[Seminar - Unix Shells, Environments] [Douglas Kline - Harvard University] [Dette er CS50. - CS50.TV] Dagens tema er Unix shell. Jeg er Douglas Kline, ekspert, eller i det minste rimelig kompetent bruker, av skallet. Et skall er grensesnittet for brukeren til datamaskinens operativsystem. Navnet er misvisende som, i motsetning til et dyr er skallet, noe som er vanskelig og beskyttende, gjør det mulig for datamaskinen skall for kommunikasjon. Så porøs membran ville trolig være en bedre metafor. Den opprinnelige skallet for Unix er Bourne shell. Bourne er stavet B-O-U-R-N-E. Bourne var en av de opprinnelige forfatterne av Unix, og så skallet er oppkalt etter ham. Navnet på at skallet som en kommando er bare rett og slett sh. Det er den kommandoen du kan utføre. Skallet starter ved innlogging. Når du logger deg på datamaskinen, skallet bare begynner å kjøre for deg, og det er det som tar dine kommandoer. Det kan begynne på andre tider også. Hvis du tar opp et vindu med ingen annen indikasjon, vil det starte et skall for deg. Det er sånn det er at du kan gå til et vindu og begynner å skrive kommandoer og så videre der selv om du ikke logget deg på til det vinduet. I tillegg, hvis du gjør en ekstern pålogging, så vil det starte et skall på den eksterne datamaskinen. Og det er mulig å kjøre kommandoer uten et interaktivt skall. Det kan bety innenfor din nåværende drift, og det kan også bety en ekstern drift. Du kan sende en kommando til en annen datamaskin, hvilken omfatter å starte opp et skall der. Faktisk har det å inkludere starte opp en shell der selv om det ikke er din endelige formål. Når noe begynner opp som dette, betyr det ikke nødvendigvis starte et nytt skall. Hvis du tar opp et nytt vindu, er det mulig å be den om å få opp en redaktør eller en annen kommando. I så fall, vil redaktøren starte fra scratch. Når redaktøren slutter, slutter vinduet. Dette er litt uvanlig, men det kan gjøres. I slike tilfeller vil det ikke være et skall. Så det er ikke nødvendigvis slik at et vindu eller noe slikt program vil få opp et skall. Shell analyserer kommandoer. Parsing innebærer å identifisere de ulike elementene og klassifisere dem. Innenfor en kommando, den komplette streng som du skriver, Det vil være en eller flere enkelt kommandoer som skal utføres. Andre elementer kan være argumenter. Det kan også være spesielle tegn som påvirker utførelsen av en kommando. De kan sende produksjonen et annet sted enn på skjermen hvis kommandoen vanligvis ville sende den til skjermen. Det kan omdirigere innspill, det kan gjøre andre ting også. Det finnes ulike andre symboler, tegn og så videre. Parsing innebærer registrering og fortolkning av disse tingene. Nå hvis det er noen flere spørsmål, noe som er ganske sannsynlig, siden det ikke er flere mennesker, vi vil gå videre til mitt neste side her. Jeg sa tidligere at Bourne shell er den første skallet. Det finnes andre. Den ene er den C-skall. Kommandoen er csh. Navnet C-skall er bare et ordspill. Denne granaten ble innført med Berkeley Unix på midten av 1970-tallet. Berkeley Unix var en banebrytende hendelse i utviklingen av Unix. Det var en stor omdreining, og med innføring av dette skall. Grunnen til at ordspill, C-skall, er at C-skallet har noen egenskaper i det som ligner på C-språk, som Bourne shell ikke har - eller det ikke hadde på den tiden. Det er også TC-skall. Dette er et supersett av C-skall. Det har flere funksjoner, hvorav mange er nyttig for interaktiv bruk, som minner om kommandoer i historien mekanismen, som jeg vil beskrive noe senere - på en enkel måte, modellert etter en redaktør. Det har også bindinger som gjør at du kan binde en kort taste streng til en lengre kommando. Vi kommer ikke til å være å få inn det i dag. Det har noen funksjoner som er nyttig for programmering. Imidlertid er den C-skallet ikke ofte brukt for skall-programmering. Shell-programmer, hvis du ikke allerede vet, er programmer som består av shell egenskaper. Du kan kjøre disse som programmer. Du skriver en haug med shell-kommandoer i en fil og kjøre filen. Du trenger ikke å kompilere den. Dette er en fortolkende språk. Uttrykket C-shell er nå tvetydig ettersom det kan referere kun til den opprinnelige C-skall, csh, eller til alle C-skjell, inkludert tcsh. Det er litt tvetydig. En senere skallet er den Korn skallet, ksh, oppkalt etter programmerer, Korn. Dette skallet forsøkt å innlemme i en shell fordelene ved den C-skall for interaktiv bruk og Bourne skall for programmering. Det har blitt brukt som et interaktivt skall av noen mennesker - en minoritet. Senere skjønt, det var en annen innledning, bash shell, BASH, igjen et ordspill, Bourne-Again Shell. Det er en forlengelse av Bourne shell. Korn skallet er også. Begge er. Den har de samme målene i Korn skallet for en sammenslåing av C-skallet og Bourne shell fortrinn i en shell. Mange av forbedringene i Korn skallet er også inkludert i Bash. Bash har imidlertid mer, og er derfor å foretrekke. The Bourne-Again Shell og Korn skallet kalles Bourne-type skjell fordi de inneholder Bourne shell egenskaper, som er inkompatible i noen henseender med C-skall. Det finnes andre skjell foruten disse, noen beregnet for begrenset bruk, kanskje begrenset til noen kommandoer, kanskje spesialiserte formål, ikke ofte brukt. Ok. Neste element her. Den Bash shell har blitt forbundet med ulike former for Linux. Jeg er ikke sikker på om det er sant for enhver form. Det finnes mange former der ute, og jeg har ikke brukt dem alle, men i de som jeg har brukt har det blitt forbundet med det. Så vidt jeg vet, er det ingenting om Bash som gjør det mer kompatibelt med Linux enn noen annen kombinasjon av skall-og driftssystem. Jeg tror dette sannsynligvis bare reflekterer tilbøyeligheter av programmerere. At det har blitt assosiert med Linux er en annen grunn til å foretrekke Bash til KSH siden ting er sannsynlig å være skrevet på det, og det er sannsynlig å spre seg. Jeg skal gi deg andre grunner til det senere. Bourne skall-skript skal kjøres under Korn skallet eller Bash. Hvis du skriver noe for Bourne shell, du kan sikkert kjøre det under ksh eller bash. Korn shell skript vil trolig kjøre under Bash, men jeg kan ikke garantere det. Senere på her, bør C-shell scripts kjøre under TC-skall. Den C-shell ble faktisk aldri mye brukt for skripting siden Bourne Shell og senere de Bourne-type skjell var å foretrekke for dette formålet. Så det er egentlig ikke så viktig. Det er ganske mye av Bourne shell skript som ble skrevet for lenge siden, før Korn skallet eller Bourne-again shell ble innført. De er fortsatt i bruk, en del av operativsystemene, og så vil du finne dem hvis du ser inn i operativsystemet eller noen gamle programmering pakker. Bash er til en viss grad bli en slags lingua franca for operativsystemer. Det er allerede blitt utvidet til Windows og til VMS. VMS, i tilfelle du ikke vet, er et proprietært operativsystem av Digital Equipment Corporation som fortsatt er i bruk, i stor grad bak kulissene. Og hvis det kommer til å kjøre på flere ulike operativsystemer, sannsynlig fleste har en tendens til å skifte for det. Men denne utviklingen er relativt fersk. Det er bare begynnelsen, så jeg kan ikke spå om dette vil vise seg å virkelig være den slags lingua franca. Også fordi filen banenavn og biblioteker avvike mellom disse ulike operativsystemer, kan du ikke være i stand til å skrive en Bash script på ett operativsystem og deretter kjøre den på en annen. Du bør være i stand til å flytte den mellom forskjellige Unix, Linux Mac OS-operativsystemer, men ikke nødvendigvis til Windows eller VMS. Du må kanskje endre fil banenavn beskrivelser, og enkelte bibliotekene kan være annerledes, som kan påvirke måten at noen kommandoer fungerer eller hvordan de behandler argumenter og lignende. I tillegg til at en annen forsiktighet her er at det er ingen garanti at alle de forskjellige skjellene jeg har nevnt - Bourne shell, C-shell, TC-shell, Korn skallet, Bourne-again shell - vil være tilgjengelig under alle Unix eller Linux eller Mac OS datamaskin. De rett og slett ikke kan være der. Det er en av advarslene her. Det er en uheldig begrensning her siden du ønsker at ting skal fungere overalt, men dessverre kan du ikke stole på det. Ok. Neste en her. La oss si at du ønsker å skrive et shell script, et program som består av shell-kommandoer. Du skriver dine kommandoer, sette dem i en fil, og kjøre filen. Hva om du ønsker å inkludere argumenter? I tilfelle av skall operasjoner, er argumenter kalt parametere eller posisjonelle parametere og de vil bli oppringt av et dollartegn og tall, $ 1, $ 2. Så hvis manuset har dette navnet, kanskje min første argumentet være argument 1 og min andre kan være argument 2, og inne manuset mitt hvis jeg ønsker å referere til disse tingene - la oss slette denne siden jeg ikke egentlig tenkt å kjøre den - inni manuset mitt kanskje jeg har $ 1 for å referere til Arg1, $ 2, som kommer ut på den måten, arg2. Så disse symbolene er tilgjengelige for å referere til argumenter, og de som gjelder for alle de skjell. I tillegg er det andre tegn. $ * Refererer til hele argumentlisten, alle av dem. $ # Refererer til antall argumenter. Igjen gjelder dette til alle skjellene. Disse symbolene, * og #, kan brukes med de betydninger i andre steder også. Vi vil ikke være å få inn i den. Shell specifier linje. Hva er det for? La oss si at du har skrevet et manus, og det er for en bestemt skall og du ønsker å kjøre den. Hvordan vet du hva skall operativsystemet vil bruke til å kjøre skriptet? På ett punkt kan du anta at det ville kjøre den i Bourne shell hvis du ikke sier noe annet, men folk ikke skriver script i Bourne shell så mye lenger og du kan ikke engang stole på det lenger. Så her har vi et skall specifier linjen her. Som angir Bash. Legg merke til at den angir det i banenavnet, / bin / bash. Hvis en datamaskin har Bash shell, men ikke i bin-katalogen, / bin, dette vil ikke fungere. Det er en annen kvalifiseringskamp, ​​en annen forsiktighet her. Firkanttegn er kommentarlinje karakter. Det gjelder for alle skjell. Den spesielle saken her, #! i begynnelsen av et skript, er et spesielt tilfelle. Som angir skallet som å kjøre skriptet. Som jeg sa, kan det ikke være på samme sted / bin. I tillegg er det en annen ting her. Hvis du bare bruker firkanttegn uten utropstegn og banenavnet, som skal indikere en C-skall. Men jeg anbefaler ikke å gjøre det fordi jeg ikke er i stand til å garantere at det alltid vil fungere. Hvis du vil ha en C-skall, ville det være bedre å si det. Så det er noe ganske forvirrende her. Hvis du bruker et skall specifier linje som / bin / bash og at skallet er ikke tilgjengelig der, det finnes ikke noe slikt som / bin / bash på den aktuelle datamaskinen, enten fordi den ikke har Bash eller fordi det er på et annet sted, du får en feilmelding som forteller deg at skriptet du kjørte ikke eksisterer. Og selvfølgelig finnes skriptet, slik at feilmeldingen er forvirrende. Grunnen til at operativsystemet gir deg denne feilen eller, mer presist, at den interaktive skall der du kjører dette gir denne feilen, er at den rapporterer kommandoen du brukte, som er navnet på skriptet. At kommandoen effektivt kalt skallet av navnet på skriptet. Det er der du får den forvirrende feilmelding. En annen måte å ringe shell script er ved å spesifisere skallet på kommandolinjen, som her. Dette er en kommando. Dette sier kjøre Bash og deretter kjøre manuset mitt i Bash. Det vil gå foran en specifier linje, og dette har i fremtiden av slik at du kan sørge for varierende banenavn. Hvis du bare gi en kommando, vil operativsystemet se etter at kommando på ulike steder. Hvis det er tilgjengelig, bør den finne det. Datamaskinen vil finne Bash uansett hvor den er plassert og kjøre den, slik at du ikke trenger da å være bekymret for hvor den finner det. Det er potensielt andre bekymringer her, som om det er mer enn en versjon av Bash, noe som er mulig selv om usannsynlig. Så det er en annen måte å forholde seg til disse tingene. Specifier linjer kan ringe noen skall. De kan også ringe andre enn skjell ting. Eksempler jeg har her er sed, som er strømmen redaktør; awk, som er et mønster behandling språk; og perl, en meget høyt utviklet skriptspråk. Hvis du putter en specifier linje som indikerer en av disse programmene i begynnelsen, det vil gå direkte inn i dette programmet heller enn å starte et skall. Disse programmene har grenser for sine evner. Perl er svært dyktige. Sed er et redigeringsprogram. Det kan gjøre ting utover bare å redigere. Men det kan være vanskelig å programmere det. I tillegg passerer argumenter og ting å skriptet er enten umulig eller forvirrende. Så i disse tilfellene, med awk eller sed, er det, i hvert fall i min erfaring, foretrekke å skrive et shell script og samtale awk eller sed fra shell script snarere enn å ringe awk eller sed som manuset specifier linjen. Perl er et svært mangfoldig språk, som jeg sa. Du kan ikke kjøre interaktive kommandoer i perl, noe som betyr at du ikke kan teste deler av skript som du utvikler ved å kjøre dem interaktivt. Men det er en ekstremt dyktige språk og har utviklet seg til en svært mye brukt verktøy. Det er bare en liten bit av et parentes bemerkning om KONSULENTEN linjer. I alle eller de fleste former for Linux - igjen, jeg kan ikke være sikker på det er alt - og i Mac OS, hvis du skriver csh du får tcsh, og hvis du skriver sh du få bash. De prøvde der for å gi deg de mer avanserte versjoner av disse skjellene, men dette kan være forvirrende. Hvis du skriver et skript ved hjelp av tcsh eller Bash funksjoner mens ringer csh eller sh og deretter prøve å kjøre den på en datamaskin som ikke har tcsh eller Bash, du kan få noen feil hvis det er kommandoer i det som disse skjellene ikke gjenkjenner. I tillegg kan du ha kalt opp skallet på den lokale datamaskinen kaller det som sh eller csh og så får de mer avanserte skjell. Du kan ikke engang tenke på det faktum at du bruker de mer avanserte shell. Så dette er en potensiell fallgruve. Hvordan er det fastslått at hvis du skriver sh du får Bash, hvis du skriver csh du får tsch? Det er ting i disse datamaskinene kalt koblinger som kan koble til filnavn for å referere til det samme. Det kan enten være to navn på samme fil eller en fil som har til formål å referere til en annen fil. De kalles harde og symbolske lenker. Vi vil ikke gå inn i det lenger i dag. Det kan også være egne filer - en fil sh, en fil Bash - men de begge kjører Bash. Så er det en annen kvalifiseringskamp her. Hvis du ringer ett av disse skjellene med ett navn, du kanskje tror du ville få samme funksjonalitet som å kalle det med et annet navn. Vel, som faktisk er ikke nødvendigvis sant. Disse kommandoene kan undersøke navn etter de ble kalt og de kan, på grunnlag av dette navnet, oppfører seg forskjellig. Det kan være problemer med å prøve å samsvare med en standard. Noen av dere har kanskje hørt om POSIX-standarden eller en annen, kanskje andre funksjoner. Dette kan velges noen ganger av kommandolinjeargumenter eller ved å sette skall-variabler. Kaller det som sh eller bash kan faktisk føre til en annen utførelse selv om det er den samme filen som du utfører. En annen ting å vurdere er at selv om en annen datamaskin har tcsh eller Bash, hvis de ikke er lenket til slik de er på din lokale maskin hvis du har et Linux eller Mac OS lokal datamaskin, så igjen vil du få skallet som du kaller sh eller csh, ikke den som du kanskje foretrekke. Den nåværende Bourne skallet har forbedringer mindre enn de i Bash men forbi de i den opprinnelige Bourne skallet. Som et resultat av dette, selv dagens Bourne skall, sh, selv når det ikke er Bash, ligner på C-språk mer enn C-shell gjør. Det var ikke sant da C-skallet først ble opprettet, men det har utviklet den måten. Du legger kanskje merke her at alle disse skall navn unntatt for Bourne shell har noe å indikere hvilket skall de er - csh, bash - men Bourne skall er bare sh. Hvorfor? Det var det opprinnelige skall. Det var skallet da, ikke et skall, og siden det var skallet, var det ingen grunn til å skille det fra et annet skall. Så det er derfor det har det navnet og gjør det fremdeles. Denne toppen her er en linje fra en passorddatabasen for en konto jeg har det på en annen datamaskin. Jeg kommer til å prøve å få det navnet, slik at du kan se at en del på slutten, skallet. Passordet database inneholder påloggings egenskaper for alle brukerne. I begynnelsen er brukernavnet, som du kan se de siste to bokstavene av meg nå. Feltene her er atskilt med kolon. Den siste feltet, som du kan se, er bin / tcsh, skallet. Det er skallet angivelse. Det er noe interessant her. Når Unix ble først utviklet, var det bare ett skall, så det var ikke noe valg der. Så hvorfor gjorde de tillater et felt i passorddatabasen for å angi et skall? Jeg vet ikke, men det er heldig at de gjorde. Det er ganske vanskelig å gjøre endringer i passorddatabasen format fordi mange programmer refererer til sitt format og måtte skrives om. Det er en treffende eller tilfeldig utvikling at de inkluderte dette feltet. Den slags passord fillinjen brukes på alle Unix-og Linux-maskiner, så vidt jeg vet. Mac har sitt eget system. Den har faktisk en passordfilen med linjene i dette formatet, men det er ikke der bruksegenskaper er definert. En annen parentes bemerkning der. Hvis du ringer et skall, kan du kalle det som en sub-skall av dine eksisterende skjell. Så hvis jeg går her, la oss bli kvitt disse tingene. Her er jeg i C-skall. Den variabelen, som nøyaktig identifiserer skallet mitt, faktisk er ikke alltid en pålitelig måte å avgjøre hva skall du kjører, men i dette tilfellet er det. Hva hvis jeg bare skriver - Nå er jeg i Bash. Noen ting kommer til å være den samme. ls forteller meg mine kommandoer. Hvis jeg en suspendere tilbake til min C-skall, ls, samme. Høyre? fg, forgrunn, tilbake til min Bash shell. pwd, gjeldende katalog, tilbake til C-skall. pwd, annen katalog - faktisk ikke en annen katalog i dette tilfellet. Det er den samme katalogen. La oss si at jeg vil kalle en kommando her: Hvor ls. Hva gjør det? Det forteller meg hvor ls kommando, den som gir meg en katalogoppføring, ligger i ls. La oss gå tilbake til Bash shell. La oss prøve det samme. Hmm, interessant det der: kommando ikke funnet. Hvorfor er det? Den der kommando er innebygd i C-skall. Dette er ikke en kommando som må leses inn i minnet fra et annet sted og henrettet. Den C-shell går det ved å overføre utførelsen til en del av sin egen kode og det er ikke i Bash shell. Så Bash, ikke å ha en slik innebygd kommando, ser for det, ikke finner det, og vi får en feilmelding. Så der har vi et bash shell som kjører under et C-shell, og vi kaller det en sub-skall. Og bare i tilfelle du er nysgjerrig, har Bash shell sin egen måte å finne kommandoer. utydeliggjort refererer til det faktum at den kan kjøres hurtigere, blir funnet raskere. Det er en av forbedringene er innebygd i noen av disse skjellene. Bourne-type skjell er å foretrekke for programmering. De har kontrollstrukturer som loops, betinget utsagn, slags kommandoer som du kan bruke i programmeringsspråk som C eller hva språk. Kanskje du programmere i Java eller hva. Skjell har dem også. De Bourne-type skjell, spesielt Bash, har mer og de er utformet med større fleksibilitet. The Bash skallet har arrays. Den opprinnelige Bourne shell ikke. Slik som kan være betydelig fordel for programmering. Den C-shell faktisk ikke har arrays, men har ikke mange av disse andre funksjoner. De Bourne-type skjell vil kjøre fortere hvis de ikke har de egenskaper som er ment for interaktiv bruk. Du laster ned ting for ett formål, og dette laster dem ned for et annet formål. Det er som trade-off der. De funksjoner som er beregnet for interaktiv bruk egentlig er av liten eller ingen bruk for skripting. Det er mulig å bruke en interaktiv sub-skall akkurat som den jeg startet der å teste ut kommandoer som du har tenkt å bruke i et skript. Det er det du ikke kan gjøre med perl. Du kan gjøre det med skjell. Selv de strukturer som for loops og så videre kan kjøres interaktivt. De er tidvis nyttig å kjøre interaktivt, men mer sannsynlig at du bruker dem til å utvikle et manus. Aliaser. Dette kommer til å være om C-skall. Historie mekanisme hvor du kommer tilbake til tidligere kommandoer eller deler av dem som du har allerede kjørt. Igjen, om C-skall, Bourne Shell og Korn skallet har disse tingene, men jeg har ikke tenkt å komme inn i dem. Så her er noen nyttige aliaser som jeg har. I stedet for å skrive ls - det er en felles kommando - bare skriv l og spare deg selv en karakter. ls med ulike alternativer, alle dem arbeid. Vær oppmerksom på at disse definisjonene har anførselstegn rundt dem. I disse tilfellene, sitatene er ikke nødvendig. Hvis du kan definere disse aliaser uten anførselstegn, vil det fortsatt fungere. De er anbefalt. Det finnes situasjoner der du ikke kan bruke sitatet fordi du vil at noe skal skje som sitatet ville forhindre. Noen ganger kan du sitere en del av definisjonen, men ikke alle av det. Det er også generelt anbefalt å bruke apostrof i stedet for anførselstegn. Anførselstegn ha effekter på variabeldefinisjoner, særlig slik at de skal evalueres i stedet for å stoppe det. Hvorfor skulle vi ønske å stoppe evalueringen? Og hvordan gjør sitater gjøre det for oss? Her er en kommando som du kan finne interessant. 'Ls g *' g *, som du sikkert vet, er et wildcard uttrykk for alle filnavn som begynner med g. Hvis jeg bare skrive inn en kommando ls g *, vil jeg få en liste over alle disse navnene i min nåværende katalog. Hvis jeg definerer som alias som det er her med sitater, det vil kjøre denne kommandoen i din nåværende katalog hvor du kjører den. Men hvis du kjører alias definisjon uten anførselstegn, det vil evaluere wildcard g * når det går denne definere kommando. Så definisjonen av aliaset vil bli ls etterfulgt av en liste over filer i katalogen hvori alias kommandoen utføres, uavhengig av hvor du faktisk har tenkt å kjøre kommandoen. Dette er ikke for mye bruk, og de apostrof hindre evalueringen av stjernen. Så får du bare definisjonen vesen ls g *. Så når du kjører alias, LGS, så sier det det ut. Nå er det ingen sitater, og det vil evaluere stjerne når du kjører alias kommandoen. Så det er en ting. Anførselstegn ville ha den samme effekten her, men det er andre tilfeller der anførselstegn ikke ville fungere så godt. Her er en annen. Du kjenner kanskje den grep kommandoen. Den grep kommandoen kan brukes til å skanne en fil for linjer som har visse strenger. Så la oss gå over her, og jeg vil gå ut fra min Bourne shell. Ok. Her er en fil. La oss si det er grep abc strenger. Det er det. Hvis jeg gjør grep zddd, jeg får ingenting. Ok. Så den finner en streng, den rapporterer, det finner ikke, betyr det ikke rapportere det. Det utganger alle linjer som har som streng på det. Det er alle slags alternativer her som du finner i dokumentasjonen. Her er én måte å gjøre det. Hva med denne, alias grabc 'grep abc'? Det kommer til å inkludere en argument når alias er definert. Så hvis jeg gjør det her, nå hvis jeg gjør grabc, nå aliaset omfatter mer enn den enkle kommandoen. Det har også argumentet. Så langt som fungerer. Jeg har en annen kommando her, denne, så de er forskjellige strenger i det og viser at dette ikke finne noe der siden det ikke samsvarer. Hva om jeg ønsker å inkludere i definisjonen av kallenavnet filen som jeg kommer til å søke og jeg ønsker å gi som et argument til alias strengen som jeg leter etter? Jeg vil kanskje si abc som argument til mitt alias, men aliaset allerede bestemt filen. Og det er der dette uttrykket kommer i. Legg merke til her vi har grep akkurat som før. Vi har filen her, strenger. \! ^, Slag av en merkelig uttrykk, antar jeg, hvis du ikke har sett dette før. Utropstegn er en del av C-shell historie mekanisme. Det kan huske tidligere kommandoer, kan det minnes argumenter til disse kommandoer og så videre. Historien mekanismen brukes som en del av aliasing. Hvis du angir en linje etter utropstegn, vil det vise til den linjen i loggen, som vi ikke vil få inn nå siden det er et helt annet tema. Det er mulig å angi del av en linje. So! 03:02 ville være den andre argumentet kommando nummer tre. Cirkumflekstegnet her i dette uttrykket står for det første argumentet. Hvis du ikke gir det en indikasjon på hvilken kommando du refererer til, det refererer til den umiddelbart foregående kommando og cirkumflekstegnet er et symbol for det første argumentet. Fordi det er cirkumflekstegnet og ikke antall, trenger du ikke å bruke kolon, så! ^ betyr det første argumentet til forrige kommando. Litt blandet opp her. I dette tilfellet, når du bruker dette som et alias definisjon, historien referanse refererer tilbake til kommandoene hvori alias brukes. Så dette kommer tilbake en kommando som en historie drift, men som et alias operasjon det refererer til den kommandoen som du ville skrive, si, grstrings_file. Vi har sitatene her i det. Hva er backslash for? I dette tilfellet, som andre steder, vi ønsker ikke å kjøre historien mekanisme mens definere alias. Hvis vi ikke har den backslash der, ville skallet trekke i det første argumentet av kommandoen rett før den kjørte denne alias kommandoen, som vi ikke ønsker. Vi ønsker at dette skal bli bygget inn i alias kommandoen til å kalle inn et argument senere. Apostrof rømmer ikke et utropstegn, historien referanse. Kanskje du kjenner uttrykket flukt betyr å endre betydningen av noe. I dette tilfelle betyr den til å slutte noe fra å ha en spesiell betydning. Utropstegn er spesiell betydning er historie. Escape og det har ikke det betydning. Sitater ikke gjør det, backslash gjør. Så vi faktisk bruker to nivåer av rømmer her. Jeg kommer til å flytte denne kommandoen inn i det andre vinduet uten å skrive det ved å bruke disse redigeringsoperasjonene, som du kan finne nyttig. Noe annet her skal jeg vise deg. Hvis du bare skriver alias uten argumenter, forteller den deg alle dine argumenter. Dette er en gjeng med aliaser jeg allerede hadde her foruten de som jeg har brukt her i dag. Men hvis jeg bare skriver med navnet på et alias, forteller det meg hva det betyr. Legg merke til at anførselstegn er borte og backslash er borte. Denne strengen her er et resultat av at alias definisjon og nå har det bare! ^ i det. Dette kommer til å se i filen strenger for noe. Så hvis jeg gjør grstrings_file strenger, det gjorde jeg ikke gi det noe å se etter det, men det ser i strenger. Det fant ikke ordet strenger i filen strenger, men det finne abc. Og den ikke finner det. Så her gir vi et argument som treffer inn i definisjonen av alias, som er satt inn i den. Det er der dette uttrykket kommer fra. Du kan bruke mer enn en. Cirkumflekstegnet er et symbol for det første argumentet. Hvis du ønsker å bruke et annet argument, ville du da si: to. Det er ingen spesiell symbol for det andre argumentet. Og fordi du bruker et tall, ville du må bruke kolon. Det er imidlertid et annet valg her. Dollartegnet står for det siste argumentet. Og fordi dette er et symbol, kan du utelate kolon. Så det ville være det siste argumentet i listen. Og det er også den. Asterisk betyr alt, så dette er den komplette argumentlisten, og igjen, kan du utelate kolon fordi det er ikke et tall. Jeg håper dere alle observere alt dette. Historien mekanismen kan gå tilbake til tidligere linjer i loggen. Du kan gjøre dette i et alias definisjon. Jeg har aldri sett dette gjort. Det ville ha effekt av å trekke ut tidligere kommandoer fra loggen når du utfører alias, som kan være forskjellige kommandoer avhengig av når og hvor du kjøre den. Muligens kan det være lurt å trekke ut en slik henvisning bare for å vite hva en tidligere kommando var. Jeg har aldri sett dette skje. Jeg antar at noen kanskje vil, men dette er svært usannsynlig. Det er en annen ting her. Hvis du bruker denne historien-typen referanse, deretter bare argumentene til hvor det er en slik henvisning er brukt. Hvis du har et alias definisjon som ikke bruker en historie-typen referanse, hvis det bare blir begynnelsen av kommandoen og du har flere argumenter, så alt du skriver etter at vil bli lagt til kommandoen. I dette tilfellet er et eksempel I ga bare der, benyttet vi det første argumentet; vi brukte ikke alle andre. Hvis andre argumenter hadde blitt gitt på kommandolinjen, ville de ikke brukes. Så hvis du bruker historien referansen i det hele tatt, så du må bruke den til å få noe argument. Det er en annen ting her jeg vil bare nevne, delvis i parentes, nemlig at denne historien mekanismen med utropstegn går tilbake til den opprinnelige C-skall. Den tcsh innført historie operasjoner som bruker den slags kommandoer og strenger fra redaktørene, enten Emacs eller vi. Min personlige mening er Emacs er mye enklere å bruke til dette formålet selv om du bruker vi for din vanlige redigering. Det finnes ulike kommandoene i Emacs som er nå tilrettelagt for historie. Kontroll P får den forrige linje i loggen. En annen kontroll P får du den før det. Opp-pilen gjør det samme. Kontroll N blir neste kommando hvis du allerede har rullet tilbake noen måter. Ned-pilen gjør det også. Du kan gå til venstre til høyre med piler og diverse andre ting. Dette kan gjøre bruk av historien mekanisme mye enklere enn å bruke utropstegn syntaks, men du ville ikke bruke det i et alias definisjon. Vi vil gå over det en annen gang. Variabler. Du vet hva variabler er i programmeringsspråk. Skallene har dem også. Den C-shell benytter kommandoen setter å tildele variabler slik som angir den variable et til verdien av b - som jeg sa, en ubrukelig definisjon, men en illustrasjon på hvordan dette blir brukt. Settet kommandoen vil opprette en variabel hvis den ikke finnes allerede. Posisjon parametere for skall-skript kan betraktes variabler, men bruken av dem og reglene for dem er noe annerledes. Du kan ikke tilordne en verdi til $ 1 i løpet av et skript. Du må definere en ny variabel for dette formålet hvis noen av dere ville. Skriv satt uten argumenter, og du får en liste over alle definerte variabler. Og la oss komme over til min andre shell her og se hva vi får hvis vi gjør det. Ganske lang liste der, ikke sant? Bla opp litt. Se på alt det. Noe av dette er definert automatisk av skallet. Skallet oppretter variabelen og gir det en verdi. Noen av dem er definert av skallet, men deretter omdefinert av brukeren ifølge hans preferanser. Og noen av dem er opprettet av brukeren avhengig av hva han gjør den dagen. Det er bare satt med noen argumenter. Det er en merkelig funksjon her på denne tingen. Det må enten være noen mellomrom mellom likhetstegnet og variabelnavnet og verdien eller områder på begge sider av likhetstegnet, som i denne. Dette vil ikke fungere, og dette faktisk er en gyldig kommando men det vil ikke gjøre hva du har tenkt. At kommandoen vil fungere fordi hvis du bare si satt og et variabelnavn med ingen likhetstegnet eller satt og et variabelnavn med et likhetstegn og ingen verdi, det vil sette variabelen til en nullverdi. Så satt en = er en gyldig kommando. Settet kommandoen kan definere mer enn en variabel på samme linje. Så denne kommandoen her har effekten av å definere både a og b til null-verdier. Sannsynligvis ikke hva du ønsker. Denne her, som nevnt tidligere, vil føre til en feil fordi = b er ikke et gyldig uttrykk. Et variabelnavn kan ikke begynne med likhetstegnet. Og det er disse ytterligere ting her. Kolon ble brukt til å velge argumenter fra historielinjer, og de kan brukes - og jeg fikk ikke gå inn før - for å endre disse tingene. De kan også brukes til å modifisere skall-variabler. Denne her, $ a har en verdi. : R vil ta av en utvidelse. En utvidelse vil være noe etter en prikk, en prikk og alt etter den på slutten av en fil, bare på slutten av listen etter den siste skråstreken. Så jeg har det her. en er det. Det vil slippe. O. Hvis det er ingen forlengelse, bare de banenavn etter den siste skråstreken, vil det ikke ha noen effekt. a: h, som variabel uttrykk, vil ta av det siste elementet i en katalogliste, igjen, kun etter at den siste skråstreken. Så / a / b / c blir / a / b, men dette endres fordi elementet etter at listen er null. Her er det noe som også jeg ønsker å understreke. Disse kvalifiseringskamper ikke søke etter forekomster av disse filene. De bare ser for strykere. Disse er ment å manipulere filnavn, banenavn, men de kan brukes på en hvilken som helst streng, selv om det ikke er et filnavn. Og de ser ikke for eksistensen, så hvis det ikke finnes en slik fil, / a / b / c, dette vil fortsatt fungere. Enten det er til noen nytte er et annet spørsmål, men det vil fortsatt fungere. Variabler er forskjellige i de Bourne skall. Vi får til det senere. Dollartegn kan rømt akkurat som utropstegn og stjernen. Dollartegn kan settes inn en omvendt skråstrek eller apostrof. Anførselstegn har odde effekt i alle skjell for å tvinge evalueringen av et dollartegn variabel uttrykk. Så hvis det blir rømt én måte, kan de doble anførselstegnene ha effekt av dette til å bli vurdert uansett. Dette er litt forvirrende. Hvis det finnes flere nivåer av rømme, for eksempel apostrof inne doble anførselstegn eller doble anførselstegn inni apostrof, bør du teste for å se hva som vil skje til en variabel hvis du bruker en. De to situasjoner - dobbel innsiden av singel, singel innsiden av dobbelt - ikke nødvendigvis gi deg samme resultat. Miljøvariabler, bundet C-skall-variabler. Miljøvariabler er også variabler i C-skall, og de er også variable i andre skjell også. I C-skall, er de forskjellige settene. De tingene jeg sa før er om skall-variabler. Miljøvariabler er et distinkt sett av variabler med unntak av en rekke variable som vi kaller bundet variabler som er svært viktig, og vi vil komme inn i de senere. Miljøvariabler blir automatisk sendt videre til skjell eller kommandoer som kjøres fra skallet ditt. De andre tingene er ikke. De skall-variabler, aliasene ikke. Miljøvariabler er. Det er derfor vi kaller dem miljøvariabler, tanken er at miljøet strekker seg forbi nettopp din nåværende skall. De kan brukes til å definere ting for kommandoer. Her er et eksempel. SKRIVER, LPDEST. Begge disse variablene kan definere en skriver som en kommando vil bruke til å skrive ut ting. Hvis du har flere skrivere rundt, kan det være lurt å sette den du liker. Grunnen til at vi har to variabler er at ulike sett av kommandoer ble skrevet ved hjelp av disse ulike variablene. Du kan gi dem forskjellige verdier. Mest sannsynlig vil du gi dem begge samme verdi. Disse tingene fungerer fordi de kommandoer som gjør utskrift ble programmert til å undersøke verdiene av disse variablene. Hvis et program ikke ble skrevet på den måten, hvis det ble skrevet for å gjøre noe annet, variabelen ville være irrelevant. Slik at operativsystemet ikke er på utkikk etter disse variablene hver gang du refererer til en skriver. En kommando som gjør utskriften er ute etter disse variablene hvis den er programmert på den måten. Disse variablene er ofte definert i dine klargjøringsfilene , men ikke nødvendigvis. Du kan definere dem på kommandolinjen. De kan defineres i en kommando. En kommando som kjører noe kan ha sitt eget utvalg av variabler - variabler som er unik for en bestemt programvarepakke, for eksempel. De vil bli definert når du kjører den pakken. Hvordan er disse variablene gått til en sub-shell? Når en sub-skall er skrevet, betyr det ikke skrive inn i det området. Arealet av sub-skall som er viet til miljøvariabler er ikke skrevet av den sub-skallet, det er skrevet av kopiering. Når du kjører en vanlig kommando, slik som disse kommandoene til å skrive ut eller hva, de starter med å lage et nytt skall. Skallet skaper et skall, og deretter overskriver en del av det med den kommandoen du kjører, noe som er litt forvirrende, men det er hvordan disse kommandoene får miljøvariablene at de deretter referere til senere. Kommandoen her for å definere den variable setenv. Det er hvordan du definerer det. Det er tre elementer: setenv, variabel, verdi. Hvis du bare trenger setenv uten argumenter, hva får du? En liste over alle disse variablene. Igjen, det er en fin lang liste, og i dette tilfellet, som i de andre, disse variablene er definert i stor grad av mitt login drift av skallet selv snarere enn av noe jeg gjorde. Det er en annen kommando her, printenv. Det skriver også ut i miljøet. Legg merke til denne siste tingen her, redaktør = vi. Som sier at hvis jeg bruker noe som kaller en redaktør og jeg ikke angir en redaktør, og det gjør meg valget, kan det gi meg vi. Hva hvis jeg gjør printenv EDITOR? Det forteller meg hva det er. Rett før det, det var en variabel, MINST. Dette er dine mislighold alternativer når jeg kjører jo mindre kommando, som viser filer. Så hvis jeg gjør det, kan printenv ta en argument eller 0 argumenter, ikke mer enn en. Det er andre kommandoer også, men vi kommer ikke til å komme inn i alt som i dag. Husk at det var de modifikatorer for skall-variabler som: h, som vil slippe det siste elementet av et banenavn, eller: r, som vil slippe en forlengelse. De som nå gjelder for miljøvariablene også. De gjorde ikke vant til. Det pleide å være at de ikke kunne bli endret. Nå kan de være. Det er en av de fremskritt med utviklingen av skjellene i løpet av årene. Jeg sa at skjellene som en del av de miljøene og skall-variabler i C-shell er, med noen unntak, forskjellige sett. Du kan opprette en miljøvariabel og et skall variabel med samme navn. De vil være forskjellige variable, de kan ha forskjellige verdier. Å endre verdien av en ikke vil endre verdien av den andre. Disse variablene er alle vurdert med dollartegnet - $ a, $ uansett. Så hva om du har dette? Vet du hvilken du får? I mine tester fikk jeg skallet variabel, men dette er ikke dokumentert, og du kan ikke stole på det. Så jeg spør dere, er å skape skall og miljøvariabler med samme navn en god idé? Nei Ok. Hva er de viktigste unntakene i hvilke miljø-og skall-variabler er knyttet til hverandre? Det er disse fire. Forbokstav TERM miljøvariabelen, shell variabel sikt i små bokstaver, type terminalemulering. Jeg skal bare gå over her, og jeg kommer til å gjøre ekko, en nyttig kommando her, $ TERM $ sikt. Og der. xterm er en terminaltype for vinduer vises i X Window System. xterm-farge er en variant av det som gjør at ulike farger. Hvorfor vi definerer disse? Hva er dette godt for? Kommandoer som omorganisere skjermen som redaktør sende bestemte sekvenser, kalt escape-sekvenser, til en terminal eller et vindu for å ordne det, og så videre. Disse sekvenser er forskjellige for forskjellige typer av terminaler. Dette forteller det hvilke du vil bruke. Noen ganger er det problemer der. Du ønsker kanskje å endre det. Hvis ting ikke fungerer, noen ganger terminaltype er satt feil, du kan være i stand til å fikse det ved å redefinere begrepet variabel. I disse tilfellene, endre én variabel, miljøvariabelen eller skallet variabel, skal forandre den andre. Jeg har oppdaget gjennom erfaring at endring TERM med blokkbokstaver endres ikke alltid skall variabel sikt i små bokstaver. Dette er en bug. Jeg vet ikke om det er alltid sant. Mesteparten av tiden er det ikke sant, men det kan være. Så hvis du gjør en endring, bare sjekk det ut. Det er ikke ofte at du må endre denne verdien, men en gang i en mens du gjør. Miljø variabel BRUKER. Igjen, miljø variabel i store bokstaver, shell variabel i små bokstaver. Dette er ditt brukernavn. Det er bare under helt spesielle omstendigheter at du ønsker å endre på det. Hvis brukernavnet ditt er noen andre, kan det kaste alle slags ting av. Hjemmekatalog, brukerens hjemmekatalog. Igjen, ville du ikke ønsker å endre det. Legg merke til i alle disse tilfellene, og en som vi er i ferd med å dekke, banen variabel, miljøvariabelen er i store bokstaver, og det bundne shell variabelen er i små bokstaver. Dersom du endrer en, bør du endre den andre. Denne typen binding kan ikke etableres som du ikke kan binde to variabler, andre enn disse fire, og bindingen i disse variablene kan ikke omgjøres, du kan ikke skille dem. Så disse fire parene av variablene er bundet. De alltid vil være. Ingen andre vil være. I tillegg vil det være mulig å lage variablene med de samme navnene av de motsatte typer. Du kan lage et skall variabel sikt i små bokstaver eller en miljøvariabel begrep i store bokstaver. Disse variable vil være uavhengig av disse sammenkoblede variablene og de kan være uavhengige av hverandre. Jeg kan ikke forestille meg hvorfor du ville gjøre det med mindre du ønsker å forvirre folk. Denne her, bane variabel, er dette en veldig viktig en. En annen ting her er at det kan være tilfeller av variablene med lignende parede navn som ikke er bundet til hverandre. Det kan være variabler, Shell og skallet, i store og små bokstaver. Basert på det navnet, vet du ikke om at variabelen er et skall variabel eller et miljø variabel, og de er ikke bundet til hverandre. Så den slags sammenkoblede navnene betyr ikke bundet variabler. Stien variabel, som jeg ble vist før, er en liste over banenavn hvor skallet ser for kommandoer. La oss komme over til dette vinduet her, og vi vil gjøre echo $ PATH, store bokstaver - miljøvariabelen - echo $ banen, små bokstaver - shell variabel. Legg merke til at listen over kataloger er den samme. Disse er bundet. Endre en, endrer du den andre. I miljøvariabelen elementene er atskilt med kolon. Legg merke til det. De skall-variabler er atskilt med mellomrom. Denne miljøvariabelen er et enkelt streng. Skallet variabelen er en matrise. The Bourne shell hadde ikke arrays. Bash gjør, men dette er allerede en fast del av skallet. Dette er en enkelt snor, og ikke en matrise. Den C-shell alltid hatt arrays. Arrays er mye lettere å jobbe med. Du kan referere til deler av den. Så echo $ bane [1] og jeg får / usr / bin, det første elementet. Igjen, husk dollartegn står for det siste elementet i historien listen. Hva skjer der? Den prøvde å finne dollartegn som en variabel symbol. Jeg unnslippe det. Oops. Det ville ikke ta det heller. Noen av disse tingene ikke fungerer så godt. Kanskje vi skal bare la det ut. Stjernen refererer til hele greia, men det er hva du får hvis du ikke angir et element. En annen måte som matrisevariabler kan manipuleres, antall elementer der, 7 elementer. Her kan vi legge firkanttegn før variabelnavnet. Her er en annen en. Satt et spørsmålstegn der. Det er en logisk verdi. Det indikerer at variabelen eksisterer. Det er en annen måte å jobbe med variabler. Det, forresten, ikke behøver å være en matrise variabel. Det kan være noe variabel. Og hvis jeg gjør det, er det ingen slik variabel, og jeg får en 0. En annen liten ting der om variable evalueringer. Tilbake til dette her, hvis noen grunn du ønsket å jobbe med dette snarere enn å jobbe med matrisen, skallet variabel, Det er kommandoer som kan skille ut dette basert på tykktarmen. Faktisk, hvis du kommer til å gjøre dette i bash shell muligens, noen form for et skript, vil dette være nok hvordan du vil gjøre det. Men i C-skallet er det mye enklere å bruke matrisen. I Bourne skall, er variabler tildelt av et enkelt uttrykk som dette, liker måten du kan tilordne en variabel i et programmeringsspråk, og her må det være noen mellomrom. Det er nødvendig at det er bare en streng. I Bourne-type skjell, alle variabler er skall-variabler. Miljøvariabler er en undergruppe av skall-variabler. De skiller seg fra de ikke-miljøvariabler ved å eksportere. Kommandoen for å gjøre det på er eksport, som eksport SKRIVER. Hvis vi definerer en slik variabel, hvis vi ønsket en utskrift kommando for å finne det, måtte det være en miljøvariabel, og det er hvordan vi gjør det en. Her er det noe slags forvirrende. Dette uttrykket, eksport til miljøet, stammer fra denne Bourne shell-konseptet, og likevel at uttrykket er brukt i beskrivelsen av den C-skall, der det ikke er noen slik kommando som eksport. Hvis du bare si eksport av seg selv, får du en liste over eksporteres - Så hvis jeg bare eksporterer her, ikke noe slikt. Ok, det vi går. Disse tingene, forresten, er også definert av skallet. Jeg gjorde ikke definere noen av disse ved meg selv. Skallet gjør alle slags ting av seg selv. Det bør gjøre ting automatisk. I Bash eller Korn-skall, kan du kjøre en kommando som dette, som både vil gi en variabel en verdi og eksportere den i en kommando. I Bourne shell må de være separate kommandoer som eksport en. Her er et annet aspekt som er forvirrende. Settet kommandoen i C-skall definerer variabler og uten argumenter forteller deg hva variablene verdigrunnlag. I Bash shell, gjør set-kommandoen uten argumenter det samme, men med argumenter gjør det noe helt annet. Så dette er de ulike argumentene her. Noen av disse er variabler, noen av dem er skall-variabler. Alle av dem er skall-variabler egentlig. Noen av disse er miljøvariabler. Settet kommando med argumenter kan brukes til å betjene på de posisjonelle parametre til et skript, som er en måte å få dem alle samtidig. Vi kan egentlig ikke gå inn på det i dag. Den kan også brukes til å endre skall oppførsel. Spesielt i Bash det er variabler som vil avgjøre hvordan skallet oppfører seg. Da også bare denne ene kommando som du kan se, denne kommandoen. Skrivne fulgt av variabler og variabeltyper brukes i Korn og Bash skjell. Det er ikke obligatorisk, men den kan brukes til å begrense verdiene av variablene noe som kan være nyttig for å unngå feil, og det er ganske vanlig. Så jeg bare nevne at dersom du ser den et sted. Den der kommandoen. Husker jeg nevnte tidligere hvor kommandoen i C-skall, som kan fortelle deg plasseringen av en kommando banenavn. Her er kommando substitusjon. Du bør finne på tastaturet et sted et tegn som ser ut som dette. Plasseringen på tastaturet kommer til å variere. Vi har kalt det backquote. Det er omtrent på størrelse med et sitat. Det går fra øvre venstre til nedre høyre. Her på min Mac tastatur det er i øvre venstre hjørne. Det karakter kan brukes for å utføre en kommando i en kommando. Hvis du har et uttrykk inne backquotes, at uttrykket er en kommando, det kjøres. Utgangssignalet fra den kommandoen blir deretter byttet ut med hele backquote ekspresjon inne i en lengre kommando som kjører deretter med at produksjonen som en del av sin rekke argumenter og så videre. Her er en kommando som bruker det. La oss demonstrere operasjonen her. La oss gå opp her, ta ut backquotes. Kontroll En får meg til begynnelsen av linjen med Emacs redigering syntaks. Så langt banenavn er hva der gjør, men når jeg gjør det slik, så plugger den i den listen over banenavn i stedet for hele denne backquote uttrykk og kjører ls-l på dem. Slags praktisk, ikke sant? Så det er en fin ting. Det er slik backquotes fungerer. Nå la oss gå ned litt lenger. Dette er aliaser. Jeg faktisk bruker disse. Jeg skal prøve å få dette inn med en redigeringsoperasjon. Ok. La oss nå se hvordan disse definisjonene kom ut. alias LHB fortelle meg hvordan det er definert. Legg merke til det er nettopp dette, men de ytre sitater har blitt tatt av og utropstegnet er tatt av. ! *, Komplett liste over alle argumentene. I et alias definisjon vil det gjelde tilbake til der jeg bruker dette. LHB ksh bash. Ok. Se hvordan det fungerer? Det sparer meg noen skrive. La oss gå opp litt bare for å nevne noe annet her. Legg merke til her disse ulike skjell. Jeg burde ha nevnt dette før. Den csh har en to over her og det gjør / bin / tcsh. Vi kunne etablere på andre måter at de er faktisk den samme filen. Husker jeg sa hvis du skriver sh du få bash. Skriv inn denne og du får dette. Men de som ikke er koblet sammen. De har enkle som er der. Og dette er ikke den type fil som kan kalle en annen. Så de er separate filer, C-skall som er den samme filen. Tilbake her nede, den andre her, dette aliaset, merk som kjører denne kommandoen, fil. At alias går det. Filen forteller deg hvilken type en fil. Så FWH ksh bash. Ok. Det er resultatet av filen kommandoen. Jeg vet ikke om du vet hva dette betyr her, Mach-O Universal Binary med to arkitekturer. Det finnes to mulige typer prosessor i Mac, og enkelte programmer ble skrevet for å være i stand til å kjøre med begge, og filen kommandoen kan bestemme det, så det er hva dette betyr. Begge disse filene ble skrevet på den måten. Så vi ser hvordan alias fungerer, ser vi hvordan backquote fungerer, vi se hvordan selve filen ls eller fil fungerer. Dette kan ikke fungere. Prøv "der hvor" og "LHB der". Ok, la oss prøve det. der hvor. der er et skall innebygd. Husker vi viste at Bash ikke hadde der. Hvis du skriver hvor i Bash shell, får du en feilmelding. Det er bare en del av skallet i stedet for å være en separat kommando. Hva skjer hvis jeg skriver LHB leter etter der? Se hva som skjer der. Ran hvor der, fikk denne utgangen, og deretter prøvde å kjøre ls som l på hvor er et skall innebygd. hvor er det, men de andre som ikke eksisterer. Ingen av disse eksisterer, faktisk. Så det fungerer ikke alltid, og det også illustrerer hvordan noen ting gjør ikke helt hva du kanskje har trodd. La oss gå ned litt lenger her. Dette her er i Bash. Det er også kommandoen substitusjon som backquote. Men i motsetning til backquote, bruker den denne variabelen stil. Det finnes en rekke uttrykk som begynner med et dollartegn, og mens disse er ikke variabler, lånte de bruk av dollartegn å indikere et uttrykk av noe slag. Det kan være omgitt av parenteser eller braketter eller doble parenteser, som har et annet formål. Enkelt parentes her er en kommando substitusjon akkurat som backquotes. Doble parentes er faktisk en aritmetisk operasjon. Det er andre syntaks, andre operasjoner. Backquote syntaks er tilgjengelig i Bash. Dette er imidlertid en foretrukket. Det er mye lettere å lese, og det gjør at hekkende. Du kan ha inne $ (kommando) en annen kommando, noe sånt som - Jeg får en liste der. Det ville fungere hvis jeg hadde backquote også. Hva om jeg ønsker å gjøre noe sånt - Du har sannsynligvis ikke ville faktisk bruke denne kommandoen, men denne interne kommando substitusjon ekko navnene på alle filer som begynner med en, så dette går ls-l på disse filene, og deretter dette bare ekko utgang. Du har sannsynligvis ikke ville gjøre dette, du vil bare gjøre ekkoet eller ls, men dette illustrerer hvordan hekkende av kommandoer fungerer. Så bare en annen funksjon her.  Jeg nevnte dette tidligere, at når du har der i C-skall, skriver fungerer i Bourne-type skjell for å finne kommandoer. Innebygde kommandoer, akkurat hva jeg sa der. Kommandoer er en del av skallet, som hvor. Når skallet utfører en kommando som ls, finner den det gjennom banen, finner den i en katalog et sted, lesninger som i minnet, skaper et nytt skall, leser kommandoen ls eller hva i skallet hvor miljøvariabler er allerede plassert, og da er det overfører kjøringen til det. Innebygd kommando, er koden for den kommandoen inne i skallet, slik at skallet bare begynner å utføre en del av sin egen kode. der er en slik kommando. Det blir faktisk raskere. Det trenger ikke å lese noe i minnet, det er allerede i minnet. Innebygde kommandoer alltid gå foran kommandoer med samme navn. Kommandoer som er i kataloger i banen kan ha samme navn, kommandoer i ulike kataloger, filer i ulike kataloger. Den ene som oppstår tidligere i banen er det du får. Hvis det er en innebygd kommando, får du alltid det. Det er ingen måte å gi den en lavere prioritet enn en kommando i banen. Hvis du ønsker å få den veien kommando, kan du skrive inn fullstendig bane. Hvis det var en kommando hvor i banen et sted, du kan skrive / bin / hvor og du vil få det. Hvis du ikke ønsker å skrive hele banenavnet, kan du definere et alias. Faktisk, hvis du ga aliaset det samme navnet som den innebygde kommandoen, ville det fungere fordi definisjonen av kallenavnet evalueres før skallet fastslår at det er en innebygd kommando som skal utføres. Så dette blir litt mer komplisert med noen kommandoer her. Tilfellet med noen kommandoer er faktisk innebygde kommandoer og i banen. En av dem er ekko, kommandoen jeg bare brukt en liten stund siden i disse eksemplene. Echo er en kommando i banen, og det er i hvert skall. De trenger ikke nødvendigvis alle oppfører seg på samme måte. Det var opprinnelig en kommando bare i banen. Den ble bygget i til skjellene senere. Fordi det finnes alternativer som er avhengig av miljøet og kommandolinjealternativene, de innebygde kommandoer ble skrevet for å virke på samme måte som kommandoen som hadde vært i banen det er usannsynlig at de ville ha blitt skrevet på den måten hvis kommandoen ikke allerede hadde blitt skrevet for banen. Så dette har bivirkninger. Dens historie har effekter her. Det finnes alternativer der. Det er også et alternativ definert av en variabel i tcsh kalt echo_style. Det er en av disse variablene som kan endre måten som ekko fungerer. Det finnes andre tilfeller hvor du kan tilordne en variabel som endrer måten at skallet operasjon, inkludert en innebygd kommando, virker. Det vil ikke påvirke noe annet siden andre kommandoer ikke har tilgang til de skall-variabler, bare miljøvariabler. Men skall operasjoner kan lese skall-variabler. Det vil ikke fungere for csh. Det er bare tcsh. Det er en av forbedringene. Parsing har sekvenser når det evaluerer metategn, når det evaluerer variabler, aliaser, historie referanser. Det er en bestemt sekvens for disse tingene. Hvis den gjør ting i en bestemt rekkefølge og får til noe som er et uttrykk for en slags som allerede har blitt evaluert, vil det ikke vurdere det på nytt. Hvis det blir det, så vil det bare passere på tegnene. Så hvis evaluering av noen uttrykk som kommando substitusjon eller variabel eller hva gir opphav til et uttrykk som du ønsker å bli vurdert, som vil arbeide bare hvis det evalueringen skjer senere i sekvensen. Jeg håper jeg blir klar der. Det parsing sekvens, en operasjon i C-skall, er ikke det samme for innebygde kommandoer som det er for ikke-innebygde kommandoer. Jeg er ikke sikker på om Bash der. For eksempel produseres hvis et skall variabel tidligere referanse, det sannsynligvis ikke ville gå tilbake i historien. Det ville bare få utropstegn. Faktisk kan vi bare prøve det ut akkurat nå. satt et = og vi må sette dette i det. Oh, vent. Unnskyld. Jeg gjorde dette i Bash. Jeg ønsket å gjøre det her. Se, så det gjorde ikke vurdere at historien referanse fordi det var allerede forbi punktet med å evaluere historie uttrykk når det vurderes variabelen. Så det er en effekt av parsing. Og igjen, er innebygde kommandoer ikke gjort på samme måte. OK. La oss gå til den neste her. Dette er ment å være en linje, men det gjør det lettere å lese. Hva gjør det? Du husker kanskje at vi kan evaluere stjernene som filnavn jokertegn, og det er andre filnavn wildcards som spørsmålstegn og brakettuttrykk. Den slags evaluering kalles jokertegn. satt noglob i begynnelsen av denne kommandoen sier ikke gjør det. unset noglob sier gå tilbake til å gjøre det. Vær oppmerksom på at settet glob ville ikke ha den effekten. I vanlig språk, ville sette glob eller unset noglob synes å være tilsvarende, men her er det ikke. Det er unset noglob. Nå tset. tset sto for terminal sett. Det er ikke brukt så ofte nå, men før owing systemer ble tilgjengelig og du hadde en enkelt terminal, må du kanskje finne ut hvilken type. Og hvis noe skulle komme over et Ethernet eller fra nettverket, vil du kanskje si at det er en VT100. VT100 er en slags standard i terminalen virksomheten. Den kommer fra desember terminal. Hvis du bare gjøre oppringt - Legg merke til at? Dette går tilbake et stykke, ikke sant? Så hvis vi bare gjør tset over her, hvis jeg bare gjøre tset, er det tilbakestille min terminal, men du fikk ikke se noe. Det gjorde egentlig ikke endre noe. -S Ok. setenv TERM xterm-farge. Vi vet allerede at begrepet ble satt på den måten, så det ikke ble endret. Det er slik vi ønsker å gjøre det. Men legg merke til at denne kommandoen, tset-s, bare utgang disse kommandoene. Det gjorde ikke kjøre dem. Det gjorde ikke kjøre disse kommandoene, det utgang dem. Så dette er ment for å produsere kommandoer som vil bli kjørt. Du husker kommandoen i den filen jeg bare viste du hadde en Q i den. Så la oss gjøre det. Q undertrykker noen utgang, men det spiller ingen rolle her, som du kan se. Jeg bare gjør det for å vise deg at det ikke spilte noen rolle. Dette er i backquote syntaks. Legg merke til backquote her, backquote her. Jeg utelate disse tingene her. Dette er tilfeller av å fortelle den hva den skal gjøre i tilfelle av visse typer terminaler - Ethernet, nettverk, oppringt, hva har du. Det spiller ingen rolle her fordi vi ikke faktisk gjør noen av disse tingene. Jeg bare illustrerer kommandoen. Hvis jeg gjør dette med backquote, hva jeg kommer til å få? Legg også merke til her at dette inkluderte settet noglob og usatt noglob, Så de er nå overflødige i definisjonen. Det var ikke alltid sant, men nå er de tatt med i denne kommandoen. Men la oss se hva som skjer hvis jeg gjør det og gå til begynnelsen av linjen med kontroll A og jeg gjør det. Ok, satt: Kommando ikke funnet. Det er slags merkelig, er det ikke? sett er en velkjent kommando. Det er en del av skallet. satt: Kommando ikke funnet? Hvorfor er det? Hmm. Vel, la oss tenke på dette. Det er en backquote kommando substitusjon kjører, og som oppstår ved en viss del av sekvensen for analysering av kommandoen. sett er en innebygd kommando. Så da det gjør at kommando substitusjon, det er allerede kommet forbi det punktet av å identifisere innebygde kommandoer. Så det behandler satt som om det var en kommando i banen. Unødvendig å si, det gjør ikke det, og du får en feilmelding. Vel. Det er et eksempel på parsing sekvens. Og hva gjør vi med det? Legg merke dette veldig interessant kommandoen her, eval. Jeg lurer på hva som gjør. Hvis du ser på manualen - og la oss bare gjøre det å vise hvor forvirrende disse håndbøkene er - Mannen tcsh, forvirret manuell, finne ting her er ikke lett heller. Here we go, eval arg, slik at vi kan ha en eller flere argumenter og det er en liste over ting der. Behandler argumenter som innganger til skallet og utfører de resulterende kommandoer i forbindelse med den aktuelle skall. Dette er vanligvis brukt til å utføre kommandoer generert som følge kommando eller variabel substitusjon fordi parsing skjer før disse erstatningene. Veldig bra. Og her de selv henviser til tset kommandoen for en prøvebruk som den jeg bare viste deg. Nå må jeg få vinduet tilbake til et nyttig sted. La oss komme over her og vi vil se at eval brukes like før det. Så la oss se hva som skjer hvis vi legger - her går vi opp med pilene til den kommandoen og kontroll A til begynnelsen EVAL. Ok, så det fungerer. Når du gjør eval, det tar hva som kommer etter det, og gjør det til en kommando. Dette gjør at du kan egentlig analysere det to ganger. Seksjonen her kjører denne kommandoen inne backquotes, blir utgangseffekten. Output er ment for å kjøres som disse kommandoene her som disse på dette, og denne. Så disse kommandoene er nå her i denne sekvensen, men disse er innebygde kommandoer, og det kan ikke få dem med en gang. Så vi går til eval, plukker eval det opp, starter det hele på nytt, og det fungerer. Et eksempel både av backquoting, eval, parsing, konsekvenser av parsing, og en kommando som sannsynligvis er av svært liten nytte for deg i dag. Ok. Greit, umask. La oss se på denne kommandoen her, umask 022. Jeg lurer på hva som gjør. La oss bare skriv umask med ingenting etter det. 22. Ok. 022 og gjøre det igjen. Som du kanskje har gjettet, forteller umask uten argumenter du gjeldende maske; umask med argumenter gjør det det, men det var den jeg allerede hadde. Hva betyr 022 bety? Disse er her de beskyttelse for en fil. De avgjør hvem som får lov til å lese eller skrive eller kjøre filen. Gjerder er også kalt tillatelser. R står for read, w for skriving, og x, som ikke er til stede der, står for utføre. Det er tre kategorier der. De siste tre elementene er i kategorien for brukeren. De gjelder for meg, brukeren. Disse tre her gjelder for gruppen. Filen tilhører en gruppe, kan brukeren høre til flere grupper, men hvis brukeren er i gruppen som denne filen tilhører, da disse beskyttelsene vil gjelde for ham hvis han ikke er brukeren. Og dette er alle andre. Disse kategoriene er gjensidig utelukkende. Bruker beskyttelse gjelder for ham, beskyttelsen gruppen gjelder medlemmer av gruppen andre enn brukeren, og de andre beskyttelsene bare gjelde for andre enn brukeren og gruppemedlemmene folk. Hvis det er en r eller aw eller en x, betyr det at beskyttelse er gitt. Hvis det er en bindestrek, betyr det at det er det ikke. Det faktisk er andre ting som kan settes inn her i tillegg til disse, som jeg vil ikke komme inn nå. Umask definerer en standard for filer som du oppretter. Og som en maske, i utgangspunktet står det biter som du ikke satt. Hvordan har dette blitt bits? Hvis du tenker på hver av disse som et oktaltall, dette er den 1s litt, dette er de 2s, dette er de 4s. Så 0 til 7 vil beskrive hvilken kombinasjon av R-er, w-tallet, og x-er du har for disse tre og deretter et tilsvarende antall for disse og deretter for disse. Så 022 betyr 0 for andre, to for gruppen, to for brukeren. Men dette er en maske. Masken er det du ikke har. Jeg beklager. Jeg bare ga deg ting i feil rekkefølge. Det er den første tre. Disse tre er at brukeren, disse 3 er gruppen, disse 3 er den andre. Beklager at jeg ga deg disse i feil rekkefølge. Når 0-, som er den første av disse, ikke viser verdien, men hvis et tall er ikke der, det er en 0. Det betyr at alle tre av disse ville bli tillatt. Legg merke til at i denne spesielle én x er ikke tillatt. Grunnen er at skallet er i stand til å avgjøre om en fil skal utføres eller ikke. Siden dette ikke er en kjørbar fil, det gjorde ikke sette x. De to virkemidler som skriver tillatelse, den andre kategorien her, den ene i midten, er avslått. Så igjen, dette er ting som det avslått. Vel, er x tillatt, men det er ikke her fordi det er ikke kjørbar og tilsvarende for de andre. Så det er en felles umask. En annen vanlig en er 700 - gi deg selv alt og ingen andre noe. Og det finnes andre muligheter. Jeg skal gå tilbake til det. Bruke historien jeg kan søke tilbake for det, LHB til det. Ok. Så her er det disse skjellene. Bash, eieren som er systemkonto, kan gjøre alt. Gruppe og alle andre kan gjøre lese eller utføre, men ikke skrive. Dette man ikke engang tillater eieren å skrive til den. Hvis eieren ønsket å skrive til den, systemkontoen, han ville ha til å endre beskyttelsen først. Men igjen, setter umask standard ved å maskere det, ved å antyde biter som ikke vil bli satt. Dette er typisk i en av initialiserings-filer, som er den. Cshrc for C-shell eller. profil for Bourne-type skjell. Det kan være andre steder også hvis det er andre initialisering filer på systemet. Uansett, det er umask. Det er noe slags merkelig her, og det er, hvorfor er det en enkel kommando for dette? Hvis jeg skulle skrive dette, ville jeg gjøre det til en variabel, umask = noen verdi. Hvorfor er det en hel kommando bare for dette formålet? Årsaken er dette bare går tilbake til opprinnelsen til Unix. Unix var bare noen programmeringsprosjekt ved Bell Labs i 1970-årene. Folk bare kom sammen til programmet. De har aldri ment det å bli en verdensomspennende operativsystem. Ulike folk skrev ulike deler uten å tenke veldig mye av hvordan de skulle brukes - heller sketchy. Og det kom sammen sånn, og det er fortsatt sånn i noen henseender. Så det gjenspeiler historien, og det er fortsatt disse inkonsekvenser og odde elementer av det. Ok. Neste en her. Som jeg skrev tidligere, er det C-shell egentlig ikke brukt veldig mye for programmering, Selv om det kan være. Det utfører saktere, igjen trade-off mellom interaktiv bruk, som har mer behandling involvert enn fart, noe som kan gjøre uten behandling. De ekstra funksjoner lagt til Bourne skall av Korn og Bourne-again skjell synes ikke å bremse dem ned, og jeg vet ikke hvorfor det er. Det kan bare bli bedre programmering, men jeg er ikke i en posisjon til å vite. Hastighet her faktisk ikke er en så big deal, selv om det er nevnt. Årsaken er at skallskript faktisk få ganske fort. Hvis det er mye av kommandoer som i en calculational program, du sannsynligvis ikke ville gjøre det i et skall skript. Operasjonene er ganske enkel og grei. De som jeg har opplevd som er for treg bære gjentatte anvendelser av langsomme kommandoer. Tidligere nevnte jeg stream redaktør sed. At kommandoen er treg. Hvis du utfører sed mange ganger, vil du få en treg script, men det er ikke skallet som er treg. Kjører den i Bourne shell vil ikke være mye raskere enn å kjøre den i C-skall, selv om det er kanskje noen fordeler der. De ytterligere programmeringsmuligheter, på den annen side, er betydelige grunner til at du ville bruke de Bourne-type skjell. C-skallet har odde funksjoner til det - det faktum at du ikke vet om en variabel er et skall variabel eller en miljøvariabel. Det kan være veldig forvirrende. Det er ikke så lett å skrive bare basert på din erfaring med programmering i andre språk. Jeg tror du kan finne de Bourne-type skjell mer i samsvar med din erfaring. Noen skript, men kan være tusenvis av linjer i lengde. De som jeg har sett er brukt for patching operativsystemer. De kan kjøre veldig sakte, men du trenger ikke kjøre dem veldig ofte. Det er bare når du gjør patching, og det er bare systemet manager som gjør disse tingene, så det er egentlig ikke mye av et problem. De som er hundrevis av linjer lang faktisk kjøre ganske raskt. Nevne dette her, hva er de forbedringer? Jeg har allerede nevnt noen av dem - arrays, beregninger, de $ () uttrykk for beregninger i Bash shell, den andre typen kommando substitusjon. Det finnes forskjellige typer testing kommandoer som du kan gjøre betingede tester på eksistensen av en fil eller andre ting. Vare her, denne kommandoen her. Hva gjør dette, og hvorfor skulle noen bruke det? printenv variabelnavn. Vi vet hva printenv gjør. Det forteller oss at verdien av en variabel. Og printenv variabel vil ikke fortelle oss veldig mye fordi det er ingen slik variabel. Blank. Men la oss gi den noe meningsfylt. Det er ikke der heller. Ok. Jeg tror jeg aldri definert det. La oss bare sjekke mine omgivelser. Dette er en annen kommando som du kan inspisere ditt miljø. Det er gode gamle redaktør, den vi så før. Hva gjør det? Her har vi en backquote uttrykk. Husk dette er C-skall. Så printenv EDITOR vil gi oss en verdi av editor. Det er vi. Og så vil det sette denne verdien til variabelen a, sett kommandoen. Så nå hvis jeg gjør echo $ a, jeg får vi. Det virker ikke veldig nyttig. Men det gjør faktisk har en hensikt. Siden vi ikke vet om en variabel er et skall variabel eller en miljøvariabel ved å bruke dollartegnet evaluering syntaks, kan vi bruke printenv å sørge for at det er en miljøvariabel. Så hvis det var et skall variabel redaktør, dette ville ikke ha fått det. Dette fungerer bare med miljøvariabelen. Hvis det var et skall variabel og jeg ønsket sin verdi, Jeg måtte finne en annen måte å gjøre det. En måte å gjøre det ville være ved å gjøre settet og piping. Dette er en av de metategn, spesialtegn. Det sender resultatet av settet til noe annet. La oss se hva vi kan finne der. Ingenting. Ok. La oss bare se hva som er der alle sammen. Det var echo_style, den jeg nevnte tidligere. Ok, la oss gjøre det. Husker jeg nevnte tidligere, echo_style bestemmer hvordan ekkoet kommandoen vil kjøre. bsd står for Berkeley Standard Distribution. Dette er Berkeley Unix fra 1970-tallet. Det er en av måtene som ekko kan kjøre. Innstilling echo_style til at verdien i TC-shell vil føre ekko å oppføre seg på den måten. Så sett gjør det, men satt bare får skall-variabler. Det ville ikke finne EDITOR, som ikke er et skall variabel. Ingenting. Så det er en måte å skille dem. Men det faktum at du må gå gjennom noen merkelige kommando sånn å skille mellom skall-variabler eller miljøvariabler viser den type upraktisk arten av den C-skall for enkelte formål. Og nå, sist, og kanskje minst, er dette mannen sidene. De av som du kanskje vet, er mannen kommandoen kort for manuell. Manual-sidene for skjellene er vanskelig å lese. De er veldig lang. De er organisert på en måte som kan gjøre det vanskelig å finne det du leter etter. Så hvis du leter etter noe med en hensikt, du kan ikke vite om at formålet er et skall variabel eller noe annet, så du kan ikke vite hvor du skal lete etter den. Du kan søke etter ulike strenger, men strengene er ofte gjentas. Så det er generelt vanskelig å lese. Vi bare så på TC-shell mannen siden litt før for å finne den eval kommando. Noen ting går raskere. En tilnærming er å søke etter en streng. Du kan bruke personsøker. Personsøker har skråstreken for å se etter en kommando eller en streng inne i en personsøker operasjon. Man som standard vil bruke personsøkere, enten være mer eller mindre. Jeg vet ikke om du er kjent med dem, men de kan vise filer litt etter litt. Jeg har brukt mindre å vise akkurat disse filene vi har fått her. Du kan søke inni der. Du kan prøve å bruke ulike søkestrenger. Også manulene i ulike operativsystemer kan ikke være det samme. De kan være egne sider for csh og tcsh. De er ikke på Mac, men de kan være hvis de er separate kommandoer. Hvis sh ikke egentlig kalle Bash, det sannsynligvis ville være en egen mann side. Noen systemer har egne man-sidene bare for C-skall innebygde kommandoer. Noen ganger hvis du ønsker å lese en beskrivelse av en innebygd kommando det er også i banen, som ekko, må du lese man-siden på den kommandoen på ekko å bestemme hvordan den vil fungere som en innebygd kommando selv om du ikke kaller den innebygde kommandoen. Det er en ulempe av operativsystemet generelt, ikke bare for skjell, selv for skjell i særdeleshet mannen sidene er ganske lang, dels fordi de har lagt nyttige funksjoner til dem, noe som kan være en positiv. Ok. Er det noen spørsmål? Eventuelle emner du ønsker å ta opp? Noe relevant her? Vel, det har vært veldig hyggelig å snakke med dere alle. Jeg håper du fikk noe ut av dette seminaret som vil være nyttig for deg i din fremtidige bestrebelser. [CS50.TV]