>> [Seminarium - Unix Shells, Miljöer]
[Douglas Kline - Harvard University]
[Det här är CS50. - CS50.TV]
>> Dagens ämne är Unix shell.
Jag är Douglas Kline, sakkunnig, eller åtminstone någorlunda kompetent användare av skalet.
Ett skal är gränssnittet för användaren att datorns operativsystem.
Namnet är vilseledande eftersom, till skillnad från ett djurs skal,
vilket är svårt och skyddande, gör att datorn skal för kommunikation.
Så poröst membran skulle förmodligen vara en bättre metafor.
>> Den ursprungliga skal för Unix är Bourne-skal.
Bourne stavas B-O-U-R-N-E.
Bourne var en av de ursprungliga författarna av Unix,
och så skalet är uppkallad efter honom.
Namnet på det skal som ett kommando är bara helt enkelt sh.
Det är det kommando du kan köra.
Skalet börjar vid inloggning.
När du loggar in på datorn, skalet börjar att köra för dig,
och det är det som tar dina kommandon.
Det kan börja på andra tider också.
Om du tar upp ett fönster med inga andra uppgifter, kommer den att starta ett skal för dig.
Det är så det är att du kan gå till ett fönster och börjar skriva kommandon
och så vidare där även om du inte logga in på det fönstret.
Dessutom, om du gör en fjärrinloggning,
då det kommer att starta ett skal på fjärrdatorn.
Och det är möjligt att köra kommandon utan ett interaktivt skal.
Det kan betyda inom din nuvarande verksamhet,
och det kan också innebära en fjärrstyrning.
Du kan skicka ett kommando till en annan dator,
vilket innefattar att starta ett skal där.
I själva verket har det för att inkludera att starta ett skal där
även om det inte är din slutliga syfte.
När något börjar såhär, inte nödvändigtvis starta ett nytt skal.
Om du tar upp ett nytt fönster, är det möjligt att tala om för den att ta upp en redaktör
eller något annat kommando.
I det fallet kommer editorn börja från början.
När redaktören slutar, ändar i fönstret.
Det är lite ovanligt, men det kan göras.
I dessa fall kommer det inte vara ett skal.
Så det är inte nödvändigtvis så att ett fönster eller en sådan ansökan kommer att ta upp ett skal.
>> Shell tolkar kommandon.
Parsning innebär att identifiera de olika elementen och klassificera dem.
Inom ett kommando, den fullständiga sträng som du skriver,
kommer det att finnas en eller flera enkla kommandon som ska exekveras.
Andra element kan vara argument.
Det kan också vara specialtecken som påverkar utförandet av ett kommando.
De kan skicka produktionen någon annanstans än skärmen
om kommandot normalt skulle sända den till skärmen.
Det kan omdirigera ingång, det kan göra andra saker också.
Det finns flera andra symboler, tecken och så vidare.
Parsning innebär att upptäcka och tolka dessa saker.
>> Nu om det inte finns några fler frågor, vilket är ganska troligt eftersom det inte finns några fler människor,
Vi kommer att gå vidare till min nästa sida här.
>> Jag sade tidigare att Bourne-skal är den ursprungliga skalet.
Det finns andra.
En är den C-skalet. Kommandot är csh.
Namnet C-skalet är bara en lek med ord.
Detta skal introducerades med Berkeley Unix i mitten av 1970-talet.
Berkeley Unix var en nyskapande händelse i utvecklingen av Unix.
Det var en stor revolution och ingår införandet av detta skal.
Anledningen till att ordlek, C-skalet,
är att den C-skal har vissa egenskaper i det som liknar C-språket,
som Bourne-skalet inte har -
eller det inte hade på den tiden.
Det finns även TC-skalet.
Detta är ett superset av C-skalet.
Den har ytterligare funktioner, av vilka många är användbara för interaktiv användning,
till exempel påminna kommandon i historien mekanismen,
som jag ska beskriva något senare -
på ett enkelt sätt, modellerad efter en redaktör.
Det har också bindningar som gör att du kan binda en kort nyckel sträng till en längre kommando.
Vi kommer inte att komma in i det i dag.
Den har vissa funktioner som är användbara för programmering.
Dock är C-skalet inte ofta för skalprogrammering.
Shell-program, om du inte redan vet,
är program som består av skal egenskaper.
Du kan köra dessa som program.
Du skriver en massa skalkommandon i en fil och köra filen.
Du behöver inte kompilera det. Detta är en tolkande språk.
Frasen C-shell är nu osäkert, eftersom det bara kan hänvisa till den ursprungliga C-skalet, csh,
eller till alla C-skal, inklusive tcsh. Det är lite tvetydigt.
>> En senare skalet är Korn-skalet, ksh, uppkallad efter programmerare, Korn.
Detta skal försökt att i 1 skal
fördelarna med den C-skal för interaktiv användning
och Bourne shell för programmering.
Den har använts som ett interaktivt skal av vissa människor - en minoritet.
Senare dock, det fanns en annan introduktion, Bash skal, BASH,
återigen en ordlek, Bourne-again shell.
Det är en förlängning av Bourne-skal. Korn-skalet finns också. Båda är.
Den har samma mål för Korn-skalet av en sammanslagning av C-skalet s
och Bourne shell fördelar i 1 skal.
Många av de förbättringar av Korn-skalet är också inkluderade i pucklar.
Våldsamt slag har dock mer och är därför att föredra.
The Bourne-again skal och Korn-skalet kallas Bourne-typ skal
eftersom de innehåller Bourne shell egenskaper,
som är oförenliga i vissa avseenden med C-skal.
Det finns andra skal än de som, en del är avsedda för begränsad användning,
kanske begränsad till vissa kommandon, kanske specialiserade ändamål, inte används ofta.
>> Okej. Nästa punkt här.
Bash-skalet har blivit förknippade med olika former av Linux.
Jag är inte säker på om det är sant i alla former.
Det finns många former där ute och jag har inte använt dem alla,
men de som jag har använt det har blivit associerade med det.
Så vitt jag vet finns det ingenting om Bash
vilket gör den mer kompatibel med Linux
än någon annan kombination av skal och operativsystem.
Jag tror att det nog bara återspeglar böjelser programmerare.
Att det har blivit förknippad med Linux är ett annat skäl att föredra Bash att ksh
eftersom saker kommer sannolikt att skrivas på det och det är sannolikt att sprida sig.
Jag ska ge er andra skäl för det senare.
Bourne shell-skript ska köras under Korn-skalet eller Bash.
Om du skriver något för Bourne-skal,
du kan nog köra den under ksh eller bash.
Korn skalskript kommer förmodligen att köras under Bash, men jag kan inte garantera det.
Senare här, bör C-skalskript köras under TC-skalet.
I C-skalet var faktiskt aldrig flitigt för skript
eftersom Bourne shell och senare var att föredra för detta ändamål de Bourne-typ skal.
Så det är verkligen inte så viktigt.
Det finns en hel del Bourne skalskript som skrevs för länge sedan,
innan Korn-skalet eller Bourne-again shell infördes.
De är fortfarande i bruk, en del av operativsystem,
och så att du hittar dem om du tittar i operativsystemet
eller några gamla programmering paket.
>> Pucklar är till viss del på att bli ett slags lingua franca för operativsystem.
Det har redan utvidgats till Windows och till VMS.
VMS, om du inte vet, är ett egenutvecklat operativsystem
av Digital Equipment Corporation, som fortfarande är i bruk, till stor del bakom kulisserna.
Och om det kommer att köras på flera olika operativsystem,
sannolikt de människor tenderar att flytta för det.
Men denna utveckling är relativt ny.
Det är bara början, så jag kan inte förutsäga om det kommer att visa sig verkligen vara den typen av lingua franca.
Också, eftersom fil sökvägar och bibliotek skiljer sig
mellan dessa olika operativsystem,
du kanske inte att kunna skriva en bash skript på ett operativsystem
och sedan köra den på en annan.
Du ska kunna flytta den mellan olika Unix, Linux
Mac OS-operativsystem, men inte nödvändigtvis till Windows eller VMS.
Du kanske måste byta fil sökvägen beskrivningar,
och vissa bibliotek kan vara annorlunda,
vilket kan påverka hur vissa kommandon fungerar
eller hur de behandlar argument och liknande.
I tillägg till detta, är en annan försiktighet här att det inte finns någon garanti
att alla olika skal jag har nämnt - Bourne shell, C-skal,
TC-shell, Korn-skalet, Bourne-again shell - kommer att finnas tillgängligt under någon Unix
eller Linux eller Mac OS-dator.
De helt enkelt inte kan vara där.
Det är en av de varningar här.
Det är en olycklig begränsning här eftersom du vill att saker och ting att fungera överallt,
men tyvärr kan man inte lita på det.
>> Okej. Nästa man här.
Låt oss säga att du vill skriva ett skalskript,
ett program som består av skalkommandon.
Du skriver dina kommandon, lägg dem i en fil, och köra filen.
Vad händer om du vill inkludera argument?
Vid skal verksamhet, argument kallas parametrar eller positionsparametrar
och de kommer att kallas av ett dollartecken och siffran, $ 1, $ 2.
Så om skriptet har detta namn, skulle min första argumentet vara argument 1
och min andra kan vara argument 2,
och inne i mitt manus om jag vill hänvisa till dessa saker -
låt oss ta bort det eftersom jag inte riktigt kommer att köra den -
i mitt manus jag kanske har $ 1 för att hänvisa till arg1,
$ 2, som kommer att komma ut på det sättet, arg2.
Så dessa symboler är tillgängliga för att hänvisa till argument,
och de gäller för alla skalen.
Dessutom finns det andra tecken.
$ * Avser hela argumentlistan, alla av dem.
$ # Refererar till det antal argument.
Återigen, detta gäller alla skalen.
Dessa symboler, * och # kan användas med de betydelser på andra ställen också.
Vi kommer inte att komma in i det.
>> Shell föreskrivaren linje. Vad är det för?
Låt oss säga att du har skrivit ett manus och det är för ett visst skal och du vill köra det.
Hur vet du vad skal operativsystemet använder för att köra skriptet?
Vid ett tillfälle kunde man anta att det skulle köra det i Bourne-skal
om du inte säger något annat,
men folk inte skriver manus i Bourne-skalet så mycket längre
och du kan inte ens lita på det längre.
Så här har vi ett skal specifice linje här.
Det anger Bash.
Observera att det anger det i sökvägen, / bin / bash.
Om en dator har Bash skalet men inte i katalogen bin, / bin, detta kommer inte att fungera.
Det är ett annat kval, en annan försiktighet här.
Pundet tecken är kommentarsrad karaktär.
Det gäller alla skal.
Den särskilda fallet här, #! i början av ett skript, är ett specialfall.
Som anger skalet på sig att köra skriptet.
Som jag sa, kan det inte vara på samma plats / bin.
Dessutom finns det en annan sak här.
Om du bara använder nummertecken utan utropstecken och sökväg,
som bör ange en C-shell.
Men jag rekommenderar inte att göra det eftersom jag inte kan garantera
att denna alltid kommer att fungera.
Om du vill ha en C-skal, skulle det vara bättre att säga så.
Sedan finns det något ganska förvirrande här.
Om du använder ett skal specificelinje som / bin / bash
och att skalet inte är tillgänglig där,
det finns inget sådant som / bin / bash på just den datorn,
antingen för att den inte har pucklar eller eftersom det är i ett annat läge,
du får ett felmeddelande som talar om att skriptet du körde inte existerar.
Och naturligtvis finns ditt manus, så att felmeddelandet är förvirrande.
Anledningen till att operativsystemet ger dig den fel
eller, rättare sagt, att din interaktiva skal där du kör detta ger detta fel,
är att den rapporterar kommandot du använde, vilket är namnet på skriptet.
Detta kommando effektivt kallas skalet av namnet på skriptet.
Det är där du får den förvirrande felmeddelande.
Ett annat sätt att ringa shell script
är genom att ange skalet på kommandoraden, så här.
Detta är ett kommando. Detta säger köra Bash och sedan köra mitt manus i Bash.
Det kommer att ha företräde framför en specificerare linje,
och detta har funktionen av att du kan ge olika sökvägar.
Om du bara ge ett kommando, kommer operativsystemet att leta efter kommandot
på olika ställen.
Om den är tillgänglig, om den anser det.
Datorn hittar Bash oavsett var den ligger och kör den,
så att du inte behöver då vara oroliga när den finner det.
Det finns potentiellt andra bekymmer här,
som om det finns mer än en version av pucklar, vilket är möjligt även om osannolik.
Så det är ett annat sätt att ta itu med dessa saker.
Specifier linjer kan ringa någon skal.
De kan också ringa till andra än snäckor saker.
Exempel Jag har här är sed, vilket är strömmen redaktör;
awk, vilket är ett mönster bearbetningsspråk;
och perl, en mycket högt utvecklad skriptspråk.
Om du sätter en specifice linje som anger en av dessa i början av programmet,
det kommer att gå direkt in i det programmet i stället för att starta ett skal.
Dessa program har gränser för sin förmåga.
Perl är mycket kapabel. Sed är redaktör. Det kan göra saker än att bara redigering.
Men det kan vara svårt att programmera det.
Dessutom passerar argument och grejer att manus är antingen omöjligt eller förvirrande.
Så i dessa fall, med awk eller sed, är det, åtminstone i min erfarenhet,
bättre att skriva ett script och samtals awk eller sed från skalskript
snarare än att ringa awk eller sed som scriptet specificelinjen.
Perl är en mycket diversifierad språk, som jag sa.
Du kan inte köra interaktiva kommandon i perl,
vilket innebär att du inte kan testa delar av manus som du utvecklar
genom att köra dem interaktivt.
Men det är en oerhört kapabel språk
och har utvecklats till en mycket vanligt förekommande verktyg.
Det är bara en liten bit av en parent kommentar om specificeraren linjerna.
>> I alla eller de flesta former av Linux - igen, jag kan inte vara säker på det är allt -
och i Mac OS, om du skriver csh får tcsh,
och om du skriver sh du bash.
De försökte där för att ge dig de mer avancerade versionerna av dessa snäckor,
men det kan vara förvirrande.
Om du skriver ett skript med tcsh eller bash funktioner när du ringer csh eller sh
och sedan försöker köra den på en dator som inte har tcsh eller bash,
du kan få några fel om det finns kommandon i det
vilka dessa skal inte känner igen.
Dessutom kan du ha ringt upp ditt skal på din lokala dator
kalla det som sh eller csh och sedan få de mer avancerade skal.
Du kanske inte ens tänker på det faktum att du använder mer avancerad skalet.
Så detta är en potentiell fallgrop.
Hur avgör man att om du skriver sh du Bash,
om du skriver csh du tsch?
Det finns saker i dessa datorer kallas länkar
som kan ansluta till filnamn för att hänvisa till samma sak.
Det kan antingen vara två namn på samma fil eller en fil vars syfte är att hänvisa till en annan fil.
De kallas hårda och symboliska länkar. Vi kommer inte att gå in i det längre idag.
Det kan också finnas separata filer - 1 fil sh, 1 fil Bash -
men de båda kör Bash.
Sedan finns det en annan kval här.
Om du ringer ett av dessa skal med ett namn,
du kanske tror att du skulle få samma funktionalitet som att kalla det med ett annat namn.
Tja, egentligen är det inte nödvändigtvis sant.
Dessa kommandon kan granska namnet som de kallades
och de kan, på grundval av det namnet, beter sig annorlunda.
Det kan finnas problem med att försöka anpassa sig till en standard.
Några av er kanske har hört talas om POSIX-standarden eller en annan,
kanske andra funktioner.
Detta kan väljas ibland med kommandoradsargument
eller genom att ställa in skalvariabler.
Kalla det som sh eller bash kan faktiskt leda till ett annat utförande
även om det är samma fil som du utför.
En annan sak att tänka på är att även om en annan dator har tcsh eller bash,
om de inte är kopplade som de är på din lokala dator
om du har en Linux-eller Mac OS lokala dator,
sedan igen får du skalet som du kallar sh eller csh, inte den som du kanske föredrar.
Den nuvarande Bourne-skalet har förbättringar mindre än de i Bash
men förbi dem i den ursprungliga Bourne-skal.
Som en följd av att även den nuvarande Bourne-skal, sh,
även när det är inte pucklar, liknar C-språket mer än den C-skal gör.
Det var inte sant när C-skalet först skapades, men den har utvecklats på det sättet.
Du kanske märker här att alla dessa skal namn utom för Bourne-skal
har något att indikera vilka skal de är - csh, bash -
men Bourne-skalet är bara sh.
Varför? Det var den ursprungliga skalet.
Det var skalet då, inte ett skal,
och eftersom det var skalet, det fanns ingen anledning att skilja den från ett annat skal.
Så det är därför den har det namnet och fortfarande gör.
>> Denna topp här är en linje från en lösenordsdatabas för ett konto jag har där
på en annan dator.
Jag ska försöka få det namnet så att du kan se att en del i slutet, skalet.
Lösenordet databas innehåller inloggningsegenskaper för alla användare.
I början är det användarnamn som du kan se de sista två bokstäverna i min nu.
Fälten här är åtskilda med kolon.
Det sista fältet, som ni kan se, är bin / tcsh, skalet.
Det är skalet föreskrivaren.
Det finns något intressant här.
När Unix utvecklades först, det var bara 1 skal,
så det fanns inget val där.
Så varför gjorde de tillåter ett fält i lösenordsdatabasen för att ange ett skal?
Jag vet inte, men det är tur att de gjorde.
Det är ganska svårt att göra ändringar i lösenordsdatabasen format
eftersom många program hänvisar till dess format
och skulle behöva skrivas om.
Det är en lyckad eller slumpartad utveckling att de inkluderade det fältet.
Denna typ av lösenord fil linje används på alla Unix-och Linux-datorer så vitt jag vet.
Mac har sitt eget system.
Den har faktiskt en lösenordsfilen med raderna i det formatet,
men det är inte där användaren egenskaper definieras.
En annan parenteser anmärkning där.
>> Om du ringer ett skal, kan du kalla det som en sub-skal av dina befintliga skal.
Så om jag går här, låt oss bli av med dessa saker.
Här är jag i C-skalet.
Denna variabel, som exakt identifierar mitt skal,
egentligen är inte alltid ett tillförlitligt sätt att avgöra vad skal du kör,
men i detta fall det är.
Vad händer om jag skriver bara -
Nu är jag i Bash.
Vissa saker kommer att vara densamma. ls säger mig mina kommandon.
Om jag gör en avbryta tillbaka till min C-skal, ls, samma. Rätt?
fg, förgrund, tillbaka till min Bash skal.
pwd, aktuella katalogen, tillbaka till C-skalet.
pwd, annan katalog - egentligen inte en annan katalog i det här fallet.
Det är samma katalog.
Låt oss säga att jag vill ringa ett kommando här: där ls.
Vad gör det?
Det säger mig var kommandot ls,
den som ger mig en kataloglista, ligger i ls.
Låt oss gå tillbaka till Bash skal. Låt oss prova samma sak.
Hmm, intressant det där: kommandot hittades inte.
Varför är det?
Där kommando Den är inbyggd i C-skalet.
Detta är inte ett kommando som måste läsas in i minnet från någon annanstans och avrättades.
I C-skalet kör den genom att överföra utförande till en del av sin egen kod
och det är inte i Bash skal.
Så Bash, att inte ha ett sådant inbyggt kommando, söker efter det, inte tycker att det är,
och vi får ett felmeddelande.
Så där har vi en Bash skal som körs under ett C-skal, och vi kallar det en sub-shell.
Och ifall du är nyfiken, har Bash skal sitt eget sätt att lokalisera kommandon.
hashade hänvisar till det faktum att den kan startas snabbare
upptäcks snabbare.
Det är en av de förbättringar som är inbyggda i en del av dessa skal.
>> Bourne-typ skal är att föredra för programmering.
De har kontrollstrukturer som loopar, villkorssatser,
den typ av kommandon som du kan använda i programspråk som C
eller vad språk. Kanske du programmera i Java eller något annat.
Tankar har dem också.
De Bourne-typ skal, särskilt Bash, har mer
och de är utformade med större flexibilitet.
Bash-skalet har arrayer. Den ursprungliga Bourne-skalet inte.
Så som kan vara avsevärt fördelaktigt för programmering.
I C-skalet gör faktiskt matriser men inte har en hel del av dessa andra funktioner.
De Bourne-typ skal kommer att utföra snabbare
om de inte har de egenskaper som är avsedda för interaktiv användning.
Du laddar ner saker för ett syfte, vilket laddar ner dem för ett annat ändamål.
Det är det avvägning där.
De funktioner som är avsedda för interaktiv användning
egentligen är för liten eller ingen användning för skript.
Det är möjligt att använda en interaktiv under skal precis som den jag började där
testa kommandon som du tänker använda i ett manus.
Det är vad du inte kan göra med perl. Du kan göra det med skalen.
Till och med de strukturer som för loopar och så vidare kan köras interaktivt.
De är ibland bra att köra interaktivt,
men mer troligt att du använder dem för att utveckla ett manus.
>> Alias.
Detta kommer att vara om C-skalet.
Historia mekanism där du kommer tillbaka till tidigare kommandon
eller delar av dem som du redan kör.
Återigen, om C-skalet, Bourne-skalet och Korn-skalet har dessa saker,
men jag kommer inte att komma in i dem.
Så här är några användbara alias som jag har.
Istället för att skriva ls - det är en vanlig kommando -
skriv bara l och spara 1 tecken.
ls med olika alternativ, alla dessa verk.
Observera att dessa definitioner har citattecken runt dem.
I dessa fall, citationstecknen är inte nödvändigt.
Om du kan definiera dessa alias utan citattecken, skulle det ändå fungera.
De rekommenderas.
Det finns situationer där du inte kan använda citatet
eftersom du vill att något ska hända som citatet skulle förhindra.
Ibland kan du citera en del av definitionen, men inte alla av det.
Det är också allmänt rekommenderas att använda enkla citattecken i stället för citattecken.
Citationstecken har effekter på variabeldefinitioner,
särskilt vilket får dem att utvärderas i stället att stoppa det.
Varför skulle vi vilja att stoppa utvärderingen?
Och hur gör offerter göra det för oss?
>> Här är ett kommando som du kanske tycker är intressant.
"Ls g * '
g *, som ni säkert vet, är ett jokertecken uttryck
för alla filnamn som börjar med g..
Om jag bara skriver in ett kommando ls g *, får jag en lista med alla dessa namn i min nuvarande katalog.
Om jag definierar det alias som det är här med citat,
det kommer att köra det kommandot i din nuvarande katalog där du kör det.
Men om du kör definitionen alias utan citattecken,
det kommer att utvärdera joker g * när den körs detta definiera kommando.
Så definitionen av alias kommer att ls följt av listan med filer i katalogen
i vilken kommandot alias exekveras
oavsett var du faktiskt har för avsikt att köra kommandot.
Det är inte för mycket användning, och de enkla citationstecken hindrar utvärdering av asterisk.
Så du bara få definitionen varelse ls g *.
Sen när du kör alias, LGS, då uttrycker det som.
Nu finns det inga citat, och det kommer att utvärdera asterisk när du kör kommandot alias.
Så det är en sak.
Dubbla citat skulle ha samma effekt här,
men det finns andra fall där citattecken inte skulle fungera så bra.
>> Här är en till.
Du kanske vet kommandot grep.
Den grep kommando kan användas för att skanna en fil för linjer som vissa strängar.
Så låt oss gå över hit och jag ska avsluta min Bourne-skal.
Okej. Här är en fil.
Låt oss säga att det är grep abc strängar. Där är det.
Om jag gör grep zddd, jag får ingenting. Okej.
Så den hittar en sträng, det rapporterar, det spelar inte, det spelar inte rapportera det.
Den matar ut alla rader som har den strängen på det.
Det finns alla möjliga alternativ här som du kan hitta i dokumentationen.
Här är ett sätt att göra det.
Vad sägs om den här, alias grabc 'grep abc "?
Det kommer att omfatta 1 argument när aliaset är definierad.
Så om jag gör det här, nu, om jag gör grabc,
nu alias omfattar mer än det enkla kommandot. Det har också argumentet.
Så långt som fungerar.
Jag har ett annat kommando här, den här, så de är olika strängar i det
och visa att detta inte hitta något där eftersom det inte matchar.
>> Vad händer om jag vill ha med i definitionen alias filen som jag ska söka
och jag vill ge som ett argument till alias strängen som jag letar efter?
Jag skulle vilja säga abc som argument till min pseudonym,
men det alias redan bestämt filen.
Och det är där detta uttryck kommer in
Lägg märke till här har vi grep precis som tidigare.
Vi har filen här, strängar.
\! ^, Typ av en udda uttryck, antar jag, om du inte har sett det här förut.
Utropstecken visas en del av den C-shell historia mekanism.
Det kan påminna om tidigare kommandon, kan den återkalla argument till dessa kommandon och så vidare.
Historien mekanism används som en del av aliasing.
Om du anger en rad efter utropstecken, kommer det att hänvisa till denna rad i historiklistan
som vi inte kommer att komma in nu, eftersom det är en helt annan fråga.
Det är möjligt att ange en del av en linje.
Så 03:02! Skulle vara det andra argumentet i kommandonummer 3.
Den cirkumflex här i detta uttryck står för det första argumentet.
Om du inte ger det en indikation på vilket kommando du hänvisar till,
den hänvisar till den omedelbart föregående kommando,
och cirkumflex är en symbol för det första argumentet.
Eftersom det är cirkumflex och inte antalet, behöver du inte använda kolon,
så! ^ innebär det första argumentet till föregående kommando.
Lite blandat här.
I det här fallet, när du använder detta som en definition alias,
historia hänvisningen hänvisar till de kommandon där alias används.
Så detta kommer tillbaka 1 kommando som en historia operation,
men som ett alias operation den hänvisar till kommandot som du skulle skriva,
säga, grstrings_file.
Vi har de citat här i det. Vad är det omvända snedstrecket för?
I detta fall, liksom på andra håll, vi vill inte köra historien mekanismen
samtidigt definiera alias.
Om vi ​​inte hade omvänt snedstreck där, skulle skalet dra in det första argumentet
av kommandot precis innan det körde detta alias kommando, som vi inte vill ha.
Vi vill att det ska byggas in i kommandot alias att kalla in ett argument senare.
Apostrof inte undgå ett utropstecken, historia referens.
Kanske vet du uttrycket fly innebär att ändra innebörden av något.
I det här fallet betyder det att stoppa något från att ha en speciell betydelse.
Utropstecken har speciell betydelse är historia.
Escape och det har inte den innebörden.
Citat gör inte det, omvänt snedstreck gör.
Så vi faktiskt använder två nivåer för att fly hit.
Jag kommer att flytta den här kommandot i det andra fönstret utan att skriva det
genom att använda dessa redigeringsåtgärder, som du kan ha nytta av.
Något annat här ska jag visa dig.
Om du bara skriva alias utan argument, säger det dig alla dina argument.
Det här är ett gäng alias jag redan hade här
förutom de som jag har använt här i dag.
Men om jag skriver bara med namnet på ett alias, säger det mig vad det betyder.
Observera att citat är borta och det omvända snedstrecket är borta.
Denna sträng här är resultatet av att alias definition,
och nu har det bara! ^ i den.
Det här kommer att se ut i filen strängar för någonting.
Så om jag gör grstrings_file strängar, det gjorde jag inte ge den något att leta efter det,
men det ser i strängar.
Den hittade inte ordet strängar i filen strängar, men det finna abc.
Och den inte hittar det.
Så här ger vi ett argument som slår in i definitionen av alias,
som sätts in i den.
Det är där detta uttryck kommer ifrån.
Du kan använda mer än 1.
Cirkumflex är en symbol för det första argumentet.
Om du vill använda ett andra argument, skulle du då säga: 2.
Det finns ingen särskild symbol för det andra argumentet.
Och eftersom du använder en siffra, skulle du behöva använda kolon.
Det finns dock ett annat val här.
Dollartecknet står för det sista argumentet.
Och eftersom det är en symbol, kan du utelämna tjocktarmen.
Så det skulle vara det sista argumentet i listan.
Och det finns också att en.
Asterisk betyder allt, så det här är den fullständiga argumentlistan,
och igen, kan du utelämna tjocktarmen eftersom det inte är en siffra.
Jag hoppas att ni alla observera allt detta.
>> Historien Mekanismen kan gå tillbaka till tidigare rader i historiklistan.
Du kan göra detta i en definition alias.
Jag har aldrig sett detta gjort.
Det skulle få till följd att dra ut tidigare kommandon från historielistan
när du kör alias, som kan vara olika kommandon
beroende på när och var du kör det.
Möjligen kanske du vill dra ut en sådan hänvisning
bara veta vad ett tidigare kommando var.
Jag har aldrig sett detta hända.
Jag antar att någon kanske vill, men det är mycket osannolikt.
Det finns en annan sak här.
Om du använder den historia-typ referens,
då endast de argument till vilka det finns en sådan hänvisning används.
Om du har ett alias definition som inte använder en referens historia-typ,
om det bara blir början av kommandot
och du har ytterligare argument, då allt du skriver efter detta
kommer att läggas till kommandot.
I det här fallet, det exempel jag gav bara där, använde vi det första argumentet;
Vi använde inte några andra.
Om andra argument hade fått på kommandoraden, skulle de inte användas.
Så om du använder historien referens alls, då måste du använda den för att få något argument.
>> Det finns en annan sak här vill jag bara nämna, dels parentes,
nämligen att denna historia mekanism med utropstecken
går tillbaka till den ursprungliga C-shell.
Den tcsh introducerade historie operationer
som använder den typ av kommandon och strängar från redaktionen,
antingen Emacs eller VI.
Min personliga åsikt är Emacs är mycket lättare att använda för detta ändamål
även om du använder vi för din vanliga redigering.
Det finns olika kommandon i Emacs, som nu är anpassade för historien.
Kontroll P får föregående rad i historiklistan.
En annan kontroll P får du den innan dess.
Den uppåtpilen gör samma sak.
Kontroll N blir nästa kommando om du redan har rullat tillbaka vissa sätt.
Pil ned gör det också.
Du kan flytta vänster till höger med pilarna och diverse andra saker.
Detta kan göra bruk av historien mekanism
mycket enklare än att använda utropstecken syntax,
men du skulle inte använda det i en definition alias.
Vi kommer att gå över att en annan gång.
>> Variabler.
Du vet vad variabler i programmeringsspråk.
Skalen har dem också.
Den C-shell använder kommandot set för att tilldela variabler,
så som sätter variabeln a till värdet av b -
som sagt, en värdelös definition men en illustration av hur det används.
Den inställda kommandot kommer att skapa en variabel om den inte redan finns.
De positionsparametrar för skalskript kan anses vara variabler,
men användningen av dem och reglerna för dem är något annorlunda.
Du kan inte tilldela ett värde till $ 1 under loppet av ett skript.
Du måste definiera en ny variabel för detta ändamål, om några av er ville.
Skriv in utan argument, och du får en lista över alla för tillfället definierade variabler.
Och låt oss komma över till min andra skal här och se vad vi får om vi gör det.
Ganska lång lista där, eller hur?
Rulla upp lite. Titta på allt det där.
Några av dessa saker definieras automatiskt av skalet.
Skalet skapar variabeln och ger den ett värde.
Några av dem som definieras av skalet men sedan omdefinieras av användaren
enligt hans önskemål.
Och en del av dem är skapade av användaren beroende på vad han gör den dagen.
Det är bara in utan argument.
Det är en udda inslag här i denna sak.
Det måste vara antingen något mellanrum mellan likhetstecknet och variabelnamnet
och värdet eller utrymmen på båda sidor om likhetstecknet,
som i det här.
Detta kommer inte att fungera, och detta faktiskt är ett giltigt kommando
men det kommer inte göra vad du tänker.
Detta kommando kommer att arbeta för om du bara säga satt och ett variabelnamn
utan likhetstecken eller ställa och ett variabelnamn med ett likhetstecken och inget värde,
det kommer att ställa in variabeln på ett nollvärde.
Så satt a = är ett giltigt kommando.
Kommandot set kan definiera mer än 1 variabel på samma rad.
Så här kommandot här har effekten av att definiera både a och b till null-värden.
Förmodligen inte vad du vill.
Denna en här, som nämndes tidigare, kommer att leda till ett fel
eftersom = b inte är ett giltigt uttryck.
Ett variabelnamn får inte börja med likhetstecken.
Och det finns dessa ytterligare saker här.
De kolon användes för att välja argument från historielinjer,
och de kan användas - och jag ville inte gå in i tidigare - att ändra dessa saker.
De kan också användas för att modifiera skalvariabler.
Den här här, $ a, har ett värde.
: R kommer att ta bort en förlängning.
En förlängning kommer att vara vad som helst efter en punkt,
en prick och allt efter den i slutet av en fil,
först i slutet av listan efter det sista snedstrecket.
Så jag har det här.
en är det. Det kommer att släppa den. O..
Om det inte finns någon förlängning, bara de sökvägar efter sista snedstrecket, kommer det att ha någon effekt.
a: h, att rörlig uttryck, kommer att ta bort det sista elementet i en kataloglista,
igen, först efter att den sista snedstreck.
Så / a / b / c blir / a / b,
men detta ändras eftersom elementet efter det att förteckningen är null.
Här finns det något som också vill jag betona.
Dessa kval inte söka efter förekomsten av dessa filer.
De ser bara för strängar.
Dessa är avsedda att manipulera filnamn, sökvägar,
men de kan användas på varje sträng, även om det inte är ett filnamn.
Och de ser inte att det finns,
så om det inte finns någon sådan fil, / a / b / c, det fungerar fortfarande.
Oavsett om det är till någon nytta är en annan fråga, men det fungerar fortfarande.
Variabler är olika i de Bourne skal. Vi kommer till det senare.
Dollartecken kan undkom precis som utropstecken och asterisk.
Dollartecken kan vara ett omvänt snedstreck eller enkla citationstecken.
Citationstecken har den udda effekt i alla skal
att tvinga utvärderingen av ett dollartecken variabel uttryck.
Så om det är som rymt ett sätt, kan de dubbla citattecken medföra
att orsaka att den kan utvärderas på något sätt.
Det är lite förvirrande.
Om det finns flera nivåer av att fly, till exempel enkla citationstecken inne citationstecken
eller citattecken inuti enkla citattecken, bör du testa att se vad som kommer att hända
till en variabel om du använder en.
Dessa två situationer - dubbel insidan av singel, singel insidan av dubbel -
inte nödvändigtvis ger samma resultat.
Miljövariabler, bundna C-skalet variabler.
Miljövariabler är också variabler i C-skalet,
och de är också variabler i andra skal också.
I C-skalet, de är distinkta uppsättningar.
De saker jag sa tidigare är om skalvariabler.
Miljövariabler är en distinkt uppsättning variabler
med undantag av flera variabler som vi kallar bundna variabler,
som är mycket viktiga och vi kommer att få in dem senare.
Miljövariabler automatiskt förs vidare
till snäckor eller kommandon som körs från ditt skal.
De andra saker inte. De skalet variabler, alias inte. Miljövariabler är.
Det är därför vi kallar dem miljövariabler,
Tanken är att miljön sträcker sig förbi just din aktuella skalet.
De kan användas för att definiera saker för kommandon.
Här är ett exempel. PRINTER, LPDEST.
Båda dessa variabler kan definiera en skrivare som ett kommando kommer att använda för att skriva ut saker.
Om du har flera skrivare runt, kanske du vill sätta den du gillar.
Anledningen till att vi har två variabler är att olika typer av kommandon skrevs
med hjälp av dessa olika variabler.
Du kan ge dem olika värden.
Mycket troligt att du ska ge dem båda samma värde.
Dessa saker fungerar eftersom de kommandon som gör utskrifter
var programmerade att undersöka värdena för dessa variabler.
Om ett program inte var skrivna på det sättet, om det skrevs för att göra något annat,
variabeln skulle vara irrelevant.
Så operativsystemet inte är ute efter dessa variabler
varje gång du hänvisar till en skrivare.
Ett kommando som gör utskriften är ute efter dessa variabler om den är programmerad så.
Dessa variabler definieras ofta i dina inställningsfiler
men inte nödvändigtvis.
Du kan definiera dem på kommandoraden.
De kan definieras på ett kommando.
Ett kommando som kör något kan ha ett eget val av variabler -
variabler som är unika för en viss programvarupaket, till exempel.
De kommer att fastställas när du kör det paketet.
Hur är dessa variabler skickas till en sub-shell?
När en sub-skal är skrivet, betyder inte att skriva in i det området.
Det område av sub-skal som ägnas åt miljövariabler
är inte skriven av sub-tanken, den är skriven av kopiering.
När du kör ett vanligt kommando, till exempel dessa kommandon för att skriva ut eller vad som helst,
De börjar med att skapa ett nytt skal.
Skalet skapar ett skal och sedan skriver över en del av det
med kommandot som du kör, vilket är lite förvirrande,
men det är hur dessa kommandon får miljövariablerna
att de sedan hänvisa till senare.
Kommandot här för att definiera variabeln setenv.
Det är hur du definierar det. Det är tre element: setenv, variabel, värde.
Om du bara gör setenv utan argument, vad får du?
En lista på alla dessa variabler.
Återigen, det är en fin lång lista och i detta fall, liksom i de andra,
Dessa variabler definieras till stor del av min inloggning operation av skalet själv
snarare än av något jag gjorde.
Det finns en annan kommando här, printenv.
Det skriver också ut i miljön.
Lägg märke till det sista här, redaktör = vi.
Det säger att om jag använder något som kräver en redaktör
och jag vill inte ange en editor och det gör mig valet, kan det ge mig vi.
Vad händer om jag gör printenv EDITOR? Den talar om för mig vad det är.
Precis innan det fanns en variabel, MINDRE.
Dessa är dina standardinställningar alternativ när jag kör MINDRE kommandot,
som visar filer.
Så om jag gör det, kan printenv ta 1 argument eller 0 argument,
inte mer än 1.
Det finns andra kommandon också, men vi kommer inte att få in allt det i dag.
Kom ihåg att det var de modifierare för skalvariabler som: h,
som kommer att släppa det sista elementet i en sökväg,
eller: r, som kommer att släppa en förlängning.
De som nu tillämpas på miljövariablerna också. De brukade inte.
Det brukade vara så att de inte skulle kunna ändras. Nu kan de vara.
Det är en av de framsteg med utvecklingen av skalen genom åren.
Jag sa att skalen som en del av de miljöer
och skalvariabler i C-skalet är, med några undantag, distinkta uppsättningar.
Du kan skapa en miljövariabel och en skalvariabel med samma namn.
De kommer att vara olika variabler, de kan ha olika värden.
Justering av värdet i en kommer inte ändra värdet på den andra.
Dessa variabler är alla utvärderas med dollartecken - $ a, $ vad.
Så vad händer om du har det? Vet du vilken som du får?
I mina tester fick jag skalvariabel,
men detta inte är dokumenterat och man kan inte lita på det.
Så jag ber er, är att skapa skal och miljövariabler
med samma namn en bra idé? Nej Okej.
Vilka är de stora undantag i vilken miljö och skalvariabler
är kopplade till varandra?
Det finns dessa 4.
Versalt TERM miljövariabel,
skal variabel term i små bokstäver, typ av terminalemulering.
Jag ska bara gå hit och jag kommer att göra eko, ett användbart kommando här,
$ TERM $ sikt. Och där.
xterm är en terminal typ av fönster som visas i X Window System.
xterm-färg är en variant av det som gör att olika färger.
Varför definierar vi dessa? Vad är det bra för?
Kommandon som organiserar om skärmen som redaktören
skicka speciella sekvenser, så kallade escape-sekvenser,
till en terminal eller ett fönster för att arrangera om den och så vidare.
Dessa sekvenser är olika för olika typer av terminaler.
Detta säger det vilka som ska användas.
Ibland finns det frågor där.
Du kanske vill ändra på det.
Om saker inte fungerar, ibland terminaltypen är inställd fel,
du kanske kan fixa det genom att omdefiniera begreppet variabel.
I dessa fall förändras en variabel, miljön variabel eller skalet variabel,
bör ändra den andra.
Jag har upptäckt genom erfarenhet att ändra TERM med versaler
inte alltid ändra skalvariabel term med små bokstäver.
Detta är en bugg.
Jag vet inte om det är alltid sant. För det mesta är det inte sant, men det kan vara.
Så om du gör en förändring, bara kolla som.
Det är inte ofta som du behöver ändra detta värde, men då och då du gör.
Miljövariabeln ANVÄNDARE.
Återigen, miljövariabel med versaler, skal variabel i små bokstäver.
Det här är ditt användarnamn.
Det är endast under mycket exceptionella omständigheter
som du skulle vilja ändra på det.
Om ditt användarnamn är någon annan, kan det kasta alla möjliga saker.
Hemkatalog, användarens hemkatalog.
Återigen, skulle du inte vill ändra på det.
Lägg märke till i alla dessa fall och det som vi är på väg att täcka, sökvägen variabeln,
miljövariabel är i versaler och den bundna skalvariabel är med små bokstäver.
Om du ändrar en, bör du byta den andra.
Denna typ av bindning kan inte fastställas eftersom du inte kan binda två variabler,
annat än dessa 4, och bindningen i dessa variabler kan inte göras ogjort,
du kan inte skilja dem åt.
Så dessa 4 par variabler är bundna.
De kommer alltid att finnas. Inga andra kommer att vara.
Dessutom skulle det vara möjligt att skapa variabler med samma namn
av de motsatta typer.
Du kan göra en skalvariabel term med små bokstäver
eller miljövariabeln TERM med versaler.
Dessa variabler skulle vara oberoende av dessa parade variabler
och de skulle vara oberoende av varandra.
Jag kan inte föreställa mig varför du skulle göra det om du inte vill förvirra folk.
Den här här, stig variabel, är detta en riktigt viktig.
En annan sak här är att det kan finnas fall
variabler med liknande parade namn som inte är bundna till varandra.
Det kan vara variabler, skal och skal, med stora och små bokstäver.
Baserat på det namnet, vet du inte om den variabeln är en skalvariabel
eller en miljövariabel, och de är inte bundna till varandra.
Så den typen av parade namn innebär inte bundna variabler.
Stigen variabel, som jag visade tidigare,
är en lista med sökvägar där skalet letar efter kommandon.
Låt oss komma över till detta fönster här och vi ska göra echo $ PATH, versaler -
miljövariabel - echo $ bana, små bokstäver - shell variabel.
Observera att listan med kataloger är densamma. Dessa är bundna.
Ändra en, ändrar du den andra.
I miljövariabeln elementen är separerade med kolon. Lägg märke till att.
De skalvariabler separeras med mellanslag.
Denna miljövariabel är en enda sträng.
Skalet variabeln är en array.
The Bourne shell hade inte arrayer.
Pucklar gör, men detta är redan en fast del av skalet.
Detta är en enda sträng och inte en array.
I C-skalet hade alltid arrayer.
De arrayer är mycket lättare att arbeta med.
Du kan hänvisa till delar av den.
Så echo $ path [1] och jag får / usr / bin, det första elementet.
Återigen, kom ihåg dollartecken står för det sista elementet i historiklistan.
Vad händer där? Man försökte hitta dollartecken som en variabel symbol.
Jag fly den. Oj. Det skulle inte ta det heller.
Några av dessa saker inte fungerar så bra.
Kanske ska vi bara lämna ut det.
Asterisk hänvisar till det hela, men det är vad du får om du inte anger ett element.
Ett annat sätt att fältvariabler kan manipuleras,
antal element där, 7 element.
Här lägger vi nummertecken före variabelnamnet.
Här är en till. Sätt ett frågetecken där.
Det är ett logiskt värde. Det indikerar att variabeln existerar.
Det är ett annat sätt att arbeta med variabler.
Det, förresten, inte behöver vara en array variabel.
Det skulle kunna vara vilken variabel.
Och om jag gör det, det finns ingen sådan variabel och jag får en 0.
En annan liten sak där om variabla utvärderingar.
Tillbaka till detta här, om du av någon anledning ville arbeta med detta
snarare än att arbeta med matrisen, skalvariabel,
det finns kommandon som kan separera dessa saker baserat på tjocktarmen.
Faktum är att om du ska göra detta i Bash skal möjligen,
någon form av ett manus, det skulle vara nog hur du skulle göra det.
Men i C-skalet är det mycket lättare att använda arrayen.
I Bourne-skalet, är variabler som tilldelas av ett enda uttryck som detta,
gillar hur du kan tilldela en variabel i ett programmeringsspråk,
och här måste det finnas några blanksteg.
Det är nödvändigt att det bara vara en sträng.
I Bourne-typ skal, alla variabler skalvariabler.
Miljövariabler är en delmängd av de skalvariabler.
De skiljer sig från de icke-miljövariablerna genom att exportera.
Kommandot för att göra det är export, liksom export PRINTER.
Om vi ​​skulle definiera en sådan variabel,
om vi ville ha en utskriftskommando för att hitta den, skulle det vara en miljövariabel,
och det är hur vi gör det en.
Här finns det något slags förvirrande.
Detta uttryck, export till miljön, härrör från denna Bourne shell koncept,
och ändå som uttrycket används i beskrivning av den C-skal,
där det inte finns något sådant kommando som export.
Om du bara säga export av sig själv, får du en lista på export -
Så om jag bara exporterar här, inget sådant.
Okej, det går vi.
Dessa saker, förresten, är också definieras av skalet.
Jag definierade inte någon av dessa själv.
Skalet gör alla möjliga saker av sig själv.
Det borde göra saker automatiskt.
I Bash eller Korn-skalet kan du köra ett kommando som det här,
vilket både ger en variabel ett värde och exportera den i 1-kommandot.
I Bourne-skal de vara separata kommandon som export en.
Här är en annan aspekt som är förvirrande.
Den inställda kommando i C-skalet definierar variabler
och utan argument berättar vad de variablernas värden.
I Bash skal, den inställda kommandot utan argument gör samma sak,
men med argument som den gör något helt annat.
Så dessa är de olika argument här.
Några av dessa är miljövariabler, vissa av dem är skalvariabler.
Alla är skalvariabler egentligen. Några av dem är miljövariabler.
Den inställda kommando med argument kan användas för att styra
på positions parametrar till ett skript,
vilket är ett sätt att få dem alla på en gång.
Vi kan inte riktigt gå in på det i dag.
Den kan också användas för att byta skal beteende.
Särskilt i Bash det finns variabler som kommer att avgöra hur skalet fungerar.
Sen också just detta ett kommando som du kan se, detta kommando.
Typsätta följt av variabler och variabeltyper används i Korn-och Bash skal.
Det är inte obligatoriskt, men det kan användas för att begränsa värdena på variablerna,
vilket kan vara användbart för att förhindra fel, och det är ganska vanligt.
Så jag bara nämna att om du ser den någonstans.
Den där kommando.
Minns jag nämnde tidigare den där kommando i C-skalet,
som kan berätta om platsen för ett kommando sökväg.
Här är kommandosubstitution.
Du bör hitta på tangentbordet någonstans en karaktär som ser ut så här.
Läget på tangentbordet kommer att variera.
Vi har kallat det backquote. Det handlar om storleken på en offert.
Den går från övre vänstra till nedre högra.
Här på min Mac-tangentbord är det i det övre vänstra hörnet.
Detta tecken kan användas för att utföra ett kommando i ett kommando.
Om du har ett uttryck inne backquotes,
att uttrycket är ett kommando, det körs.
Utgången av detta kommando
Därefter substitueras för hela backquote uttryck
inne en längre kommando som sedan körs med att produktionen
som en del av sin sträng av argument och så vidare.
Här är ett kommando som använder det.
Låt oss visa att verksamheten här.
Låt oss gå upp hit, ta ut backquotes.
Kontroll A får mig till början av raden med Emacs redigering syntax.
Hittills sökvägar är det där gör,
men när jag gör det så här, då pluggar den i listan över sökvägar
i stället för detta hela backquote expression och körningar ls-l på dem.
Typ av bekvämt, va?
Så det är en snygg sak. Det är så backquotes fungerar.
Nu går vi ner lite längre.
Dessa alias. Jag faktiskt använda dessa.
Jag ska försöka få detta i med 1 redigering.
Okej.
Nu ska vi se hur dessa definitioner kom ut.
alias LBH talar om för mig hur det definieras.
Lägg märke till att det är just detta, men de yttre citat har tagits bort
och utropstecken tas bort.
*, Komplett lista på alla argument.
I en definition alias den kommer att tillämpa tillbaka till där jag använder här.
LBH ksh bash. Okej.
Se hur det fungerar? Det sparar mig några skriva.
Låt oss gå upp lite bara för att nämna något annat här.
Notera här dessa olika skal. Jag borde ha nämnt detta tidigare.
CSH har en 2 hit och det gör / bin / tcsh.
Vi kunde fastställa på annat sätt att de är faktiskt samma fil.
Kom ihåg att jag sa om du skriver sh du bash.
Skriv in det här och du får detta.
Men de som inte är kopplade. De har enkel som det.
Och det är inte den typ av fil som kan ringa en annan.
Så de är separata filer, i C-skal som är de samma fil.
Här tillbaka, den andra här, detta alias,
notera som kör detta kommando, fil.
Det alias kör det. File berättar vilken typ av fil.
Så FWH ksh bash. Okej.
Det är utsignalen från kommandofilen.
Jag vet inte om du vet vad det betyder här,
Mach-O universell binär med 2 arkitekturer.
Det finns två möjliga processortyper i Mac,
och vissa program skrevs för att kunna köra med båda,
och kommandofilen kan avgöra det, så det är vad det här betyder.
Båda dessa filer var skrivna på det sättet.
Så ser vi hur alias fungerar, vi ser hur backquote fungerar,
Vi ser hur den faktiska fil ls eller fil fungerar.
Det kanske inte fungerar. Försök "var där" och "LBH där". Okej, låt oss prova det.
där där.
där är ett skal inbyggd.
Kom ihåg tidigare vi visade att Bash inte hade där.
Om du skriver var i Bash skal, får du ett felmeddelande.
Det är bara en del av skalet snarare än att vara ett separat kommando.
Vad händer om jag typ LBH söker där? Se vad som händer där.
Ran var där, fick denna utgång, och sedan försökte köra ls
såsom l på var är ett skal inbyggd.
var är det, men de andra som inte existerar.
Ingen av dessa finns, faktiskt.
Så det fungerar inte alltid, och det visar också hur vissa saker
gör inte riktigt vad du kanske trodde.
Låt oss gå ner lite längre här.
Det här är i Bash. Det är också kommandosubstitution som backquote.
Men till skillnad från backquote, använder den här variabeln stil.
Det finns ett antal uttryck som börjar med ett dollartecken,
och medan dessa inte variabler, lånade de användningen av dollartecken
för att ange ett uttryck för något slag.
Det kan vara omgiven av parenteser eller konsoler eller dubbla parenteser,
som har ett annat syfte.
Enstaka parentes här är ett kommando byte precis som backquotes.
Dubbla parenteser är faktiskt en aritmetisk operation.
Det finns andra syntaxer, övrig verksamhet.
Backquote syntax finns i pucklar.
Detta är emellertid en föredragen. Det är mycket lättare att läsa och det gör att häckning.
Du kan ha inne $ (kommando) ett annat kommando,
något liknande -
Jag får en lista där.
Det skulle fungera om jag hade backquote också.
Vad händer om jag vill göra något liknande -
Du skulle nog faktiskt inte använda detta kommando,
men denna interna substitution kommando ekar namnen på alla filer som börjar med en,
då denna man kör ls-l på dessa filer,
och sedan detta ekar bara produktionen.
Du har förmodligen inte skulle göra detta, du bara skulle göra ekot eller ls,
men detta illustrerar hur häckande kommandon fungerar.
Så bara en annan funktion här.
Jag nämnde detta tidigare, att när du har var i C-skalet,
skriver arbeten i Bourne-typ skal för att lokalisera kommandon.
Inbyggda kommandon, precis vad jag sa där.
Kommandon är en del av skalet, som var.
När skalet exekverar ett kommando som ls, lokaliserar det den genom banan,
finner det i någon katalog någonstans,
läser det i minnet, skapar ett nytt skal,
läser kommandot ls eller vad i skalet
där miljövariabler redan finns,
och då den överför exekvering till den.
Inbyggd kommando, är koden för det kommandot inne i skalet,
så skalet börjar bara utföra en del av sin egen kod.
där är sådant kommando. Det blir faktiskt snabbare.
Det behöver inte läsa något i minnet, det är redan i minnet.
Inbyggda kommandon har alltid företräde framför kommandon med samma namn.
Kommandon som finns i katalogerna i sökvägen kan ha samma namn,
kommandon i olika kataloger, filer i olika kataloger.
Det som inträffar tidigare i vägen är den som du får.
Om det finns ett inbyggt kommando får du alltid det.
Det finns inget sätt att ge den en lägre prioritet än ett kommando i vägen.
Om du vill få den vägen kommando, kan du skriva den fullständiga sökvägen.
Om det fanns ett kommando där i vägen någonstans,
du kan skriva / bin / där och du skulle få det.
Om du inte vill skriva hela sökvägen, kan du definiera ett alias.
Faktum är att om du gav alias samma namn som det inbyggda kommandot, skulle det fungera
eftersom definitionen alias utvärderas
innan skalet bestämmer att det är ett inbyggt kommando som ska köras.
Då detta blir lite mer komplicerat med vissa kommandon här.
Fallet med vissa kommandon faktiskt inbyggda kommandon och i vägen.
En av dem är eko, kommandot jag använde bara en liten stund sedan i dessa exempel.
Echo är ett kommando i vägen och det är i varje skal.
De behöver inte nödvändigtvis alla beter sig på samma sätt.
Det var ursprungligen ett kommando bara i vägen.
Den byggdes till skalen senare.
Eftersom det finns alternativ som är beroende på miljön
och kommandoraden, de inbyggda kommandon
skrevs för att fungera på samma sätt som kommandot som hade varit i vägen,
det är osannolikt att de skulle ha skrivits på det sättet
om kommandot inte hade redan skrivits för sökvägen.
Så det här har biverkningar. Dess historia har effekter här.
Det finns alternativ där.
Det finns även ett alternativ som definieras av en variabel i tcsh kallas echo_style.
Det är en av dessa variabler som kan ändra det sätt som eko ​​verk.
Det finns andra fall där du kan tilldela en variabel
som förändrar sättet att skalet operationen, inklusive ett inbyggt kommando, fungerar.
Det skulle inte påverka något annat
eftersom andra kommandon inte har tillgång till de skalvariabler,
endast de miljövariabler.
Men skal operationer kan läsa skalvariabler.
Det kommer inte att fungera för csh. Det är bara tcsh. Det är en av de förbättringar.
Parsning har sekvenser när det utvärderar metatecken,
när det utvärderar variabler, alias, historia referenser.
Det finns en särskild ordning för dessa saker.
Om den gör saker i en viss sekvens
och blir till något som är ett uttryck för ett slags
som redan har utvärderats, kommer det inte att utvärdera den igen.
Om det blir det, så kommer det bara gå på karaktärerna.
Så om utvärdering av vissa uttryck som kommandosubstitution
eller variabel eller vad som helst ger upphov till en expressions
som du skulle vilja att utvärderas,
det fungerar bara om att utvärdering sker senare i sekvensen.
Jag hoppas att jag är klar där.
Det parssekvens, en operation i C-skalet,
är inte samma för inbyggda kommandon som det är för icke-inbyggda kommandon.
Jag är inte säker på om Bash där.
Till exempel, framställs om en skalvariabel en historia referens,
det förmodligen inte skulle gå tillbaka i historien.
Det skulle bara få utropstecken.
I själva verket kan vi bara försöka att ut just nu.
ställa en = och vi måste sätta detta i det.
Vänta. Ursäkta. Jag gjorde detta i Bash. Jag ville göra det här.
Se, så det inte bedöma att historien referens
eftersom det var redan förbi den punkt att utvärdera historie uttryck
när den utvärderade variabeln.
Så det är en effekt av tolkning.
Och återigen, är inbyggda kommandon inte gjort på samma sätt.
Okej. Låt oss gå till nästa här.
Detta är tänkt att vara en linje, men det gör det lättare att läsa.
Vad gör det?
Ni minns kanske att vi kan utvärdera asterisker som filnamnsjokertecken,
och det finns andra filnamn jokertecken som frågetecken och konsoluttryck.
Denna typ av utvärdering kallas globbing.
ställa noglob i början av detta kommando säger gör inte det.
unset noglob säger gå tillbaka till att göra det.
Observera att uppsättningen glob skulle inte ha den effekten.
I vardagligt språk, skulle sätta glob eller urkopplat noglob verkar vara likvärdiga,
men här är det inte. Det är urkopplat noglob.
Nu TSET. TSET stod för terminal set.
Det används inte så ofta nu, men innan fönstersystem blev tillgängliga
och du hade en enda terminal, kanske du måste bestämma vilken typ.
Och om något skulle komma över ett Ethernet-eller från nätverket,
kanske du vill säga att det är en VT100.
VT100 är lite av en standard i terminalen verksamheten. Den kommer från DEC terminalen.
Om du bara gör uppringd - märker det? Detta går tillbaka en bit, va?
Så om vi bara gör TSET över här,
Om jag bara tset, det återställer min terminal, men du inte såg någonting.
Det tog inte egentligen ändra någonting.
-S
Okej.
setenv TERM xterm-color.
Vi vet redan att termen var inställd på det sättet, så att inte förändrades.
Det är det sätt som vi skulle vilja göra det.
Men märker att det här kommandot, tset-s, bara utgångs dessa kommandon. Det tog inte köra dem.
Det tog inte köra dessa kommandon, det mata ut dem.
Så detta är tänkt att producera kommandon som sedan kommer att köras.
Du minns kommandot i den filen jag visade bara att du hade en Q i den.
Så låt oss göra det.
Q trycker viss utgång, men det spelar ingen roll här, som ni kan se.
Jag gör bara att visa att det inte spelade någon roll.
Detta är i backquote syntax.
Notera backquote här, backquote här.
Jag utelämnar dessa saker här.
Dessa fall av att berätta det vad man ska göra
När det gäller vissa typer av terminaler -
Ethernet, nätverk, uppringd, vad har du.
Det spelar ingen roll här eftersom vi inte egentligen gör någon av dessa saker.
Jag bara illustrerar kommandot.
Om jag gör det här med backquote, vad ska jag få?
Också märker här att detta ingick den inställda noglob och unset noglob,
så de nu är överflödiga i definitionen.
Det var inte alltid sant, men nu är de som ingår i detta kommando.
Men låt oss se vad som händer om jag gör det
och gå till början av raden med kontroll A och jag gör det.
Okej, set: Kommando hittades inte. Det är ganska märkligt, eller hur?
set är ett välkänt kommando. Det är en del av skalet.
set: Kommando hittades inte? Varför är det?
Hmm. Nåväl, låt oss tänka på detta.
Det körs en backquote kommandosubstitution,
och som inträffar vid en viss del av sekvensen för tolkning av kommando.
set är ett inbyggt kommando.
Så när den gör det kommandot substitution,
det har redan kommit förbi den punkt att identifiera inbyggda kommandon.
Så den behandlar satt som om det vore ett kommando i sökvägen.
Naturligtvis går det inte att hitta det och du får ett felmeddelande.
Tja. Det är ett exempel på parssekvens.
Och vad gör vi åt det?
Lägg märke till denna mycket intressanta kommando här, eval.
Jag undrar vad det gör.
Om du tittar på manualen - och låt oss bara göra det
att visa hur förvirrande dessa handböcker är -
man tcsh, förvirrad manuell, hitta saker här är inte heller lätt.
Nu kör vi, eval arg, så att vi kan ha ett eller flera argument
och det finns en lista över saker där.
Behandlar de argument som indata till skalet
och exekverar de erhållna kommandon i samband med det aktuella skalet.
Detta är vanligtvis används för att utföra kommandon som genereras som resultat av kommandot
eller variabel substitution eftersom tolkning sker innan dessa ersättningar.
Mycket bra.
Och här är de till och med hänvisa till kommando tset för ett prov användning
som den jag just visade dig.
Nu måste jag få fönstret tillbaka till en bra plats.
Låt oss komma hit och vi ser att eval används strax dessförinnan.
Så låt oss se vad som händer om vi sätter - nu kör vi upp med pilarna till det kommandot
och kontroll A till början, eval.
Okej, så det fungerar.
När du gör eval, tar det som kommer efter det och gör det till ett kommando.
Detta gör det möjligt att i grunden analysera det två gånger.
Avsnittet här kör detta kommando inuti backquotes,
blir utgången.
Produktionen är tänkt att köras som dessa kommandon här som dessa
på den här och den här.
Så dessa kommandon är nu här i denna sekvens,
men dessa är inbyggda kommandon och det kan inte få dem direkt.
Så vi går till eval, plockar eval upp det, börjar det hela om igen, och det fungerar.
Ett exempel både på backquoting, eval, parsning, konsekvenser av tolkning,
och ett kommando som förmodligen är av mycket liten nytta för dig nu för tiden.
Okej. Okej, umask.
Låt oss titta på detta kommando här, umask 022. Jag undrar vad det gör.
Låt oss bara skriva umask med ingenting efter det. 22. Okej.
022 och göra det igen.
Som du kanske har gissat, umask utan argument talar om den aktuella masken;
umask med argument gör den det, men det var den jag redan hade.
Vad betyder 022 detta?
Det är här det skydd för en fil.
De bestämmer vem som får läsa eller skriva eller köra filen.
Skydd kallas också behörigheter.
R står för läsning, w för write,
och x, som inte finns där, står för exekvera.
Det finns 3 kategorier där.
De sista tre elementen i kategorin av användaren. De som gäller för mig som användare.
Dessa 3 här gäller för koncernen.
Filen tillhör en grupp, kan användaren tillhöra flera grupper,
men om användaren är i den grupp som den här filen tillhör,
då detta skydd kommer att gälla för honom, om han inte är användaren.
Och den här är alla andra.
Dessa kategorier är ömsesidigt uteslutande.
Användaren skyddet i detta för honom,
grupp skyddet i detta för medlemmar i gruppen andra än användaren,
och de andra skydden endast gälla för andra än användaren och gruppens medlemmar folket.
Om det finns ett r eller en w eller x, betyder det att skyddet har beviljats.
Om det finns ett bindestreck, betyder det att det inte är.
Det faktiskt finns andra saker som kan sättas in här förutom dessa,
som jag inte kommer att komma in nu.
Den umask definierar en standard för filer som du skapar.
Och som en mask, i grund och botten står det de bitar som du inte fastställts.
Hur har detta blivit bitar?
Om du tänker på var och en av dessa som ett oktalt tal,
Detta är den 1s bit, detta är 2: or, det är de 4s.
Så 0 till 7
kommer att beskriva vad kombinationen av r s, w s, och x är du har för dessa 3
och då ett liknande antal för dessa och sedan för dessa.
Så 022 betyder 0 för andra, 2 för gruppen, 2 för användaren.
Men det är en mask. Masken är det som du inte har.
Jag är ledsen. Jag gav dig bara saker i fel ordning.
Det är den första 3. Dessa 3 är användaren, dessa 3 är den grupp, dessa 3 är den andra.
Ledsen att jag gav dig dem i fel ordning.
Den 0, som är den första av dem, inte visa värdet,
men om ett nummer är inte där, det är en 0.
Det betyder att alla 3 av dessa skulle tillåtas.
Lägg märke till att det i just detta att x inte är tillåtet.
Skälet till detta är att skalet är kapabel att bestämma
om en fil ska verkställas eller inte.
Eftersom detta inte är en körbar fil, gjorde det inte ställa in x.
De två sätt som skrivrättigheter, den andra kategorin här,
den i mitten, nekas.
Så återigen, det är dessa saker som det förnekade.
Tja, är x tillåtet men det är inte här eftersom det inte är körbar
och på liknande sätt för de övriga.
Så det är en vanlig umask.
En annan vanlig man är 700 - ger dig allt och ingen annan som helst.
Och det finns andra möjligheter.
Jag ska gå tillbaka till det. Med hjälp av historien kan jag söka tillbaka för det, LBH till där.
Okej. Så här är det dessa skal.
Bash, ägaren som är systemkonto, kan göra allt.
Koncernen och alla andra kan göra läsa eller köra men inte skriva.
Det man inte ens tillåter ägaren att skriva till den.
Om ägaren ville skriva till den, systemkonto,
han skulle behöva ändra skyddet först.
Men återigen, sätter umask standard genom att maskera den,
genom att ange de bitar som inte kommer att ställas in.
Detta är typiskt i en av era teminitieringsfilerna, vilket är det. Cshrc för C-skal
eller. profilen för Bourne-typ skal.
Det kan vara någon annanstans även om det finns andra inställningsfiler på systemet.
Hur som helst, det är umask.
Det är något slags konstigt här,
och det är, varför finns det ett enda kommando för detta?
Om jag skriver detta, skulle jag göra det till en variabel, umask = något värde.
Varför finns det en hel kommando just för detta ändamål?
Anledningen är detta går bara tillbaka till ursprunget till Unix.
Unix var bara några programmeringsprojekt vid Bell Labs i början av 1970-talet.
Folk kom precis ihop till program.
De avsåg aldrig att bli ett världsomspännande operativsystem.
Olika människor skrev olika delar utan att tänka så mycket
om hur de skulle användas - ganska skissartad.
Och det kom ihop så där, och det är fortfarande så i vissa avseenden.
Så det speglar historien, och det finns fortfarande dessa inkonsekvenser och udda inslag i det.
Okej. Nästa man här.
Som jag skrev tidigare, är det C-skalet inte riktigt används mycket för programmering,
även om det kan vara.
Det kör långsammare, återigen avvägningen mellan interaktiv användning,
som har mer processor inblandade än hastighet,
vilket kan göra utan behandlingen.
De extra funktioner lagts till i Bourne-skalet av Korn och Bourne-again skal
verkar inte sakta ner dem, och jag vet inte varför det är.
Det kan bara bli bättre planering, men jag är inte i stånd att veta.
Hastighet här egentligen inte så stor roll, även om det nämns.
Anledningen är att skalskript faktiskt komma ganska snabbt.
Om det finns en hel del kommandon som i ett calculational program,
du förmodligen inte skulle göra det i ett skalskript.
Verksamheten finns ganska enkel och okomplicerad.
De som jag har upplevt som är för långsam
involverar upprepade applikationer av långsamma kommandon.
Jag nämnde tidigare att strömeditor sed. Detta kommando är långsam.
Om du kör sed många gånger, får du en långsam manus, men det är inte skalet som är långsam.
Köra den i Bourne-skalet kommer inte att vara mycket snabbare än att köra den i C-skalet,
även om det kanske är vissa fördelar där.
De ytterligare programmeringsmöjligheter, å andra sidan,
är viktiga anledningar till varför du skulle använda den Bourne-typ skal.
C-skalet har udda funktioner till det -
det faktum att du inte vet om en variabel är en skalvariabel eller en miljövariabel.
Det kan vara mycket förvirrande.
Det är inte så lätt att skriva
bara baserat på din erfarenhet av programmering i andra språk.
Jag tror att du kan hitta Bourne-typ skal mer överens med din erfarenhet.
Vissa manus, men kan vara tusentals rader långa.
De som jag har sett används för lapp operativsystem.
De kan köra mycket långsamt, men du behöver inte köra dem mycket ofta.
Det är bara när du gör patchning,
och det är bara systemadministratören som gör dessa saker,
så det är egentligen inte mycket av en fråga.
De som är hundra rader lång faktiskt köra ganska snabbt.
Att nämna det här, vad är dessa förbättringar?
Jag har redan nämnt några av dem - matriser, beräkningar,
de $ () uttryck för beräkningar i Bash skal,
den andra typen av kommandosubstitution.
Det finns olika typer av testkommandon
med vilken du kan göra villkorade tester om förekomsten av en fil eller annat.
Senast här, det här kommandot här.
Vad gör detta, och varför skulle någon använda det?
printenv variabelnamn.
Vi vet vad printenv gör. Det säger oss att värdet på en variabel.
Och printenv variabel inte för oss väldigt mycket eftersom det inte finns någon sådan variabel.
Blank.
Men låt oss ge det något meningsfullt.
Det är inte där heller. Okej. Jag antar att jag aldrig definierat det.
Låt oss bara kontrollera min omgivning.
Detta är ytterligare ett kommando med vilket du kan inspektera din miljö.
Det är gamla goda EDITOR, den vi såg tidigare.
Vad gör det?
Här har vi en backquote uttryck.
Notera att detta är den C-shell.
Så printenv REDAKTÖR kommer att ge oss ett värde på REDAKTÖR. Det är vi.
Och så kommer det att sätta det värdet till variabeln a, kommandot set.
Så nu om jag gör echo $ a, jag blir vi.
Det verkar inte särskilt användbar.
Men det faktiskt har ett syfte.
Eftersom vi inte vet om en variabel är en skalvariabel eller en miljövariabel
med hjälp av dollartecken utvärderings syntax, kan vi använda printenv
att se till att det är en miljövariabel.
Så om det fanns en skalvariabel redaktör, det skulle inte ha blivit det.
Detta fungerar endast med miljövariabel.
Om det fanns en skalvariabel och jag ville ha sitt värde,
Jag måste hitta något annat sätt att göra det.
Ett sätt att göra det skulle vara genom att göra set-och rörsystem.
Detta är en av de metatecken, specialtecken.
Den skickar utgången av inställda till någonting annat.
Låt oss se vad vi kan hitta där.
Ingenting. Okej. Låt oss bara se vad som finns där inne tillsammans.
Det var echo_style, den jag nämnde tidigare. Okej, låt oss göra det.
Kom ihåg att jag nämnde tidigare, echo_style
bestämmer hur echo kommandot kommer att köras.
bsd står för Berkeley Standard Distribution.
Detta är den Berkeley Unix från 1970-talet.
Det är ett av de sätt som ekar kan köras.
Ställa echo_style till det värdet i TC-skalet kommer att orsaka eko att bete sig på det sättet.
Så satt gör det, men satt bara blir skalvariabler.
Det skulle inte hitta Editor, som inte är en skalvariabel.
Ingenting.
Så det är ett sätt att särskilja dem.
Men det faktum att du måste gå igenom några konstiga kommando som det
att skilja mellan skalvariabler och miljövariabler
visar den typ av opraktisk naturen hos C-shell för vissa ändamål.
Och nu, är sist och kanske minst detta manualsidorna.
De av som du kanske vet, är mannen kommandot kort för manuell.
Man-sidorna för skalen är svåra att läsa. De är mycket lång.
De är organiserade på ett sätt som kan göra det svårt att hitta det du letar efter.
Så om du letar efter något med ett syfte,
du kanske inte vet om detta syfte är en skalvariabel eller något annat,
så du kanske inte vet var du ska leta efter den.
Du kan leta efter olika strängar, men strängarna är ofta upprepas.
Så det är i allmänhet svårt att läsa.
Vi bara tittade på TC-shell man-sidan lite innan för att hitta kommandot eval.
Vissa saker går fortare.
Ett tillvägagångssätt är att söka efter en sträng.
Du kan använda personsökaren.
Personsökaren har ett snedstreck för att leta efter ett kommando eller en sträng inuti en personsökare drift.
Mannen som standard kommer att använda personsökare, antingen vara mer eller mindre.
Jag vet inte om du är bekant med dem, men de kan visa filer bit för bit.
Jag har använt MINDRE att visa just dessa filer som vi har fått här.
Du kan söka inne där.
Du kan prova att använda olika söksträngar.
Också man-sidor i olika operativsystem kan inte vara samma.
De kan vara separata sidor för csh och tcsh.
De är inte på Mac, men de skulle vara om de är separata kommandon.
Om sh inte riktigt kalla Bash, det skulle förmodligen vara en separat manualsida.
Vissa system har separata manualsidor bara för C-shell inbyggda kommandon.
Ibland om du vill läsa en beskrivning av ett inbyggt kommando
det är också i vägen, som eko, måste du läsa manualsidan för kommandot på eko
att avgöra hur det kommer att fungera som ett inbyggt kommando
även om du inte kallar det inbyggda kommandot.
Det är en nackdel med det operativsystem i allmänhet, inte bara för de skal,
men för skalen särskilt manualsidorna är ganska lång,
dels för att de har lagt till användbara funktioner till dem, vilket kan vara positivt.
Okej. Finns det några frågor? Alla ämnen du vill ta upp?
Allt är relevant här?
Jo, det har varit mycket trevligt att prata med er alla.
Jag hoppas att du fick ut något av detta seminarium
som kommer att vara till nytta för dig i din framtida strävanden.
[CS50.TV]