[Seminar - Unix Skaller, Environments] [Douglas Kline - Harvard University] [Dette er CS50. - CS50.TV] Dagens emne er Unix shell. Jeg er Douglas Kline, ekspert eller i det mindste rimeligt kompetent bruger af skallen. En Shell er grænsefladen for brugeren til computerens operativsystem. Navnet er misvisende som, i modsætning til et dyrs shell, der er hård og beskyttende, computer shell giver mulighed for kommunikation. Så porøs membran ville nok være en bedre metafor. Den oprindelige shell til Unix er Bourne shell. Bourne er stavet B-O-U-R-N-E. Bourne var en af ​​de oprindelige forfattere af Unix, og så skallen er opkaldt efter ham. Navnet på denne skallen som en kommando er simpelthen sh. Det er den kommando, du kan udføre. Skallen starter ved login. Når du logger på computeren, skallen bare begynder at køre for dig, og det er hvad tager dine kommandoer. Det kan starte på andre tidspunkter også. Hvis du sætter op et vindue med ingen anden angivelse, vil det starte en shell for dig. Det er, hvordan det er, at du kan gå til et vindue og begynd at skrive kommandoer og så videre der, selvom du ikke logge ind på det vindue. Hertil kommer, at hvis du gør en remote login, så vil det starte en shell på fjerncomputeren. Og det er muligt at køre kommandoer uden en interaktiv shell. Det kan betyde i din nuværende drift, og det kan også betyde en fjernbetjening. Du kan sende en kommando til en anden computer, som omfatter etablering af en shell der. I virkeligheden, det har at omfatte opstart af en shell der selv om det ikke er din endelige formål. Når noget starter op som dette, er det ikke nødvendigvis starte en ny shell. Hvis du sætter et nyt vindue, er det muligt at fortælle det at opdrage en redaktør eller en anden kommando. I så fald, vil redaktør starte fra bunden. Når redaktøren slutter, vinduet slutter. Dette er lidt usædvanlig, men det kan gøres. I disse tilfælde vil det ikke være en shell. Så det er ikke nødvendigvis tilfældet, at et vindue eller nogle sådan ansøgning vil bringe en shell. Shell parser kommandoer. Tolker betyder at identificere de forskellige elementer og klassificere dem. Inden for en kommando, den fuldstændige streng, du skriver, vil der være 1 eller flere enlige kommandoer, der skal udføres. Andre elementer kan være argumenter. Der kan også være særlige tegn, som påvirker udførelsen af ​​en kommando. De kan sende output et andet sted end skærmen hvis kommandoen normalt ville sende den til skærmen. Det kan omdirigere input, og det kan gøre andre ting også. Der er forskellige andre symboler, tegn og så videre. Tolker indebærer påvisning og fortolkning af disse ting. Nu, hvis der ikke er flere spørgsmål, som er temmelig sandsynligt, da der ikke er flere mennesker, vi vil gå videre til mit næste side her. Jeg sagde tidligere, at Bourne shell er den første skallen. Der er andre. Den ene er den C-shell. Kommandoen er csh. Navnet C-shell er bare en leg med ord. Denne shell blev indført med Berkeley Unix i midten af ​​1970'erne. Berkeley Unix var en skelsættende begivenhed i udviklingen af ​​Unix. Det var en kæmpe revolution og omfattede indførelsen af ​​denne shell. Grunden til, at ordspil, C-shell, er, at C-shell har nogle karakteristika i det, der ligner C sproget, hvor Bourne skal ikke har - eller det havde ikke på det tidspunkt. Der er også TC-shell. Dette er en overordnet af C-shell. Det har yderligere funktioner, hvoraf mange er egnede til interaktiv brug, såsom minder kommandoer i historien mekanisme, som jeg vil beskrive noget senere - på en enkel måde, modelleret efter en editor. Det har også bindinger, som giver dig mulighed for at binde en kort nøgle snor til en længere kommando. Vi kommer ikke til at være at få ind i dag. Det har nogle funktioner, der er nyttige for programmering. Imidlertid er C-shell ikke ofte brugt til shell programmering. Shell-programmer, hvis du ikke allerede kender, er programmer, der består af shell egenskaber. Du kan køre disse som programmer. Du skriver en masse shell-kommandoer i en fil og udføre filen. Du behøver ikke at kompilere den. Dette er en fortolkende sprog. Sætningen C-shell er nu uklart, da det kun kan henvise til den oprindelige C-shell, CSH, eller til alle C-skaller, herunder tcsh. Det er lidt tvetydig. En senere Shell er Korn shell, ksh, opkaldt efter den programmør, Korn. Skallen har forsøgt at inkorporere 1 shell fordelene ved C-shell til interaktiv brug og Bourne shell til programmering. Det har været brugt som en interaktiv shell af nogle mennesker - et mindretal. Senere var der dog en anden introduktion, Bash shell, BASH, igen et ordspil, Bourne-igen shell. Det er en udvidelse af Bourne shell. Korn-shell er også. Begge af dem er. Det har de samme målsætninger for Korn-shell for sammenlægning C-Shell og Bourne Shells fordele 1 Shell. Mange af de forbedringer af Korn shell er også inkluderet i Bash. Bash, har dog mere og er derfor at foretrække. Bourne-igen Shell og Korn shell kaldes Bourne-type skaller fordi de omfatter Bourne skal karakteristika, der er uforenelige i visse henseender med C-skaller. Der er andre skaller udover dem, nogle er beregnet til begrænset brug, måske er begrænset til nogle kommandoer, måske specialiserede formål, ikke ofte brugt. Okay. Næste punkt på dagsordenen her. Det Bash shell er blevet forbundet med forskellige former for Linux. Jeg er ikke sikker på, om det er rigtigt af enhver form. Der er mange former derude, og jeg har ikke brugt dem alle, men i dem, jeg har brugt det er blevet forbundet med det. Så vidt jeg ved, er der intet om Bash hvilket gør det mere kompatibelt med Linux end nogen anden kombination af skallen og operativsystem. Jeg tror, ​​det nok bare afspejler tilbøjeligheder programmører. At det er blevet forbundet med Linux er en anden grund til at foretrække Bash at ksh da tingene er tilbøjelige til at være skrevet i det, og det er sandsynligt, at sprede sig. Jeg vil give dig andre grunde til det senere. Bourne shell scripts skal køre under Korn shell eller Bash. Hvis du skriver noget for Bourne shell, du kan sikkert udføre det under ksh eller bash. Korn shell scripts vil formentlig køre under Bash, men jeg kan ikke garantere det. Senere her, bør C-shell scripts køre under TC-shell. C-shell var faktisk aldrig flittigt brugt til scripting eftersom Bourne shell og senere Bourne-type granater var at foretrække til dette formål. Så det er virkelig ikke så vigtigt. Der er en hel masse af Bourne shell scripts, der blev skrevet for længe siden, før Korn shell eller Bourne-igen shell blev indført. De er stadig i brug, en del af de operativsystemer, og så vil du finde dem, hvis du kigger ind i operativsystemet eller nogle gamle programmering pakker. Bash er til en vis grad ved at blive en slags lingua franca for operativsystemer. Det er allerede blevet udvidet til Windows og til FOS. VMS, hvis du ikke kender, er et proprietært operativsystem af Digital Equipment Corporation, som stadig er i brug, i vid udstrækning bag kulisserne. Og hvis det kommer til at køre på flere forskellige operativsystemer, sandsynligvis de mennesker har en tendens til at flytte til det. Men denne udvikling er noget relativt nyt. Det er lige begyndt, så jeg kan ikke forudsige, om dette vil vise sig at være virkelig den slags lingua franca. Også, fordi fil stinavne og biblioteker er forskellige mellem disse forskellige operativsystemer, du måske ikke være i stand til at skrive en Bash script på et operativsystem og derefter køre den på en anden. Du bør være i stand til at flytte den mellem forskellige Unix, Linux Mac OS-styresystemer, men ikke nødvendigvis til Windows eller VMS. Du har måske til at ændre Filstinavnet beskrivelser, og nogle biblioteker kan være anderledes, som kan påvirke den måde, at nogle kommandoer arbejde eller hvordan de behandler argumenter og lignende. Hertil kommer, at en anden advarsel her er, at der ikke er nogen garanti at alle de forskellige skaller jeg har nævnt - Bourne shell, C-shell, TC-shell, Korn shell, Bourne-igen shell - vil være tilgængelig under nogen Unix eller Linux eller Mac OS computer. De kan simpelthen ikke være der. Det er en af ​​de advarsler her. Det er en uheldig begrænsning her siden du gerne vil tingene til at fungere overalt, men desværre kan du ikke stole på det. Okay. Næste en her. Lad os sige, at du ønsker at skrive en shell script, et program, der består af shell-kommandoer. Du skriver dine kommandoer, læg dem i en fil og udføre filen. Hvad hvis du ønsker at medtage argumenter? I tilfælde af shell operationer er argumenter kaldes parametre eller positionelle parametre og de vil blive kaldt af et dollartegn og tal, $ 1, $ 2. Så hvis scriptet har dette navn, kan mit første argument være argument 1 og min anden kunne være argument 2, og inde i mit script, hvis jeg ønsker at henvise til disse ting - lad os slette dette, da jeg ikke rigtig kommer til at køre det - inde i mit manuskript, jeg har måske $ 1 for at henvise til arg1, $ 2, som vil komme ud på den måde, arg2. Så disse symboler er til rådighed til at henvise til argumenterne, og dem, gælder for alle de skaller. Desuden er der andre tegn. $ * Refererer til hele argumentet listen, dem alle. $ # Refererer til antallet af argumenter. Igen, dette gælder for alle de skaller. Disse symboler, * og #, kan bruges med disse betydninger i andre steder også. Vi vil ikke komme ind i det. Shell specificerende linje. Hvad er den til? Lad os sige, du har skrevet et script, og det er for en bestemt shell, og du ønsker at køre den. Hvordan kan du vide, hvad shell dit operativsystem vil bruge til at køre dit script? På et tidspunkt kan du antage, at det ville køre det i Bourne shell hvis du ikke siger noget andet, men folk er ikke at skrive scripts i Bourne shell, meget længere og du kan ikke engang stole på længere. Så her har vi en shell specifier linje lige her. Der angiver Bash. Bemærk, at det præciseres det i stinavnet, / bin / bash. Hvis en computer har Bash shell, men ikke i bin, / bin, det vil ikke fungere. Det er en anden kvalifikationskamp, ​​en anden forsigtighed her. Pundet tegn er kommentaren linje karakter. Det gælder for alle skaller. Den særlige tilfælde her, #! i starten af ​​et script, er et særligt tilfælde. Der angiver skallen til at køre scriptet. Som jeg sagde, kan det ikke være det samme sted / bin. Derudover er der en anden ting her. Hvis du bare bruge havelåge uden udråbstegn og stinavn, der skal angive et C-shell. Men jeg ikke anbefale at gøre det, fordi jeg ikke er i stand til at garantere, at der altid vil arbejde. Hvis du vil have en C-shell, ville det være bedre at sige det. Så er der noget temmelig forvirrende her. Hvis du bruger en shell specifier linje som / bin / bash og at Shell ikke er tilgængelig der, Der er ikke sådan noget som / bin / bash på den pågældende computer, enten fordi det ikke har Bash, eller fordi det er i en anden placering, får du en fejl, fortæller dig, at det script, du kørte ikke eksisterer. Og selvfølgelig eksisterer dit script, så fejlmeddelelsen er forvirrende. Grunden til, at operativsystemet giver dig denne fejl eller mere præcist, at din interaktiv shell, hvor du kører det giver denne fejl, er, at det rapporterer den kommando, du brugte, som er navnet på scriptet. Denne kommando effektivt kaldes skallen ved navn scriptet. Det er, hvor du får det forvirrende fejlmeddelelse. En anden måde at kalde shell script er ved at angive skallen på kommandolinjen, som her. Dette er en kommando. Det siger køre Bash og derefter køre mit script i Bash. Det vil tage forrang en anvisning linje, og dette har den funktion at tillade dig at sørge for varierende stinavne. Hvis du bare give en kommando, vil styresystemet kigge efter, at kommando forskellige steder. Hvis den er tilgængelig, hvis den finder det. Computeren vil finde Bash uanset hvor den er placeret, og køre den, så du behøver ikke så at være bekymret over, hvor det finder det. Der er potentielt andre bekymringer her, som om der er mere end 1 version af Bash, hvilket er muligt omend usandsynligt. Så det er en anden måde at beskæftige sig med disse ting. Anvisning linjer kan kalde enhver shell. De kan også ringe til andre end skaller ting. Eksempler, jeg har her, er sed, der er åen redaktør; awk, hvilket er et mønster-sprog; og perl, en meget højt udviklet scriptsprog. Hvis du sætter en specificerende linje angiver et af disse programmer i begyndelsen, det vil gå direkte ind i dette program frem for at starte en shell. Disse programmer har grænser for deres evner. Perl er meget dygtige. Sed er en editor. Det kan gøre ting end blot at redigere. Men det kan være vanskeligt at programmere det. Desuden passerer argumenter og ting til at script er enten umuligt eller forvirrende. Så i de tilfælde, med awk eller sed, det er, i hvert fald i min erfaring, foretrække at skrive en shell script og call awk eller sed fra shell script snarere end at ringe awk eller sed som scriptet specifier linje. Perl er en meget alsidig sprog, som jeg sagde. Du kan ikke køre interaktive kommandoer i perl, hvilket betyder at du ikke kan teste dele af scripts, som du udvikler ved at køre dem interaktivt. Men det er en yderst stand sprog og har udviklet sig til et meget udbredt værktøj. Det er bare en lille smule af en parentetisk bemærkning om anvisning linjer. I alle eller de fleste former for Linux - igen, 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 får du bash. De forsøgte der for at give dig de mere avancerede versioner af disse skaller, men det kan være forvirrende. Hvis du skriver et script ved hjælp tcsh eller Bash funktioner mens ringer csh eller sh og derefter prøve at køre det på en computer, som ikke har tcsh eller Bash, kan du få nogle fejl, hvis der er kommandoer derinde som disse skaller ikke kan genkende. Derudover kan du have kaldt din shell på din lokale computer kalde det som sh eller csh og derefter få de mere avancerede skaller. Du må ikke engang tænke på det faktum, at du bruger de mere avancerede shell. Så dette er en potentiel faldgrube. Hvordan er det fastslået, at hvis du skriver sh du får Bash, hvis du skriver csh får du TSCH? Der er ting i disse computere kaldes links som kan forbinde til filnavne til at henvise til de samme ting. Det kan enten være 2 navne for den samme eller en fil, hvis formål er at henvise til en anden fil. De kaldes hårde og symbolske links. Vi vil ikke gå ind i det længere i dag. Der kan også være separate filer - 1 fil sh, 1 fil Bash - men de begge køre Bash. Så er der en anden kvalifikationskamp her. Hvis du ringer en af ​​disse granater ved et navn, du måske tror, ​​du ville få den samme funktionalitet som at kalde det et andet navn. Tja, der faktisk er ikke nødvendigvis sandt. Disse kommandoer kan undersøge det navn, som de blev kaldt og de kan på grundlag af samme navn, opfører sig anderledes. Der kan være spørgsmål om at forsøge at svare til en standard. Nogle af jer har måske hørt om POSIX-standarden eller en anden, måske andre funktioner. Dette kan vælges undertiden ved kommandolinjeargumenter eller ved at shell-variabler. At kalde det som sh eller bash kan faktisk føre til et andet henrettelse selvom det er den samme fil, som du udfører. En anden ting at overveje, er, at selv hvis en anden computer har tcsh eller Bash, hvis de ikke er forbundet som de er på din lokale computer hvis du har en Linux eller Mac OS lokal computer, så igen, du får skallen som du kalder sh eller csh, ikke den ene, som du måske foretrækker. Den nuværende Bourne shell har forbedringer mindre end i Bash men forbi dem i den oprindelige Bourne shell. Som et resultat af, at selv den nuværende Bourne shell, sh, selv når det ikke er Bash, ligner C sproget mere end C-shell gør. Det var ikke tilfældet, når C-shell først blev oprettet, men det har udviklet sig på den måde. Du vil måske bemærke her, at alle disse tomme navne bortset fra Bourne skal har noget at angive, hvilken shell de er - csh, bash - men Bourne shell er lige sh. Hvorfor? Det var den oprindelige shell. Det var skallen så, ikke en skal, og da det var skallen, var der ingen grund til at skelne den fra en anden skal. Så det er derfor det har det navn, og stadig gør. Denne top her er der en linje fra en password database for en konto, jeg har der på en anden computer. Jeg har tænkt mig at forsøge at få det navn, så du kan se, at en del i slutningen, skallen. Databasen kodeord holder login egenskaber for alle brugere. I begyndelsen er det brugernavn, som du kan se de sidste 2 bogstaver af mine nu. Felterne her er adskilt af kolon. Det sidste område, som du kan se, er bin / tcsh, skallen. Det er skallen anvisning. Der er noget interessant her. Da Unix blev først udviklet, var der kun 1 skal, så der var ingen valg der. Så hvorfor de tillader et felt i databasen adgangskode for at angive en shell? Jeg ved det ikke, men det er heldigt, at de gjorde. Det er temmelig vanskeligt at foretage ændringer i password-databasen format fordi mange programmer henvise til sit format og skulle skrives om. Det er en heldig eller tilfældig udvikling, de omfattede dette område. Den slags en password fil linje bruges på alle Unix og Linux-computere, så vidt jeg ved. Mac har sit eget system. Det har faktisk en adgangskode fil med de linjer i dette format, men det er ikke hvor brugeren karakteristika defineres. En anden parentetisk bemærkning der. Hvis du ringer til en shell, kan du kalde det som en sub-shell af dine eksisterende skaller. Så hvis jeg går her, lad os slippe af med disse ting. Her er jeg i C-shell. Denne variabel, som nøjagtigt identificerer min shell, faktisk ikke altid er en pålidelig måde at afgøre, hvad shell du kører, men i dette tilfælde er det. Hvad hvis jeg bare skrive - Nu er jeg i Bash. Nogle ting kommer til at være den samme. ls fortæller mig mine kommandoer. Hvis jeg gør en suspendere tilbage til mit C-shell, ls, samme. Right? fg, forgrunden, tilbage til min Bash shell. pwd, aktuelle mappe, tilbage til C-shell. pwd, andet bibliotek - faktisk ikke en anden mappe i dette tilfælde. Det er det samme bibliotek. Lad os sige, at jeg vil ringe til en kommando her: Hvor ls. Hvad betyder det så? Det fortæller mig, hvor de ls kommandoen, den, der giver mig en mappe notering, er beliggende i ls. Lad os gå tilbage til Bash shell. Lad os prøve det samme. Hmm, interessant dér, hvor: kommando ikke fundet. Hvorfor er det? Den hvor kommando er indbygget i C-shell. Dette er ikke en kommando, der skal læses ind i hukommelsen fra et andet sted og henrettet. C-shell kører det ved at overføre fuldbyrdelsen til en del af sin egen kode og det er ikke i Bash shell. Så Bash, der ikke har en sådan indbygget kommando, ser for det, finder det ikke, og vi får en fejl. Så der har vi en Bash shell kører under en C-shell, og vi kalde det en sub-shell. Og bare i tilfælde af at du er nysgerrig, Bash shell har sin egen måde at lokalisere kommandoer. hash'et henviser til det faktum, at det kan udføres hurtigere, blive fundet hurtigere. Det er en af ​​de forbedringer, der er indbygget i nogle af disse skaller. Bourne-type skaller foretrækkes til programmering. De har kontrol strukturer som løkker, betingede udsagn, den slags kommandoer, som du kan bruge i programmeringssprog som C eller hvad sprog. Måske er du programmering i Java eller hvad. Skaller har dem også. Bourne-type skaller, især Bash, har mere og de er designet med større fleksibilitet. Det Bash shell har arrays. Den oprindelige Bourne skal ikke. Så det kan være betydeligt fordelagtigt for programmering. C-shell rent faktisk har arrays, men ikke har en masse af disse andre funktioner. Bourne-type skaller vil køre hurtigere hvis de ikke har de funktioner, der er bestemt til interaktiv brug. Du lægger ting ned til ét formål, og dette indlæser dem ned til et andet formål. Der er det trade-off der. De funktioner, som er beregnet til interaktiv brug virkelig er af ringe eller ingen brug for scripting. Det er muligt at bruge en interaktiv sub-shell ligesom den ene jeg startede der at afprøve kommandoer, som du har til hensigt at bruge i et script. Det er, hvad du ikke kan gøre med perl. Du kan gøre det med skaller. Selv de strukturer som for loops og så videre kan køres interaktivt. De er nogle gange nyttigt at køre interaktivt men mere sandsynligt du bruger dem til at udvikle et script. Aliaser. Dette kommer til at være omkring C-shell. Historie mekanisme, hvor du kommer tilbage til tidligere kommandoer eller dele af dem, at du allerede har kørt. Igen, om C-shell, Bourne shell og Korn shell have disse ting, men jeg har ikke tænkt mig at komme ind i dem. Så her er nogle nyttige aliaser, som jeg har. I stedet for at skrive ls - det er en fælles kommando - bare skrive l og spare 1 karakter. ls med forskellige muligheder, alle de arbejde. Bemærk, at disse definitioner har anførselstegn omkring dem. I disse tilfælde, anførselstegn er ikke nødvendige. Hvis du kan definere disse aliaser uden anførselstegn, ville det stadig arbejde. De anbefales. Der er situationer, hvor du ikke kan bruge citatet fordi du vil have noget til at ske, som citatet ville forhindre. Nogle gange kan du citere en del af definitionen, men ikke det hele. Det er også generelt anbefales at bruge apostroffer snarere end dobbelt anførselstegn. Anførselstegn have indvirkning på variable definitioner, især får dem til at blive evalueret stedet for at stoppe den. Hvorfor skulle vi ønsker at stoppe evalueringen? Og hvordan gør citater gøre det for os? Her er en kommando, som du måske vil finde interessant. 'Ls g *' g *, som du sikkert ved, er et wildcard udtryk for alle de filnavne, der begynder med g. Hvis jeg bare skrive i en kommando ls g *, får jeg en liste over alle disse navne i min nuværende bibliotek. Hvis jeg definerer som alias, da det er her med anførselstegn, det vil køre denne kommando i din nuværende bibliotek, hvor du kører det. Men hvis du kører aliasdefinitionen uden anførselstegn, det vil evaluere wildcard g * når den kører dette afgørende kommando. Så definitionen af ​​alias vil blive ls efterfulgt af liste over filer i mappen hvor alias kommandoen er udført, uanset hvor du rent faktisk har til hensigt at køre kommandoen. Dette er ikke til megen nytte, og de enkelte anførselstegn forhindre evaluering af stjerne. Så du bare få definitionen væsen ls g *. Så når du kører alias LGS, det så sætter den ud. Nu er der ingen citater, og det vil evaluere stjerne, når du kører alias kommando. Så det er én ting. Anførselstegn ville have den samme effekt her, men der er andre tilfælde, hvor dobbelte anførselstegn ikke ville fungere så godt. Her er en anden. Du kan kende den grep kommando. Den grep kommando kan bruges til at scanne en fil til linjer, der har visse strenge. Så lad os gå over her, og jeg vil forlade min Bourne shell. Okay. Her er en fil. Lad os sige det er grep abc strenge. Der er det. Hvis jeg gør grep zddd, får jeg ingenting. Okay. Så det finder en streng, rapporterer, at det ikke finder, at det ikke rapportere det. Det udgange enhver linje, som har denne streng på den. Der er alle mulige muligheder her, som du kan finde i dokumentationen. Her er en måde at gøre det. Hvad med denne ene, alias grabc 'grep abc'? Det kommer til at omfatte 1 argument, når aliaset er defineret. Så hvis jeg gør det her, nu, hvis jeg gør grabc, nu alias omfatter mere end den simple kommando. Det har også argumentet. Hidtil der virker. Jeg har en anden kommando her, denne ene, så dem er forskellige strenge derinde og vise, at dette ikke finde noget der, da det ikke passer. Hvad hvis jeg ønsker at lade definitionen alias den fil, som jeg har tænkt mig at søge og jeg ønsker at give som et argument til alias den streng, jeg leder efter? Jeg vil måske sige abc som argument til mit alias, men aliaset allerede fastlagt filen. Og det er her, dette udtryk kommer i. Bemærk her har vi grep ligesom før. Vi har filen her, strygere. \! ^, Sådan en mærkelig udtryk, formoder jeg, hvis du ikke har set det før. Udråbstegn er en del af C-shell historie mekanisme. Det kan huske tidligere kommandoer, kan det huske argumenter for de kommandoer og så videre. Historien mekanisme bruges som en del af aliasing. Hvis du angiver en linje efter udråbstegn, vil det henvise til denne linje i historien listen som vi ikke vil komme ind nu, da det er en helt anden emne. Det er muligt at angive en del af en linje. Så! 03:02 ville være det andet argument kommando nummer 3. Indsætningstegn her i dette udtryk står for det første argument. Hvis du ikke giver det en indikation af, hvilken kommando du refererer til, det henviser til det umiddelbart foregående kommando, og indsætningstegn er et symbol for det første argument. Fordi det er indsætningstegn og ikke antallet, behøver du ikke behøver at bruge kolon, så ^ betyder! det første argument til den forrige kommando. Lidt blandet op her. I dette tilfælde, når du bruger dette som et alias definition, historie henvisningen refererer tilbage til de kommandoer, hvor alias anvendes. Så dette går tilbage 1 kommando som en historie operation, men som et alias operation det refererer til den kommando, som du ville skrive, sige, grstrings_file. Vi har de citater her i det. Hvad er backslash efter? I dette tilfælde, som andre steder, vi ikke ønsker at udføre historie mekanismen samtidig med at definere alias. Hvis vi ikke har omvendt skråstreg der, ville skallen trække i det første argument af kommandoen lige før det løb denne alias kommando, som vi ikke ønsker. Vi ønsker, at dette skal bygges i den alias kommando til at ringe i et argument senere. Enkelte citater ikke undslippe et udråbstegn, historien reference. Måske kender du udtrykket flugt betyder at ændre betydningen af ​​noget. I dette tilfælde betyder det, at stoppe noget fra at have en særlig betydning. Udråbstegn særlige betydning er historie. Flygte, og det ikke har denne betydning. Citater ikke gør det, backslash gør. Så vi faktisk bruger 2 niveauer af undslippe her. Jeg har tænkt mig at flytte denne kommando ind i det andet vindue uden at skrive det ved hjælp af disse redigering, som du kan finde nyttige. Noget andet her skal jeg vise dig. Hvis du bare skriver alias uden argumenter, det fortæller dig alle dine argumenter. Dette er en flok aliaser Jeg havde allerede her udover dem, som jeg har brugt her i dag. Men hvis jeg bare skrive med navnet på et alias, det fortæller mig, hvad det betyder. Bemærk, at citaterne er væk, og den backslash er væk. Denne streng her er resultatet af denne Aliasdefinitionen, og nu har bare! ^ i det. Dette kommer til at se i filen strenge til noget. Så hvis jeg gør grstrings_file strygere, jeg ikke give det noget at kigge efter der, men det ser i strenge. Det gjorde ikke finde ordet strenge i filen strenge, men det gør finde abc. Og det gør ikke finde det. Så her giver vi et argument, der rammer ind i definitionen af ​​alias der er indsat i den. Det er, hvor dette udtryk kommer fra. Du kan bruge mere end 1. Indsætningstegn er et symbol for det første argument. Hvis du ønskede at bruge et andet argument, ville du så sige: 2.. Der er ingen særlige symbol for det andet argument. Og fordi du bruger et tal, ville du nødt til at bruge kolon. Der er imidlertid et andet valg her. Den dollartegn står for det sidste argument. Og fordi det er et symbol, kan du udelade tyktarmen. Så det ville være det sidste argument i listen. Og der er også den der. Asterisk betyder alt, så dette er den komplette argument listen og igen, kan du udelade tyktarmen, fordi det er ikke et tal. Jeg håber du er alle observere alt dette. Historie mekanisme kan gå tilbage til tidligere linjer i historien listen. Du kan gøre dette i et alias definition. Jeg har aldrig set dette gjort. Det ville have den virkning at trække tidligere kommandoer fra oversigtslisten når du udfører alias, som kunne være forskellige kommandoer afhængigt af hvornår og hvor du udfører det. Tænkes du måske ønsker at trække sig ud en sådan henvisning bare at vide, hvad en tidligere kommando var. Jeg har aldrig set det ske. Jeg formoder, nogen vil måske, men det er meget usandsynligt. Der er en anden ting her. Hvis du bruger denne historie-typebetegnelse, så kun de argumenter, hvor der er en sådan henvisning er brugt. Hvis du har et alias definition, som ikke bruger en historie-typebetegnelse, hvis det blot bliver begyndelsen af ​​kommandoen og du har yderligere argumenter, så alt hvad du skriver, efter at vil blive føjet til kommandoen. I dette tilfælde, det eksempel jeg lige gav der, vi brugte det første argument; vi ikke bruge nogen andre. Hvis andre argumenter havde fået på kommandolinjen, ville de ikke blive brugt. Så hvis du bruger historien henvisningen på alle, så skal du bruge det til at få noget argument. Der er en anden ting her vil jeg blot nævne, dels i parentes, nemlig at denne historie mekanisme med udråbstegn går tilbage til den oprindelige C-shell. Tcsh introduceret historie operationer der anvender den slags kommandoer og strygere fra redaktionen, enten Emacs eller VI. Min personlige mening er Emacs er meget lettere at bruge til dette formål selvom du bruger vi til din almindelige redigering. Der er forskellige Emacs-kommandoer, som nu er tilpasset til historien. Kontrol P får den forrige linje i historien listen. En anden Kontrol P får du den ene før. Pil op gør det samme. Kontrol N får den næste kommando, hvis du allerede har rullet tilbage nogle måder. Pil ned gør det også. Du kan gå til venstre til højre med pilene og forskellige andre ting. Dette kan gøre brug af historikfunktion meget nemmere end at bruge udråbstegn syntaks, men du ville ikke bruge det i et alias definition. Vi vil gå over, at en anden gang. Variabler. Du ved, hvad variabler er i programmeringssprog. Skallerne har dem også. C-shell bruger kommandosættet at tildele variabler så sætter variablen a værdien af ​​b - som jeg sagde, en ubrugelig definition, men en illustration af, hvordan det bliver brugt. Den indstillede kommando vil oprette en variabel, hvis den ikke allerede findes. De positionelle parametre for shell scripts kan betragtes som variable, men brugen af ​​dem, og reglerne for dem er noget anderledes. Du kan ikke tildele en værdi til $ 1 i løbet af et script. Du ville have til at definere en ny variabel til dette formål, hvis nogle af jer ville. Type sæt med nogen argumenter, og du får en liste over alle de aktuelt definerede variable. Og lad os komme over til min anden shell her og se, hvad vi får, hvis vi gør det. En ganske lang liste der, right? Rul op en lille smule. Kig på alt det der. Nogle af disse ting er defineret automatisk af skallen. Skallen skaber de variable og giver det en værdi. Nogle af dem er defineret af skallen, men derefter omdefineres af brugeren ifølge hans præferencer. Og nogle af dem er skabt af brugeren afhængigt af, hvad han laver den dag. Det er bare sat uden argumenter. Der er en ulige funktion her af denne ting. Der er nødt til at være enten ingen mellemrum mellem lighedstegnet og variabelnavnet og værdien eller rum på begge sider af lighedstegnet, som i denne. Det vil ikke fungere, og dette rent faktisk er en gyldig kommando men det vil ikke gøre, hvad du har til hensigt. Denne kommando vil arbejde, fordi hvis du bare sige sæt og en variabel navn uden lighedstegn eller sæt og et variabelnavn med et lighedstegn og ingen værdi, det vil sætte variablen til en null-værdi. Så sæt a = er en gyldig kommando. Sættet Kommandoen kan definere mere end 1 variabel på samme linje. Så denne kommando her har den virkning at definere både a og b til null værdier. Sandsynligvis ikke, hvad du ønsker. Denne ene her, nævnt tidligere, vil føre til en fejl fordi = b er ikke et gyldigt udtryk. En variabel navn kan ikke begynde med lighedstegnet. Og der er disse yderligere ting her. Koloner blev brugt til at vælge argumenter fra historik-linjer, og de kan anvendes - og jeg ikke gå ind i før - for at ændre disse ting. De kan også anvendes til at modificere shell-variabler. Denne ene her, $ a, har en værdi. : R vil tage ud en udvidelse. En udvidelse vil være noget efter en prik, en prik og alt efter det i slutningen af ​​en fil, kun ved afslutningen af ​​listen efter den sidste skråstreg. Så jeg har det her. a er det. Det vil droppe. O.. Hvis der ikke er nogen forlængelse, kun stinavne efter sidste skråstreg, vil det ikke have nogen effekt. a: h, at variable udtryk, vil tage ud det sidste element i en oversigt, igen, kun efter den sidste skråstreg. Så / a / b / c bliver / a / b, men denne ene er ændret, fordi elementet efter listen er nul. Her er der noget, som jeg også vil fremhæve. Disse kvalifikationskampe ikke søge efter eksistensen af ​​disse filer. De ser bare for strygere. De har til formål at manipulere filnavne stinavne, men de kan bruges på enhver streng, selvom det ikke er et filnavn. Og de ser ikke for eksistensen, så hvis der er ingen sådan fil, / a / b / c, det vil stadig fungere. Uanset om det er til nogen nytte er et andet spørgsmål, men det vil stadig arbejde. Variabler er forskellige i de Bourne skaller. Vi vil komme til senere. Dollartegn kan undsluppet ligesom udråbstegn og stjerne. Dollartegn kan slap med en omvendt skråstreg eller enkelte anførselstegn. Anførselstegn har den ulige virkning i alle skaller at tvinge evalueringen af ​​et dollartegn variable udtryk. Så hvis det bliver flygtede den ene vej, kan de dobbelte anførselstegn have den virkning for at forårsage det til at blive evalueret alligevel. Det er lidt forvirrende. Hvis der er flere niveauer for at undslippe, såsom enkelte anførselstegn inde anførselstegn eller dobbelte anførselstegn inde apostroffer, skal du prøve at se, hvad der vil ske til en variabel, hvis du bruger en. Disse 2 situationer - dobbelt inde i single, enkelt inde i dobbelt - ikke nødvendigvis give dig det samme resultat. Miljø variabler, der er bundet C-shell variable. Miljø variabler er også variable i C-shell, og de er også variable i andre skaller også. I C-shell, er de forskellige sæt. De ting, jeg sagde før er omkring shell-variabler. Variabler miljø er et bestemt sæt af variabler med undtagelse af en række variabler, som vi kalder bundne variabler, som er meget vigtige, og vi vil komme ind i dem senere. Miljø variabler automatisk videre til skaller eller kommandoer, der kører fra din shell. De andre ting er ikke. Skallen variabler, kaldenavn er ikke. Miljø variabler er. Det er derfor vi kalder dem miljøvariabler, Ideen er, at miljøet strækker sig forbi netop din nuværende shell. De kan bruges til at definere ting for kommandoer. Her er et eksempel. PRINTER, LPDEST. Begge disse variabler kan definere en printer, en kommando vil bruge til at udskrive ting. Hvis du har flere printere rundt, kan du ønsker at sætte en du kan lide. Grunden til at vi har 2 variabler er, at forskellige sæt af kommandoer blev skrevet ved hjælp af disse forskellige variabler. Du kan give dem forskellige værdier. Mest sandsynligt, du vil give dem begge samme værdi. Disse ting arbejde, fordi de kommandoer, der gør udskrivning var programmeret til at undersøge de værdier af disse variabler. Hvis et program ikke blev skrevet på den måde, hvis det blev skrevet for at gøre noget andet, variabel ville være irrelevant. Så styresystemet er ikke på udkig efter disse variabler hver gang du henviser til en printer. En kommando, der gør udskrivning er på udkig efter disse variabler, hvis det er programmeret på den måde. Disse variabler er ofte defineret i dine initialiseringsfiler men ikke nødvendigvis. Du kan definere dem på kommandolinjen. De kan defineres i en kommando. En kommando, der kører noget kunne have sin egen udvælgelse af variabler - variabler, der er unikke for en bestemt softwarepakke, for eksempel. De vil blive defineret, når du kører denne pakke. Hvordan er disse variabler videre til en sub-shell? Når en sub-shell er skrevet, betyder det ikke at skrive ind i dette område. Det område af sub-shell, der er afsat til miljøvariabler er ikke skrevet af sub-shell, det er skrevet af kopiering. Når du kører en almindelig kommando, som disse kommandoer til at udskrive eller hvad, de starter med at oprette en ny shell. Skallen skaber en shell og derefter overskriver en del af det med den kommando, du kører, hvilket er en smule forvirrende, men det er, hvordan disse kommandoer får miljøvariabler at de derefter henvise til senere. Kommandoen her for at definere variable setenv. Det er, hvordan du definerer det. Det er 3 elementer: setenv, variabel, værdi. Hvis du bare setenv uden argumenter, hvad får du? En liste over alle disse variabler. Igen, det er en dejlig lang liste, og i dette tilfælde, som i de andre, disse variabler er defineret i høj grad af mit login drift af selve råtanken snarere end af noget jeg gjorde. Der er en anden kommando her, printenv. At også udskriver miljøet. Bemærk denne sidste ting her, redaktør = VI. Det siger, at hvis jeg bruger noget, der kalder en editor og jeg ikke angiver en editor, og det giver mig valget, kan det give mig VI. Hvad hvis jeg gør printenv Editor? Det fortæller mig, hvad det er. Lige før, at der var en variabel, mindre. Disse er dine defaults muligheder, når jeg kører MINDRE kommando, som viser filer. Så hvis jeg gør det, kan printenv tage 1 argument eller 0 argumenter, ikke mere end 1. Der er andre kommandoer også, men vi kommer ikke til at komme ind i alt, i dag. Husk der var modifikatorer for shell-variabler som: h, som vil slippe det sidste element i en sti, eller: r, vil der falde en forlængelse. Dem, der nu gælder for de miljøvariabler også. De havde ikke vant til. Det plejede at være, de ikke kunne ændres. Nu kan de være. Det er en af ​​de fremskridt med udviklingen i skallerne i årenes løb. Jeg sagde, at skallerne som en del af de miljøer og shell variable i C-shell er, med visse undtagelser, forskellige sæt. Du kan oprette en miljøvariabel og en shell variabel med samme navn. De vil være forskellige variabler, de kan have forskellige værdier. Ændring af værdien af ​​en ikke vil ændre værdien af ​​den anden. Disse variabler er alle evalueres med dollartegn - $ a, $ whatever. Så hvad nu hvis du har det? Har du vide, hvilken en, du får? I min test fik jeg skallen variable, men dette er ikke dokumenteret, og du kan ikke stole på det. Så jeg spørger dig, er at skabe shell og miljøvariabler med de samme navne en god idé? Nej Okay. Hvad er de store undtagelser, hvor miljøet og shell-variabler er knyttet til hinanden? Der er disse 4. Capital brev TERM miljøvariabel, shell variable udtryk i små bogstaver, type terminal emulering. Jeg vil bare gå over her, og jeg har tænkt mig at gøre ekko, en nyttig kommando her, $ TERM $ sigt. Og der. xterm er en terminal type til vinduer vises i X Window System. xterm-farve er en variation af den, der tillader forskellige farver. Hvorfor definerer vi disse? Hvad er det godt for? Kommandoer, omarrangere skærmen som redaktør sende bestemte sekvenser, kaldet escape-sekvenser, til en terminal eller et vindue for at omarrangere det og så videre. Disse sekvenser er forskellige for forskellige typer af terminaler. Det fortæller den, hvilke af dem til at bruge. Nogle gange er der spørgsmål der. Du vil måske ændre det. Hvis tingene ikke fungerer, undertiden terminal typen er sat forkert, du kan være i stand til at ordne det ved at omdefinere begrebet variabel. I disse tilfælde ændre en variabel, miljøvariablen eller skallen variabel, bør ændre den anden. Jeg har opdaget gennem erfaring, at ændre TERM med blokbogstaver ikke altid ændre shell variable udtryk i små bogstaver. Dette er en fejl. Jeg ved ikke, om det er altid sandt. Det meste af tiden er det ikke sandt, men det kan være. Så hvis du laver en ændring, bare tjek det ud. Det er ikke ofte, at du har brug for at ændre denne værdi, men en gang imellem, du gør. Miljøvariablen BRUGER. Igen miljøvariablen med blokbogstaver, shell variabel i små bogstaver. Dette er dit brugernavn. Det er kun under ganske særlige omstændigheder at du ønsker at ændre det. Hvis dit brugernavn er en anden, kan det kaste alle mulige ting fra. Hjemmebibliotek, brugerens hjemmemappe. Igen, ville du ikke ønsker at ændre det. Bemærk i alle disse sager og den, som vi er ved at dække, stien variabel miljø-variabel er med store bogstaver, og det bundne shell variabel er med små bogstaver. Hvis du ændrer en, bør du ændre den anden. Denne form for binding kan ikke etableres, som du ikke kan binde 2 variabler, andre end disse 4, og bindingen i disse variabler kan ikke fortrydes, du kan ikke adskille dem. Så disse 4 par variabler er bundet af. De vil altid være. Ingen andre vil være. Desuden ville det være muligt at skabe variabler med samme navn af de modstående typer. Du kan gøre en shell variabel udtryk i små bogstaver eller en miljøvariabel TERM blokbogstaver. Disse variabler vil være uafhængig af disse parrede variabler og de ville være uafhængige af hinanden. Jeg kan ikke forestille mig, hvorfor du ville gøre det, medmindre du ønsker at forvirre folk. Denne ene her, sti variabel, dette er en virkelig vigtig. En anden ting er, at der kan være tilfælde, variabler med lignende Forbundne navne, der ikke er bundet til hinanden. Der kan være variabler, Shell og Shell, i store og små bogstaver. Baseret på det navn, du ikke ved, om denne variabel er en shell variabel eller en miljøvariabel, og de er ikke bundet til hinanden. Så den slags parrede navne er ikke ensbetydende med bundne variabler. Stien variable, som jeg viste før, er en liste over stinavne hvor skallen ser for kommandoer. Lad os komme over til dette vindue her og vi vil gøre echo $ PATH, versaler - miljøvariabel - echo $ sti, små bogstaver - shell variabel. Bemærk, at listen over mapper er den samme. Disse er bundet. Ændre én, ændrer du den anden. I miljøvariablen elementerne er adskilt af kolon. Bemærk, at. Skallen variable er adskilt af mellemrum. Dette miljø variabel er en enkelt streng. Skallen variabel er et array. Bourne shell havde ikke arrays. Bash gør, men det er allerede en fast del af skallen. Dette er en enkelt streng og ikke et array. C-shell altid haft arrays. Opstillingerne er meget nemmere at arbejde med. Du kan henvise til dele af det. Så echo $ sti [1], og jeg får / usr / bin, det første element. Igen, husk dollartegn står for det sidste element i oversigtslisten. Hvad sker der? Det forsøgte at finde dollar tegn som en variabel symbol. Jeg undslippe den. Ups. Det ville ikke tage at enten. Nogle af disse ting ikke fungerer så godt. Måske vil vi bare lade det ud. Asterisk refererer til det hele, men det er, hvad du får, hvis du ikke angiver et element. En anden måde at array-variable kan manipuleres, række elementer der, 7 elementer. Her sætter vi havelåge før variabelnavnet. Her er en anden. Sæt et spørgsmålstegn der. Det er en logisk værdi. Dette indikerer, at variablen eksisterer. Det er en anden måde at arbejde med variabler. Det, ved den måde, behøver ikke at være en array variabel. Det kunne være en hvilken som helst variabel. Og hvis jeg gør det, er der ikke sådan variabel, og jeg får en 0. En anden lille ting der om variable evalueringer. Tilbage til denne ene her, hvis en eller anden grund du ville arbejde med dette stedet for at arbejde med den vifte skallen variabel der er kommandoer, der kan adskille disse ting baseret på tyktarmen. I virkeligheden, hvis du vil gøre dette i Bash shell eventuelt en form for et script, ville det være nok, hvordan du ville gøre det. Men i C-shell, det er meget lettere at bruge array. I Bourne shell, er variable tildelt af et enkelt udtryk som dette, lide den måde, du kan tildele en variabel i et programmeringssprog, og her må der ikke være nogen mellemrum. Det er nødvendigt, at det er kun 1 streng. I Bourne-type skaller, alle variabler shell variable. Miljø variabler er en delmængde af de shell-variabler. De adskiller sig fra de ikke-miljøvariabler ved at eksportere. Kommandoen til at gøre det er eksporten, ligesom eksport printer. Hvis vi skulle definere en sådan variabel, hvis vi ønskede et trykkeri kommando til at finde det, ville det være en miljøvariabel, og det er, hvordan vi gør det ene. Her er der noget slags forvirrende. Dette udtryk, eksport til miljøet, stammer fra denne Bourne shell koncept, og alligevel dette udtryk anvendes i beskrivelser af den C-shell, hvor der ikke er en sådan kommando som eksport. Hvis du bare sige eksport af sig selv, får du en liste af eksporteret - Så hvis jeg bare eksporterer her, ikke sådan noget. Okay, der vi går. Disse ting, ved den måde, er også defineret af skallen. Jeg har ikke definere nogen af ​​disse af mig selv. Skallen gør alle mulige ting af sig selv. Den bør gøre tingene automatisk. I Bash eller Korn shell, kan du køre en kommando som denne, som både vil give en variabel en værdi, og eksportere det i 1 kommando. I Bourne skal de være adskilte kommandoer som eksport en. Her er et andet aspekt, der er forvirrende. Sættet kommando i C-shell definerer variabler og uden argumenter fortæller dig, hvad variablerne værdier er. I Bash shell, sæt kommando uden argumenter gør de samme ting, men med argumenter, det gør noget helt andet. Så det er de forskellige argumenter her. Nogle af disse er miljøvariabler, nogle af dem er shell-variabler. Alle af dem er shell-variabler rigtig. Nogle af dem er miljøvariabler. Sættet kommandoen med argumenter kan bruges til at betjene på de positionelle parametre til et script, der er en måde at få dem alle på én gang. Vi kan ikke rigtig gå ind i det i dag. Det kan også bruges til at ændre shell adfærd. Især i Bash der er variable, der vil bestemme, hvordan skallen opfører sig. Så er også bare denne ene kommando, som du kan se, denne kommando. Typeset efterfulgt af variable og variable typer anvendes i Korn og Bash skaller. Det er ikke obligatorisk, men det kan bruges til at begrænse de værdier af variabler, som kan være nyttige for at undgå fejl, og det er ret almindeligt. Så jeg bare nævne, at hvis du ser det et eller andet sted. Den hvor kommando. Husk jeg nævnte tidligere, hvor kommandoen i C-shell, som kan fortælle dig placeringen af ​​en kommando stinavn. Her er kommando substitution. Du skal finde på dit tastatur eller andet sted et tegn, der ligner dette. Placeringen på tastaturet kommer til at variere. Vi har kaldt det backquote. Det er på størrelse med et citat. Det går fra øverste venstre hjørne til nederste højre. Her på min Mac-tastatur er det i øverste venstre hjørne. Denne karakter kan bruges til at udføre en kommando inden for en kommando. Hvis du har et udtryk inde backquotes, dette udtryk er en kommando, det køres. Udgangen af ​​denne kommando derefter i stedet for hele backquote ekspression inde i en længere kommando, som derefter kører med, at produktionen som led i sin perlerække af argumenter og så videre. Her er en kommando, der bruger det. Lad os demonstrere driften her. Lad os gå op her, tage ud backquotes. Kontrol A får mig til begyndelsen af ​​linjen med Emacs redigering syntaks. Hidtil stinavne er, hvad hvor gør, men når jeg gør det på denne måde, er det så stik på denne liste over stinavne i stedet for hele denne backquote udtryk og kører ls-l på dem. Kind of bekvem, hva '? Så det er en pæn ting. Det er, hvordan backquotes virker. Lad os nu gå lidt længere nede. Disse alias. Jeg faktisk bruger disse. Jeg vil prøve at få denne i med 1 redigering. Okay. Lad os nu se, hvordan disse definitioner kom ud. alias LHB fortælle mig, hvordan det er defineret. Bemærk, det er netop dette, men de ydre citater er taget ud og udråbstegnet er taget fra. ! *, Komplet liste over alle de argumenter. I en Aliasdefinitionen den vil anvende tilbage til, hvor jeg bruger dette. LBH ksh bash. Okay. Se hvordan det virker? Det sparer mig nogle at skrive. Lad os gå lidt op bare for at nævne noget andet her. Bemærk her disse forskellige skaller. Jeg skulle have nævnt dette før. CSH har en 2 herovre, og det gør / bin / tcsh. Vi kunne etablere en anden måde, de er faktisk den samme fil. Husk jeg sagde, hvis du skriver sh får du bash. Skriver dette, og du får dette. Men de er ikke forbundet. De har enkeltværelser, der. Og det er ikke den slags fil, der kan kalde en anden. Så dem er separate filer, C-shell dem er den samme fil. Tilbage hernede, den anden her, dette alias, bemærke, at kører denne kommando fil. At alias kører det. File fortæller dig typen af ​​en fil. Så FWH ksh bash. Okay. Det er outputtet af kommandoen file. Jeg ved ikke, om du ved, hvad det betyder her, Mach-O Universal Binary med 2 arkitekturer. Der er 2 mulige processor typer i Mac, og nogle programmer blev skrevet til at være i stand til at køre med begge, og filen kommando kan bestemme det, så det er, hvad det betyder. Begge disse filer blev skrevet på den måde. Så vi se, hvordan alias virker, vi ser, hvordan backquote virker, vi se, hvordan den faktiske fil ls eller fil virker. Dette virker måske ikke. Prøv "hvor hvor" og "LBH hvor". Okay, lad os prøve det. hvor hvor. hvor er en shell indbygget. Husk tidligere vi viste, at Bash afse hvor. Hvis du skriver hvor i Bash shell, får du en fejlmeddelelse. Det er bare en del af skallen snarere end at være en separat kommando. Hvad sker der, hvis jeg skriver LBH leder efter hvor? Se hvad der sker der. Ran hvor hvor, fik denne udgang, og derefter forsøgte at køre ls som l på hvor er en shell indbygget. hvor er der, men de andre ikke eksisterer. Ingen af ​​disse eksisterer, faktisk. Så det virker ikke altid, og det er også illustrerer, hvordan nogle ting gør ikke helt, hvad du måske har tænkt. Lad os gå lidt længere ned her. Denne her er i Bash. Det er også kommando substitution ligesom backquote. Men i modsætning til backquote, bruger denne variabel stil. Der er en række udtryk, som begynder med et dollartegn, og mens disse ikke er variabler, de lånte brugen af ​​dollar tegn at angive et udtryk for en slags. Det kan være omgivet af parenteser eller beslag eller dobbelt parenteser, som har et andet formål. Enlige parenteser her er en kommando substitution ligesom backquotes. Dobbelt parenteser er faktisk en aritmetisk operation. Der er andre grammatikker, andre operationer. Backquote syntaks er tilgængelig i Bash. Men denne ene er at foretrække. Det er meget lettere at læse, og det giver mulighed for indlejring. Du kan have inde $ (kommando) en anden kommando, noget lignende - Jeg får en liste der. Det ville fungere, hvis jeg havde backquote også. Hvad hvis jeg ønsker at gøre noget lignende - Du sandsynligvis ikke ville faktisk bruge denne kommando, men denne interne kommando substitution ekkoer navnene på alle filer, der begynder med en, så er dette en kører ls-l på disse filer, og så denne ene bare ekkoer output. Du ville sikkert ikke gøre dette, du ville bare gøre det ekko eller ls, men det illustrerer, hvordan indlejring af kommandoerne fungerer. Så bare en anden funktion her.  Jeg nævnte dette tidligere, at når du har, hvor i C-shell, skrive værker i Bourne-type granater til lokalisering kommandoer. Indbyggede kommandoer, lige hvad jeg sagde der. Kommandoer er en del af skallen, som hvor. Når skallen udfører en kommando som ls, det lokaliserer det gennem stien, finder det i en mappe eller andet sted, lyder, at i hukommelsen, skaber en ny shell, læser ls eller hvad i skallen hvor miljøvariabler er allerede placeret, og så er det overfører henrettelse til det. Indbygget kommando, koden for denne kommando er inde i skallen, så skallen bare begynder udfører en del af sin egen kode. hvor er en sådan kommando. Det faktisk bliver hurtigere. Det behøver ikke at læse noget i hukommelsen, det er allerede i hukommelsen. Indbyggede kommandoer altid forrang kommandoer med samme navn. Kommandoer, der findes i telefonbøger i stien kan have samme navn, kommandoer i forskellige mapper, filer i forskellige mapper. Den ene, der sker tidligere i stien er den, du får. Hvis der er en indbygget kommando, får du altid det. Der er ingen måde at give det en lavere prioritet end en kommando i stien. Hvis du ønsker at få den sti kommando, kan du skrive den fulde sti. Hvis der var en kommando hvor i stien eller andet sted, du kunne skrive / bin / hvor og du ville få det. Hvis du ikke ønsker at skrive hele stien, kan du definere et alias. I virkeligheden, hvis du gav aliaset det samme navn som den indbyggede kommando, ville det arbejde fordi definitionen alias evalueres før skallen fastslår, at det er en indbygget kommando der bør gennemføres. Så det bliver lidt mere kompliceret med nogle kommandoer her. Tilfælde af nogle kommandoer er faktisk indbygget i kommandoer og i stien. En af dem er ekko, kommandoen jeg bare brugt lidt siden i disse eksempler. Echo er en kommando i vejen, og det er i hvert shell. De behøver ikke nødvendigvis alle opfører sig på samme måde. Det var oprindeligt en kommando i stien. Det blev bygget i de skaller senere. Fordi der er muligheder, der er afhængige af miljøet og kommandolinjeparametre, de indbyggede kommandoer blev skrevet til at fungere på samme måde som den kommando, der havde været i stien, det er usandsynligt, at de ville have været skrevet på den måde hvis kommandoen ikke allerede var blevet skrevet til stien. Så det har bivirkninger. Dens historie har virkninger her. Der er muligheder der. Der er også en mulighed, er defineret af en variabel i tcsh kaldet echo_style. Det er en af ​​disse variabler, der kan ændre den måde, ECHO arbejder. Der er andre tilfælde, hvor du kan tildele en variabel der ændrer den måde, at skallen operationen, herunder en indbygget kommando, fungerer. Det ville ikke påvirke noget andet da andre kommandoer ikke har adgang til de shell-variabler, kun de miljøvariabler. Men shell operationer kan læse shell-variabler. Det vil ikke arbejde for csh. Det er kun tcsh. Det er en af ​​de forbedringer. Tolker har sekvenser, når den evaluerer metategn, når den evaluerer variabler, aliaser, historie referencer. Der er en bestemt sekvens for disse ting. Hvis det gør tingene i en bestemt rækkefølge og bliver til noget, der er et udtryk for en slags som allerede er blevet evalueret, vil det ikke vurdere det igen. Hvis det bliver det, så vil det bare gå på de tegn. Så hvis evalueringen af ​​nogle udtryk som kommando substitution eller variabel eller hvad giver anledning til et udtryk som du ønsker at blive evalueret, der vil kun fungere, hvis denne evaluering opstår senere i sekvensen. Jeg håber, at jeg er klar der. At parsing sekvens, en operation i C-shell, er ikke det samme for indbyggede kommandoer, som det er for ikke-indbyggede kommandoer. Jeg er ikke sikker på om Bash der. For eksempel, hvis en shell variabel produceret en historie reference det sandsynligvis ikke ville gå tilbage i historien. Det ville bare få det udråbstegn. Faktisk kan vi bare forsøge at ud lige nu. sæt a =, og vi bliver nødt til at sætte dette i der. Åh, vent. Undskyld. Jeg gjorde det i Bash. Jeg ønskede at gøre det her. Se, så det ikke vurdere, at historien henvisning fordi det var allerede forbi det punkt at vurdere historie udtryk når det vurderes variablen. Så det er 1 effekt af parsing. Og igen, er indbyggede kommandoer ikke gjort på samme måde. Ok. Lad os gå til den næste her. Dette er beregnet til at være 1 linje, men det gør det lettere at læse. Hvad betyder det så? Du husker måske, at vi kan vurdere asterisk som filnavn jokere, og der er andre filnavn wildcards som spørgsmålstegn og beslag udtryk. Den slags evaluering kaldes globbing. sæt noglob i begyndelsen af ​​denne kommando siger ikke gør det. frakoblet noglob siger gå tilbage til at gøre det. Bemærk at sæt glob ville ikke have denne virkning. I almindelig sprogbrug, ville sætte glob eller frakoblet noglob synes at være ækvivalent, men her er det ikke. Det er frakoblet noglob. Nu tIndstil. tIndstil stod for terminal sæt. Det er ikke brugt, som ofte nu, men før vinduessystemer blev tilgængelige og du havde en enkelt terminal, kan du nødt til at bestemme, hvilken type. Og hvis noget var på vej over en Ethernet eller fra netværket, du måske ønsker at sige, det er en VT100. VT100 er lidt af en standard i terminalen virksomhed. Det kommer fra DEC terminalen. Hvis du bare gøre dialup - bemærke, at? Dette går tilbage en måder, hva '? Så hvis vi bare tIndstil herovre, hvis jeg bare gøre tIndstil, er det at nulstille min terminal, men du kunne ikke se noget. Det gjorde ikke rigtig ændre noget. -S Okay. setenv TERM xterm-farve. Vi ved allerede, at udtrykket blev sat på den måde, så der ikke ændres. Det er den måde, vi gerne vil gøre det. Men bemærk at denne kommando, tIndstil-s, bare output disse kommandoer. Det gjorde ikke køre dem. Det gjorde ikke køre disse kommandoer, det output dem. Så dette er beregnet til at producere kommandoer, som derefter vil blive kørt. Du husker kommandoen i filen jeg bare viste du havde en Q i det. Så lad os gøre det. Q-undertrykker nogle output, men det betyder ikke noget her, som du kan se. Jeg er bare at gøre det for at vise dig, at det ikke har noget. Dette er i backquote syntaks. Bemærk backquote her backquote her. Jeg udelade disse ting her. Det er de tilfælde af at fortælle det, hvad de skal gøre i tilfælde af særlige typer af terminaler - Ethernet, netværk, dialup, hvad har du. Det betyder ikke noget her, fordi vi ikke rent faktisk gør nogen af ​​disse ting. Jeg er bare illustrerer kommando. Hvis jeg gør dette med backquote, hvad jeg kommer til at få? Bemærk også her, at dette omfattede indstillede noglob og frakoblet noglob, så dem bliver nu afskediget i definitionen. Det var ikke altid sandt, men nu er de medtaget i denne kommando. Men lad os se hvad der sker, hvis jeg gør det og gå til begyndelsen af ​​linjen med Kontrol A og jeg gør det. Okay, sæt: Kommando ikke fundet. Det er lidt underligt, er det ikke? sæt er en velkendt kommando. Det er en del af skallen. sæt: Kommando ikke fundet? Hvorfor er det? Hmm. Nå, lad os tænke over dette. Det kører en backquote kommando substitution, og der forekommer ved en bestemt del af sekvensen af ​​parsing kommandoen. sæt er en indbygget kommando. Så ved den tid, det gør denne kommando substitution, det er allerede kommet forbi det punkt at identificere indbyggede kommandoer. Så det behandler indstillet som om det var en kommando i stien. Overflødigt at sige, det ikke finde det, og du får en fejl. Well. Der er et eksempel på parsing sekvens. Og hvad gør vi ved det? Bemærk denne meget interessante kommando her, eval. Jeg spekulerer på, hvad der gør. Hvis man ser på den manuelle - og lad os bare gøre det at vise, hvordan forvirrende disse håndbøger er - mand tcsh, forvirret manual, finde ting her er heller ikke let. Her går vi, eval arg, så vi kan have en eller flere argumenter og der er en liste over ting der. Behandler de argumenter som input til skallen og udfører de resulterende kommandoer i forbindelse med den aktuelle skallen. Dette er normalt bruges til at udføre kommandoer genereret som følge af kommando eller variabel substitution fordi parsing sker, før disse udskiftninger. Meget godt. Og her er de endda henvise til tIndstil kommandoen for en stikprøve brug som den jeg bare viste dig. Nu er jeg nødt til at få vinduet tilbage til et nyttigt sted. Lad os tage over her, og vi vil se, at eval bruges lige før det. Så lad os se hvad der sker, hvis vi sætter - her går vi op med pilene til denne kommando og Kontrol A til begyndelsen, eval. Okay, så det fungerer. Når du gør eval, det tager, hvad der kommer efter det og gør det til en kommando. Dette giver dig mulighed for væsentlige tolke det to gange. Afsnittet her kører denne kommando inde i backquotes, får output. Output formodes at blive kørt som de kommandoer her som disse på denne ene, og denne ene. Så disse kommandoer er nu her i denne sekvens, men disse er indbyggede kommandoer, og det kan ikke få dem med det samme. Så går vi til eval, eval samler det op, starter det hele forfra igen, og det virker. Et eksempel både backquoting EVAL, parsing konsekvenser parsing og en kommando, som sandsynligvis er meget lidt brug for dig i dag. Okay. Okay, umask. Lad os se på denne kommando her, umask 022. Jeg spekulerer på, hvad der gør. Lad os bare skrive umask med intet efter det. 22.. Okay. 022 og gøre det igen. Som du måske har gættet, umask uden argumenter fortæller dig den aktuelle maske; umask med argumenter gør den det, men det var den ene havde jeg allerede. Hvad betyder 022 betyder? Det er her den beskyttelse af en fil. De bestemmer, hvem der må læse eller skrive eller eksekvere filen. Beskyttelse kaldes også tilladelser. R står for læse, w for skrivning, og x, som ikke er til stede der, står for udføre. Der er 3 kategorier der. De sidste 3 elementer er i den kategori af brugeren. De gælder for mig, for brugeren. Disse 3 her gælder for gruppen. Filen tilhører 1 gruppe, kan brugeren tilhøre flere grupper, men hvis brugeren er i den gruppe, hvor filen tilhører, så disse beskyttelser vil gælde for ham, hvis han ikke er brugeren. Og dette er alle andre. Disse kategorier er gensidigt udelukkende. De bruger-beskyttelser gælder for ham, gruppens beskyttelse gælder for medlemmer af gruppen andre end brugeren, og de andre beskyttelser kun gælde for andre end brugeren og gruppens medlemmer folk. Hvis der er en r eller aw eller x, betyder det, at der gives beskyttelse. Hvis der er en bindestreg, betyder det, er det ikke. Der faktisk er andre ting, der kan sættes i her foruden disse, som jeg ikke vil komme ind nu. Den umask definerer en standard for filer, som du opretter. Og som en maske, dybest set det siger de bits, som du ikke sat. Hvordan er dette blevet bits? Hvis du tænker på hver af disse som en oktal nummer, dette er det 1s smule, er dette den 2s, dette er 4s. Så 0 til 7 vil beskrive, hvad kombinationen af ​​r s, w er, og x'er du har for disse 3 og derefter et tilsvarende antal for disse og derefter for disse. Så 022 betyder 0 for andre, 2 for gruppen, 2 for brugeren. Men dette er en maske. Masken er, hvad du ikke har. Undskyld. Jeg har lige givet dig ting i den forkerte rækkefølge. Det er de første 3. Disse 3 er brugeren, disse 3 er gruppen, disse 3 er den anden. Undskyld jeg gav dig disse i den forkerte rækkefølge. 0, som er den første af dem, ikke vise værdien, men hvis et tal ikke er der, det er et 0. Det betyder, at alle 3 af disse ville være tilladt. Bemærk, at i dette særlige ene x er ikke tilladt. Årsagen er, at skallen er i stand til at bestemme om en fil skal udføres eller ej. Da dette ikke er en eksekverbar fil, gjorde det ikke indstille x. De 2 midler, der skriver tilladelse, den anden kategori her, den ene i midten, er nægtet. Så igen, det er de ting, som den nægtet. Nå, x er tilladt, men det er ikke her, fordi det ikke er eksekverbar og tilsvarende for de andre. Så det er en fælles umask. En anden almindelig ene er 700 - give dig selv alt og ingen andre noget. Og der er andre muligheder. Jeg vil gå tilbage til. Brug af historie, jeg kan søge tilbage til det, LBH til der. Okay. Så her, det er de skaller. Bash, de ejer, der er system-konto, kan gøre alt. Group og alle andre kan gøre læse eller udføre, men ikke skrive. Denne ene ikke engang tillader ejeren at skrive til den. Hvis ejeren ønskede at skrive til det, vil systemet konto, han ville have til at ændre beskyttelsen først. Men igen, det umask sætter standard ved at skjule det, ved at angive de bits, der ikke vil blive sat. Det er typisk i en af ​​dine initialiseringsfiler, som er. Cshrc for C-shell eller. profilen for Bourne-type skaller. Det kan være andre steder også, hvis der er andre initialisering filer på systemet. Anyway, det er umask. Der er noget slags ulige her, og det er, hvorfor er der en enkelt kommando til dette? Hvis jeg skulle skrive dette, ville jeg gøre det en variabel, umask = vis værdi. Hvorfor er der en hel kommando netop til dette formål? Årsagen er dette blot går tilbage til oprindelsen af ​​Unix. Unix var blot nogle programmerings projekt på Bell Labs i begyndelsen af ​​1970'erne. Folk bare fik sammen til programmet. De har aldrig tænkt sig at blive et verdensomspændende operativsystem. Forskellige mennesker skrev forskellige dele uden at tænke meget af hvordan de skal bruges - temmelig magre. Og det kom sammen sådan, og det er stadig som den i visse henseender. Så det afspejler den historie, og der er stadig disse uoverensstemmelser og ulige elementer i det. Okay. Næste en her. Som jeg skrev tidligere, er C-shell ikke rigtig brugt meget til programmering, selvom det kan være. Den udfører langsommere, igen afvejningen mellem interaktiv brug, som har mere processorkraft involveret end hastighed, der kan undvære behandlingen. De ekstra funktioner tilføjet til Bourne skal af Korn og Bourne-again skaller synes ikke at sinke dem, og jeg ved ikke, hvorfor det er. Det kunne bare være bedre programmering, men jeg er ikke i stand til at vide. Hastighed her faktisk ikke er sådan en big deal, selv om det er nævnt. Årsagen er, at shell scripts faktisk få temmelig hurtigt. Hvis der er en masse af kommandoer som i en beregningsteknikkerne program ville du sikkert ikke gøre det i et shell script. Operationerne der er forholdsvis enkel og ligetil. Dem, jeg har oplevet, der er for langsomme involvere gentagne anvendelser af langsomme kommandoer. Jeg nævnte tidligere stream editor sed. Denne kommando er langsom. Hvis du udfører SED mange gange, får du en langsom script, men det er ikke skallen, der er langsom. Kører det i Bourne shell, vil ikke være meget hurtigere end at køre i C-shell, selv om der er måske nogle fordele der. De yderligere programmering kapaciteter, på den anden side, er væsentlige grunde til, at du ville bruge de Bourne-type skaller. C-shell har ulige funktioner til det - det faktum, at du ikke ved, om en variabel er en shell variabel eller en miljøvariabel. Det kan være meget forvirrende. Det er ikke så let at skrive blot baseret på din oplevelse af programmering i andre sprog. Jeg tror du kan finde de Bourne-type skaller mere i overensstemmelse med din oplevelse. Nogle scripts, men kan være tusindvis af linjer i længden. Dem, jeg har set bruges til at lappe operativsystemer. De kan udføre meget langsomt, men du behøver ikke køre dem meget ofte. Det er kun, når du laver patching, og det er kun systemadministratoren, der gør disse ting, så det er egentlig ikke meget af et problem. De, der er hundredvis af linjer lang faktisk at gennemføre forholdsvis hurtigt. Hvori dette her, hvad er disse forbedringer? Jeg har allerede nævnt et par af dem - arrays, beregninger, de $ () udtryk for beregningerne i Bash shell, Den anden form for kommando substitution. Der findes forskellige typer af test-kommandoer , som du kan gøre betingede tests på eksistensen af ​​en fil eller andre ting. Her sidst, denne kommando her. Hvad betyder dette gør, og hvorfor skulle nogen bruge det? printenv variabelnavn. Vi ved, hvad printenv gør. Det fortæller os, at værdien af ​​en variabel. Og printenv variabelnavn vil ikke fortælle os meget, fordi der er ikke sådan variabel. Blank. Men lad os give det noget meningsfuldt. Det er ikke der enten. Okay. Jeg tror jeg aldrig defineret det. Lad os lige tjekke mine omgivelser. Dette er en anden kommando, som du kan inspicere dit miljø. Der er gode gamle editor, den vi oplevede før. Hvad betyder det så? Her har vi en backquote udtryk. Husk dette er C-shell. Så printenv EDITOR vil give os en værdi af editor. Det er vi. Og så vil det sætte denne værdi til variablen a, den indstillede kommando. Så nu, hvis jeg gør echo $ a, jeg får vi. Det synes ikke frygtelig nyttig. Men det rent faktisk gør har et formål. Da vi ikke ved, om en variabel er en shell variabel eller en miljøvariabel ved hjælp af dollar tegn evaluering syntaks, kan vi bruge printenv at sikre, at det er en miljøvariabel. Så hvis der var en shell variabel redaktør, ville dette ikke have fået det. Dette virker kun med miljøvariablen. Hvis der var en shell variabel og jeg ville dens værdi, Jeg er nødt til at finde en anden måde at gøre det. En måde at gøre det ville være ved at gøre sæt og rørføring. Dette er en af ​​de metategn, specialtegn. Det sender produktionen af ​​sæt til noget andet. Lad os se hvad vi kan finde der. Ikke noget. Okay. Lad os bare se, hvad der er derinde alle sammen. Det var echo_style, den ene jeg nævnte før. Okay, lad os gøre det. Husk jeg nævnte før, echo_style bestemmer den måde kommandoen echo vil køre. bsd står for Berkeley Standard Distribution. Dette er Berkeley Unix fra 1970'erne. Det er en af ​​de måder, at ECHO kan køre. Indstilling echo_style til denne værdi i TC-shell vil forårsage ekko til at opføre sig på den måde. Så sæt gør det, men sæt kun får shell-variabler. Det ville ikke finde EDITOR, hvilket ikke er en shell variabel. Ikke noget. Så det er en måde at adskille dem. Men det faktum, at du er nødt til at gå igennem nogle mærkelige kommando som der at skelne mellem shell variabler eller miljøvariabler viser den slags upraktisk karakter af C-shell til nogle formål. Og nu, sidste og måske det mindste er det man-siderne. De af hvem du måske ved, at manden er den kommando kort til manuel. Man siderne for skallerne er svære at læse. De er meget lange. De er organiseret på en måde, der kan gøre det svært at finde det, du leder efter. Så hvis du leder efter noget med et formål, du kan ikke vide, om dette formål er en shell variabel eller noget andet, så du kan ikke vide, hvor de skal lede efter det. Du kan søge efter forskellige strenge, men strengene er ofte gentagne. Så det er generelt svært at læse. Vi har lige kigget på TC-shell mand side lidt før for at finde eval kommando. Nogle ting går hurtigere. En fremgangsmåde er at søge efter en streng. Du kan bruge personsøger. Personsøgeren har skråstreg til at lede efter en kommando eller en streng inde i en personsøger operation. Man som standard vil bruge personsøgere, enten være mere eller mindre. Jeg ved ikke, om du er fortrolig med dem, men de kan vise filer lidt efter lidt. Jeg har brugt mindre at vise disse særlige filer, vi har her. Du kan søge inde der. Du kan prøve at bruge forskellige søgestrenge. Også mand sider i forskellige operativsystemer kan ikke være den samme. De kan være separate sider for csh og tcsh. De er ikke på Mac, men de kunne være, hvis de er separate kommandoer. Hvis sh ikke rigtig kalde Bash, sandsynligvis ville der være en separat man side. Nogle systemer har separate mand sider bare for C-shell indbyggede kommandoer. Nogle gange, hvis du ønsker at læse en beskrivelse af en indbygget kommando det er også i vejen, ligesom ekko, skal du læse den mand siden på denne kommando på ekko at bestemme, hvordan det vil fungere som en indbygget kommando selvom du ikke kalder den indbyggede kommando. Det er en ulempe af operativsystemet i almindelighed, ikke kun for de skaller, selv om skallerne især mand sider er ganske lang, dels fordi de har tilføjet nyttige funktioner til dem, hvilket kan være en positiv. Okay. Er der nogen spørgsmål? Eventuelle emner, du ønsker at bringe op? Noget relevant her? Tja, det har været meget hyggeligt at tale med jer alle. Jeg håber du fik noget ud af dette seminar der vil være nyttige for dig i dine fremtidige bestræbelser. [CS50.TV]