>> [Seminar - Unix Schelpen, Environments]
[Douglas Kline - Harvard University]
[Dit is CS50. - CS50.TV]
>> Vandaag onderwerp is de Unix shell.
Ik ben Douglas Kline, deskundige, of op zijn minst redelijk bekwaam gebruiker, van de schelp.
Een shell is de interface voor de gebruiker om het besturingssysteem van de computer.
De naam is misleidend, omdat, in tegenstelling tot de schelp van een dier,
die is hard en beschermend, de computer shell zorgt voor de communicatie.
Dus poreus membraan zou waarschijnlijk een betere metafoor.
>> De originele shell voor Unix is ​​de Bourne shell.
Bourne is gespeld B-O-U-R-N-E.
Bourne was een van de oorspronkelijke auteurs van Unix,
en dus de schaal is naar hem vernoemd.
De naam van die shell als een commando is gewoon sh.
Dat is de opdracht die u kunt uitvoeren.
De schaal begint bij het inloggen.
Wanneer u zich aanmeldt bij de computer, de shell begint net lopen voor jou,
en dat is wat neemt uw commando's.
Het kan beginnen op andere momenten ook.
Als je verschijnt een venster met geen andere indicatie, zal het een shell voor je begint.
Dat is hoe het is dat je kunt naar een raam en begint te typen commando's
enzovoort daar ook al heb je niet inloggen op dat venster.
Bovendien, als je een remote login doen,
dan zal het een shell te starten op de externe computer.
En is het mogelijk om opdrachten uit te voeren zonder een interactieve shell.
Dat kan betekenen binnen uw huidige operatie,
en het kan ook betekenen dat een op afstand te bedienen.
Je zou een commando te sturen naar een andere computer,
waaronder het opstarten van een shell daar.
In feite is het opstarten van een shell er zijn
zelfs als dat niet je uiteindelijke doel.
Wanneer iets wordt opgestart als dit, is het niet per se start een nieuwe shell.
Als je verschijnt een nieuw venster, is het mogelijk om het te vertellen om een ​​editor te brengen
of een ander commando.
In dat geval zal de uitgever beginnen vanaf nul.
Wanneer de editor eindigt, het raam eindigt.
Dit is een beetje ongewoon, maar het kan worden gedaan.
In die gevallen zal het niet een schelp.
Dus het is niet noodzakelijk zo dat een raam of een dergelijke toepassing zal een schelp.
>> Shell ontleedt opdrachten.
Parsing betekent het identificeren van de verschillende elementen en hun kwalificatie.
Binnen een opdracht, de complete string die u typt,
zullen er 1 of meer enkele te voeren opdrachten.
Andere elementen kunnen argumenten.
Er kunnen ook speciale tekens die de uitvoering van een opdracht beïnvloeden.
Ze kunnen de uitgang ergens anders dan het scherm te sturen
indien de opdracht normaal zou sturen naar het scherm.
Het kan invoeren redirect, het kan andere dingen ook doen.
Er zijn verschillende andere symbolen, karakters, enzovoort.
Parsing gaat opsporen en interpreteren van die dingen.
>> Nu als er geen vragen meer, dat is nogal onwaarschijnlijk omdat er geen meer mensen,
we zullen hier naar mijn volgende pagina.
>> Ik zei eerder dat de Bourne shell is de eerste shell.
Er zijn anderen.
Een daarvan is de C-shell. Het commando is csh.
De naam C-shell is gewoon een woordspeling.
Deze schaal werd geïntroduceerd met Berkeley Unix in het midden van de jaren 1970.
Berkeley Unix was een baanbrekende gebeurtenis in de ontwikkeling van Unix.
Het was een enorme revolutie en onder meer de introductie van deze schelp.
De reden voor die woordspeling, C-shell,
is dat de C-shell heeft een aantal kenmerken in, die de taal C lijken,
die de Bourne shell niet over -
of zij niet over op dat moment.
Er is ook de TC-shell.
Dit is een superset van de C-schaal.
Het heeft extra functies, waarvan vele zijn nuttig voor interactief gebruik,
zoals herinnerend opdrachten in de geschiedenismechanisme,
die ik iets later zal beschrijven -
op eenvoudige wijze gemodelleerd naar een editor.
Het heeft ook bindingen die u toelaten om een ​​korte sleutel touwtje binden aan een langere opdracht.
We gaan niet te krijgen in dat vandaag.
Het heeft een aantal functies die handig zijn voor het programmeren zijn.
Echter, de C-shell niet vaak gebruikt voor shell programmeren.
Shell-programma's, als je niet al weet,
zijn programma's die bestaan ​​uit shell kenmerken.
Je kan deze draaien als programma's.
Je schrijft een bos van shell commando's in een bestand en het bestand uit te voeren.
U hoeft niet om het te compileren. Dit is een interpretatieve taal.
De zinsnede C-shell is nu dubbelzinnig omdat het alleen kan verwijzen naar de oorspronkelijke C-shell, csh,
of om alle C-schelpen, waaronder tcsh. Het is een beetje dubbelzinnig.
>> Een later shell is de Korn shell, ksh, vernoemd naar de programmeur, Korn.
Deze shell geprobeerd op te nemen in 1 shell
de voordelen van de C-shell voor interactief gebruik
en de Bourne shell voor de programmering.
Het is gebruikt als een interactieve shell door sommige mensen - een minderheid.
Later echter, was er nog een introductie, de Bash shell, BASH,
weer een woordspeling, Bourne-Again Shell.
Het is een uitbreiding van de Bourne shell. Korn shell is ook. Beiden zijn.
Het heeft dezelfde doelstellingen van de Korn-shell van de samenvoeging van de C-shell
en voordelen Bourne shell in 1 schelp.
Veel van de verbeteringen van de Korn shell zijn ook opgenomen in Bash.
Bash heeft echter meer en verdient derhalve de voorkeur.
De Bourne-Again Shell en de Korn shell zijn Bourne-achtige shells genoemd
omdat ze onder de kenmerken van de Bourne shell,
die onverenigbaar zijn in sommige opzichten met C-schelpen.
Er zijn andere schelpen naast die, wat bedoeld voor beperkt gebruik,
misschien beperkt tot een aantal opdrachten, misschien gespecialiseerde doeleinden, niet vaak gebruikt.
>> Oke. Volgend item hier.
De Bash shell is geworden in verband met verscheidene vormen van Linux.
Ik weet niet zeker of dat waar is van iedere vorm.
Er zijn vele vormen die er zijn en ik heb ze niet allemaal gebruikt,
maar in die die ik heb gebruikt het is verbonden met het uitgegroeid.
Voor zover ik weet, is er niets over Bash
die het niet meer compatibel met Linux maakt
dan elke andere combinatie van Shell en het besturingssysteem.
Ik denk dat dit waarschijnlijk gewoon weerspiegelt de neigingen van de programmeurs.
Dat het is uitgegroeid geassocieerd met Linux is een andere reden om Bash liever ksh
omdat dingen zijn waarschijnlijk in te kunnen worden geschreven en het is waarschijnlijk te verspreiden.
Ik zal je andere redenen om die later op te geven.
Bourne shell scripts moeten worden uitgevoerd onder de Korn shell of Bash.
Als je iets voor de Bourne shell schrijven,
kunt u waarschijnlijk voer het onder ksh of bash.
Korn shell scripts zullen waarschijnlijk draaien onder Bash, maar ik kan niet garanderen dat.
Later hier, moet C-shell scripts worden uitgevoerd onder de TC-shell.
De C-shell is eigenlijk nooit veel gebruikt voor scripting
sinds de Bourne shell en later de Bourne-soort schelpen waren de voorkeur voor dat doel.
Dus dat is echt niet zo belangrijk.
Er zijn heel veel van Bourne shell scripts die werden lang geleden geschreven,
voordat de Korn shell of de Bourne-shell opnieuw werden ingevoerd.
Die zijn nog steeds in gebruik, een deel van de besturingssystemen,
en zo zal je ze vinden als je kijkt in het besturingssysteem
of een oude programmering pakketten.
>> Bash is tot op zekere hoogte worden een soort lingua franca voor besturingssystemen.
Het is al uitgebreid naar Windows en VMS.
VMS, voor het geval je niet weet, is een eigen besturingssysteem
van Digital Equipment Corporation, die nog steeds in gebruik, grotendeels achter de schermen.
En als het gaat om te draaien op verschillende besturingssystemen,
waarschijnlijk de mensen de neiging om te verschuiven voor.
Maar deze ontwikkeling is relatief recent.
Het is nog maar net begonnen, dus ik kan niet voorspellen of dit zal blijken te zijn echt dat soort lingua franca zijn.
Ook, omdat bestandspadnamen en bibliotheken verschillen
tussen deze verschillende besturingssystemen,
je zou niet in staat zijn om een ​​Bash-script te schrijven over een besturingssysteem
en voer het vervolgens op een ander.
Je moet in staat zijn om het te verplaatsen tussen verschillende Unix, Linux
Mac OS besturingssystemen, maar niet per se naar Windows of VMS.
Je zou kunnen hebben om een ​​bestand padnaam beschrijvingen te veranderen,
en sommige bibliotheken kan anders zijn,
die de weg dat sommige commando's werken kunnen beïnvloeden
of hoe zij verwerken argumenten en dergelijke.
Trouwens, een waarschuwing is dat er geen garantie
dat alle verschillende schelpen die ik heb genoemd - Bourne shell, C-shell,
TC-shell, Korn shell, Bourne-Again Shell - zal beschikbaar zijn onder een Unix
of Linux of Mac OS-computer.
Ze kunnen er gewoon niet zijn.
Dat is een van de waarschuwingen hier.
Het is een ongelukkige beperking hier omdat je wilt dingen om overal te werken,
maar helaas kun je niet op vertrouwen.
>> Oke. Volgende hier.
Laten we zeggen dat je wilt een shell script te schrijven,
een programma dat bestaat uit shell commando's.
Je schrijft je commando's, zet ze in een bestand, en het bestand uit te voeren.
Wat als je wilt argumenten bevatten?
In het geval van shell operaties, zijn argumenten parameters of positionele parameters, ook wel
en ze zullen worden opgeroepen door een dollarteken en cijfer, $ 1, $ 2.
Dus als het script heeft deze naam, zou mijn eerste argument argument 1 zijn
en mijn tweede misschien argument 2 zijn,
en in mijn script als ik wil verwijzen naar deze dingen -
laten we dit wist want ik ben niet echt van plan om het uit te voeren -
in mijn script dat ik zou $ 1 te verwijzen naar arg1,
$ 2, die uit zal komen op die manier, arg2.
Dus deze symbolen zijn beschikbaar om te verwijzen naar argumenten,
en die gelden voor alle schalen.
Daarnaast zijn er andere karakters.
$ * Verwijst naar de volledige lijst met argumenten, allemaal.
$ # Verwijst naar het aantal argumenten.
Nogmaals, dit geldt voor alle schalen.
Deze symbolen * en # kunnen worden gebruikt met de betekenissen in andere plaatsen ook.
We zullen niet krijgen in dat.
>> Shell specificeerder lijn. Waar is dat voor?
Laten we zeggen dat je hebt geschreven een script en het is voor een bepaalde shell en je wilt het uit te voeren.
Hoe weet je wat shell uw besturingssysteem zal gebruiken om uw script uit te voeren?
Op een gegeven moment kon je ervan uitgaan dat het zou draaien in de Bourne shell
als je niet anders heb gezegd,
maar mensen zijn niet het schrijven van scripts in de Bourne shell die veel meer
en je kan niet eens rekenen op dat niet meer.
Dus hier hebben we een shell specifier lijn hier.
Die aangeeft Bash.
Merk op dat het specificeert het in de padnaam, / bin / bash.
Als een computer de Bash-shell, maar niet in de map bin, / bin, dit zal niet werken.
Dat is een andere qualifier, nog voorzichtigheid hier.
Het hekje is het commentaar teken.
Dat geldt voor alle schelpen.
Het specifieke geval hier, #! aan het begin van een script, een speciaal geval.
Dat bepaalt de schaal waarin het script uit te voeren.
Zoals ik al zei, is het misschien niet op dezelfde plaats / bin zijn.
Daarnaast is er nog een ding hier.
Als u gewoon gebruik maken van het hekje zonder uitroepteken en padnaam,
dat zou een C-shell te geven.
Toch denk ik niet aanraden dat te doen, want ik ben niet in staat om te garanderen
dat deze altijd werkt.
Als je een C-shell, zou het beter zijn om dat te zeggen.
Dan is er nog iets wat nogal verwarrend hier.
Als je een shell specifier lijn gebruiken, zoals / bin / bash
en dat shell is er niet beschikbaar is,
er is niet zoiets als / bin / bash op die specifieke computer,
hetzij omdat het niet Bash hebben of omdat het in een andere locatie,
zult u een foutmelding gekregen dat de script je liep bestaat niet krijgen.
En natuurlijk je script bestaat, zodat foutmelding is verwarrend.
De reden dat het besturingssysteem geeft je die fout
of, beter gezegd, dat je interactieve shell waarin u werkt dit geeft die fout,
is dat het verslag van de opdracht die u gebruikt, dat is de naam van het script.
Dat commando effectief wel de shell door de naam van het script.
Dat is waar je die verwarrende foutmelding.
Een andere manier om shell script te bellen
is door het specificeren van de shell op de opdrachtregel, zoals hier.
Dit is een opdracht. Dit zegt run Bash en voer mijn script in Bash.
Dat zal voorrang hebben op een specifier lijn,
en dit heeft de functie van het toestaan ​​van u om te voorzien in uiteenlopende padnamen.
Als je alleen maar een commando, zal het besturingssysteem op zoek naar die opdracht
op verschillende plaatsen.
Als het beschikbaar is, moet het te vinden.
De computer zal Bash vinden waar het ligt en voer het uit,
zodat u niet nodig hebt dan te maken over wanneer zij constateert het zijn.
Er zijn mogelijk andere problemen hier,
alsof er meer dan 1 versie van Bash, dat is mogelijk, maar onwaarschijnlijk.
Dus dat is een andere manier om te gaan met deze dingen.
Specifier lijnen kan elk shell bellen.
Ze kunnen ook andere dan de schelpen dingen noemen.
Voorbeelden die ik hier heb zijn sed, dat is de stroom editor;
awk, dat is een patroon verwerking taal;
en perl, een zeer hoog ontwikkelde scripttaal.
Als je een specifier lijn die een van deze programma's in het begin,
zal het direct in dat programma in plaats van het starten van een schelp.
Die programma's hebben grenzen aan hun capaciteiten.
Perl is zeer capabel. Sed is een editor. Het kan dingen doen dan alleen te bewerken.
Maar het kan moeilijk te programmeren dat.
Daarnaast passeren argumenten en spullen om script onmogelijk of verwarrend.
Dus in die gevallen met awk of sed, het is, althans in mijn ervaring,
beter om een ​​shell script en oproep awk schrijven of sed uit de shell script
in plaats van te bellen awk of sed als het script specificeerder lijn.
Perl is een zeer divers taal, zoals ik al zei.
Je kunt geen interactieve opdrachten uitvoeren in perl,
wat betekent dat u geen delen van scripts die je aan het ontwikkelen bent kunt testen
door ze interactief.
Echter, het is een zeer capabele taal
en heeft zich ontwikkeld tot een zeer veel gebruikte tool.
Dat is gewoon een beetje een terloopse opmerking over de ontwerper lijnen.
>> In alle of de meeste vormen van Linux - nogmaals, ik kan er niet zeker van dat is alles -
en in Mac OS, als je csh typt krijg je tcsh,
en als je typt je sh bash krijgen.
Ze werden er proberen om u de meer geavanceerde versies van deze schelpen geven,
maar dit kan verwarrend zijn.
Als je een script schrijven met behulp van tcsh of Bash biedt tijdens het bellen csh of sh
en dan proberen om het uit te voeren op een computer die niet tcsh of Bash heeft,
je zou kunnen krijgen een aantal fouten als er commando's daar
die deze schelpen niet herkent.
Bovendien, je kan hebben op uw lokale computer heet uw shell
noemde het als sh of csh en dan krijgt de meer geavanceerde schelpen.
Je mag niet eens denken aan het feit dat je met behulp van de meer geavanceerde shell.
Dus dit is een potentiële valkuil.
Hoe staat vast dat als je typt sh je Bash,
als je csh typt u tsch krijgen?
Er zijn dingen in deze computers wel links
die verbinding kan maken aan bestandsnamen om te verwijzen naar het zelfde ding.
Het kan ofwel 2 namen voor dezelfde of een bestand waarvan het doel is om te verwijzen naar een ander bestand.
Ze heten harde en symbolische links. We zullen niet in te gaan op dat niet meer vandaag.
Er kunnen ook afzonderlijke bestanden - 1 bestand sh, 1 bestand Bash -
maar ze lopen beide Bash.
Dan is er hier nog een qualifier.
Als je belt een van deze schelpen met een naam,
je zou denken dat je zou dezelfde functionaliteit krijgen als het aanroepen van het onder een andere naam.
Nou, dat is eigenlijk niet noodzakelijk waar.
Deze commando's kunnen de naam waarmee ze werden genoemd onderzoeken
en ze kunnen, op basis van die naam, zich anders gedragen.
Er kunnen problemen proberen te voldoen aan een norm.
Sommigen van jullie misschien wel eens gehoord van de POSIX-standaard of een andere,
misschien andere functies.
Dit kan soms worden geselecteerd door command line argumenten
of door shell variabelen.
Noemde het als sh of bash kan zelfs leiden tot een andere uitvoering
zelfs als het hetzelfde bestand dat u uitvoeren.
Een ander ding om te overwegen is dat zelfs als een andere computer heeft tcsh of Bash,
als ze niet verbonden zijn zoals ze op uw lokale computer
als je een Linux of Mac OS lokale computer,
dan weer zul je de shell die je sh of csh noemen, niet degene die je misschien liever te krijgen.
De huidige Bourne shell heeft verbeteringen minder dan die in Bash
maar voorbij die in de originele Bourne shell.
Als gevolg daarvan, zelfs de huidige Bourne shell, sh,
zelfs wanneer het niet Bash, lijkt op de taal C meer dan de C-shell doet.
Dat was niet het geval wanneer de C-shell voor het eerst werd gemaakt, maar het is op die manier ontwikkeld.
Je zou hier opmerken dat al deze shell namen behalve de Bourne shell
iets aan te geven welke shell ze zijn - csh, bash -
maar de Bourne shell is gewoon sh.
Waarom? Dat was de oorspronkelijke shell.
Het was de shell dan, niet een schelp,
en omdat het de shell, was er geen reden om het te onderscheiden van andere shell.
Dus dat is de reden waarom het die naam heeft en nog steeds doet.
>> Deze top is hier een regel uit een wachtwoord database account Ik heb er
op een andere computer.
Ik ga proberen om die naam te krijgen, zodat je dat deel kunt zien op het einde, de schelp.
Het wachtwoord database bevat de login kenmerken voor alle gebruikers.
In het begin is de gebruikersnaam, die u de laatste 2 letters van mij nu zien.
De velden hier worden gescheiden door dubbele punten.
Het laatste veld, zoals je kunt zien, is bin / tcsh, de schelp.
Dat is de shell specifier.
Er is iets interessants hier.
Toen Unix eerst werd ontwikkeld, was er slechts 1 schelp,
dus er was geen keuze daar.
Dus waarom hebben ze laten een veld in het wachtwoord-database naar een shell te geven?
Ik weet het niet, maar het is gelukkig dat ze deden.
Het is nogal moeilijk om veranderingen in de wachtwoord database-indeling maken
omdat veel programma's hebben betrekking op het formaat
en zou moeten worden herschreven.
Het is een gelukkige of toevallige ontwikkeling die zij opgenomen dat veld.
Dat soort van een wachtwoord bestand regel wordt gebruikt op alle Unix-en Linux-computers voor zover ik weet.
De Mac heeft een eigen systeem.
Het heeft eigenlijk een wachtwoord bestand met de lijnen in dat formaat,
maar niet wanneer de gebruiker zijn bepaald.
Een andere terloopse opmerking daar.
>> Als je belt een shell, kan je het noemen als een sub-shell van uw bestaande schelpen.
Dus als ik ga hier, laten we ontdoen van deze dingen.
Hier ben ik in de C-shell.
Die variabele, die nauwkeurig identificeert mijn schelp,
eigenlijk is het niet altijd een betrouwbare manier om te bepalen welke shell je draait,
maar in dit geval is.
Wat als ik typ -
Nu ben ik in Bash.
Sommige dingen zullen hetzelfde zijn. ls vertelt me ​​mijn commando's.
Als ik een schorsing terug naar mijn C-shell, ls, hetzelfde. Rechts?
fg, voorgrond, terug naar mijn Bash shell.
dow, huidige directory, terug naar de C-shell.
dow, andere directory - eigenlijk niet een andere directory in dit geval.
Het is dezelfde directory.
Laten we zeggen dat ik een commando wilt noemen hier: waar ls.
Wat doet dat?
Het vertelt me ​​waar de opdracht ls,
degene die mij een directory listing geeft, ligt in ls.
Laten we teruggaan naar Bash shell gaan. Laten we proberen hetzelfde.
Hmm, interessant daar waar: command not found.
Waarom is dat?
Het waarbij opdracht is ingebouwd in de C-shell.
Dit is niet een opdracht die moet worden gelezen in het geheugen van ergens anders en uitgevoerd.
De C-shell loopt het door de overdracht van de uitvoering om een ​​deel van zijn eigen code
en het is niet in de Bash shell.
Dus Bash, niet met een dergelijke ingebouwde opdracht, zoekt het, vindt het niet,
en we krijgen een foutmelding.
Dus daar hebben we een Bash shell draaien onder een C-shell, en we noemen dat een sub-shell.
En voor het geval je nieuwsgierig bent, Bash shell heeft zijn eigen manier van het vinden van opdrachten.
hash verwijst naar het feit dat het sneller kan worden uitgevoerd,
wordt sneller gevonden.
Dat is een van de verbeteringen ingebouwd in een aantal van deze schelpen.
>> Bourne-achtige schelpen hebben de voorkeur voor de programmering.
Ze hebben controle structuren zoals lussen, conditionele statements,
het soort opdrachten die u kunt gebruiken in programmeertalen zoals C
of welke taal dan ook. Misschien bent u het programmeren in Java of wat dan ook.
Shells hebben die ook.
De Bourne-soort schelpen, vooral Bash, hebben meer
en ze zijn ontworpen met een grotere flexibiliteit.
De Bash shell heeft arrays. De originele Bourne shell niet.
Zodat zijn aanzienlijk voordeel voor het programmeren.
De C-shell eigenlijk wel arrays, maar heeft niet veel van deze andere functies.
De Bourne-achtige shells sneller uitvoeren
als ze niet de kenmerken bestemd voor interactief gebruik.
U laadt dingen naar beneden voor een doel, dit laadt ze naar beneden voor een ander doel.
Daar is die trade-off daar.
Die functies die bestemd zijn voor interactief gebruik
werkelijk zijn van weinig of geen nut voor scripting.
Het is mogelijk om een ​​interactieve sub-shell gebruiken, net zoals degene die ik daar begonnen
aan het testen van commando's die u wilt gebruiken in een script.
Dat is wat je niet kunt doen met perl. U kunt dit doen met de schelpen.
Zelfs de structuren zoals lussen en dergelijke kunnen interactief worden uitgevoerd.
Ze zijn soms nuttig om interactief draaien,
maar meer waarschijnlijk dat je ze met behulp van een script te ontwikkelen.
>> Alias.
Dit gaat worden over de C-shell.
Geschiedenis mechanisme waar u terug naar eerdere opdrachten te krijgen
of delen daarvan die je al hebt draaien.
Nogmaals, over de C-shell, de Bourne shell en de Korn shell hebben deze dingen,
maar ik ben niet van plan om in hen.
Dus hier zijn enkele nuttige aliassen die ik heb.
In plaats van het typen van ls - het is een gemeenschappelijk commando -
typ je gewoon l en bespaar jezelf 1 karakter.
ls met verschillende opties, al die werkzaamheden.
Merk op dat deze definities hebben aanhalingstekens om hen heen.
In deze gevallen de aanhalingstekens zijn niet nodig.
Als je die aliassen kunt definiëren zonder de aanhalingstekens, zou het nog steeds werken.
Ze worden aanbevolen.
Er zijn situaties waarin u de offerte niet kunt gebruiken
omdat je iets te gebeuren waar de offerte zou willen voorkomen.
Soms kun je een deel van de definitie citeren, maar niet alles.
Het is ook in het algemeen aan te raden om enkele aanhalingstekens in plaats van dubbele aanhalingstekens te gebruiken.
Dubbele aanhalingstekens gevolgen hebben voor de variabele definities,
waardoor ze bijzonder te evalueren plaats stoppen.
Waarom zouden we willen de evaluatie stoppen?
En hoe doe citaten die voor ons doen?
>> Hier is een opdracht die je interessant vindt.
'Ls g *'
g *, zoals u waarschijnlijk weet, is een wildcard uitdrukking
voor alle bestandsnamen beginnend met g.
Als ik schrijf gewoon in een commando ls g *, zal ik een lijst van al die namen in mijn huidige directory.
Als ik definiëren dat alias als hier met de aanhalingstekens,
het zal dat commando uitvoert in je huidige directory waar je het draait.
Maar als je de alias definitie draaien zonder de aanhalingstekens,
het zal de wildcard g * evalueren wanneer het loopt dit cruciale opdracht.
Dus de definitie van het alias zal worden ls gevolgd door de lijst met bestanden in de directory
waarin de alias opdracht wordt uitgevoerd,
ongeacht waar je eigenlijk van plan om de opdracht uit te voeren.
Dit is niet veel te gebruiken, en de enkele aanhalingstekens voorkomen dat de evaluatie van het sterretje.
Dus je krijgt gewoon de definitie wezen ls g *.
Dan, lgs, vervolgens zet wanneer u de alias lopen dat uit.
Nu zijn er geen aanhalingstekens, en het zal het sterretje beoordelen als u het alias commando uitvoeren.
Dus dat is een ding.
Dubbele aanhalingstekens zou dat hetzelfde effect hier hebben,
maar er zijn andere gevallen waarin dubbele aanhalingstekens niet zo goed zou werken.
>> Hier is een andere.
Misschien ken je het grep commando.
De grep commando kan worden gebruikt om een ​​bestand voor lijnen die bepaalde snaren scannen.
Dus laten we gaan hier en ik zal verlaten mijn Bourne shell.
Oke. Hier is een bestand.
Laten we zeggen dat het grep abc snaren. Daar is het.
Als ik dat doe grep zddd, krijg ik niets. Oke.
Het vindt zo een string, hij rapporteert het niet vinden, het niet melden.
Het uitgangen elke lijn die die string op het heeft.
Er zijn allerlei opties hier die u kunt vinden in de documentatie.
Hier is een manier om het te doen.
Wat dacht je van deze, alias grabc 'grep abc'?
Dat gaat 1 argument omvatten wanneer de alias wordt gedefinieerd.
Dus als ik dat hier, als ik nu grabc doen,
nu de alias omvat meer dan het simpel commando. Het heeft ook het argument.
Tot dusver dat werkt.
Ik heb een andere opdracht hier, dit een, dus die zijn verschillende strings daar
en laten zien dat dit niet er iets vinden, omdat het niet overeenkomt.
>> Wat als ik wil in de alias definitie op te nemen van het bestand dat ik ga zoeken
en ik wil geven als argument voor de alias van de string die ik zoek?
Ik zou willen zeggen abc als argument naar mijn alias,
maar de alias al het bestand bepaald.
En dat is waar deze uitdrukking komt inch
Let hier hebben we grep net als voorheen.
We hebben het bestand hier, strijkers.
\! ^, Soort van een vreemde uitdrukking, denk ik, als je dit nog niet eerder hebben gezien.
Uitroepteken is onderdeel van de C-shell geschiedenis mechanisme.
Het kan eerder commando oproepen kan argumenten herinneren om die commando enzovoort.
De geschiedenis mechanisme wordt gebruikt als onderdeel van aliasing.
Als je een lijn na het uitroepteken opgeeft, zal het verwijzen naar die lijn in de geschiedenis lijst,
die we niet zullen krijgen in nu want het is een heel ander onderwerp.
Het is mogelijk om een ​​deel van een lijn opgeven.
Dus! 03:02 zou het tweede argument van het commando nummer 3 zijn.
Het dakje hier in deze uitdrukking staat voor het eerste argument.
Als je niet geven een indicatie van welk commando je bedoelt,
het verwijst naar het laatst gebruikte commando,
en het dakje is een symbool voor het eerste argument.
Omdat het de dakje en niet het aantal, hoeft u niet om de dikke darm te gebruiken,
dus! ^ betekent dat het eerste argument om het vorige commando.
Een beetje gemengd hier boven.
In dit geval, wanneer je dit gebruikt als alias definitie
de geschiedenis verwijzing verwijst naar de commando's waarin de alias wordt gebruikt.
Dus dit is terug te gaan 1 commando als een geschiedenis operatie,
maar als een alias operatie het verwijst naar het commando waarin u typt,
zeggen, grstrings_file.
Wij hebben de citaten hier in. Wat is de backslash voor?
In dit geval, net als elders, we willen niet de geschiedenis mechanisme uitvoeren
terwijl het definiëren van de alias.
Als we de backslash daar niet hebben, zou de shell trekken in het eerste argument
van het commando vlak voordat het liep deze alias commando, dat willen we niet.
We willen dat dit wordt ingebouwd in de alias commando om later te bellen in een argument.
Enkele aanhalingstekens ontsnappen niet aan een uitroepteken, de geschiedenis referentie.
Misschien ken je de uitdrukking ontsnapping betekent om de betekenis van iets te veranderen.
In dit geval betekent iets van met een bijzondere betekenis stoppen.
Uitroepteken speciale betekenis is geschiedenis.
Ontsnappen en het niet die betekenis hebben.
Quotes doen dat niet; backslash doet.
Dus we daadwerkelijk gebruik van 2 verdiepingen van hier ontsnappen.
Ik ga deze opdracht verplaatsen naar het andere venster zonder te typen
met behulp van deze bewerkingen, die u misschien nuttig vindt.
Iets anders hier Ik zal je laten zien.
Als je typt gewoon alias zonder argumenten, het vertelt je al je argumenten.
Dit is een bos van aliassen ik had hier al
naast die die ik heb gebruikt hier vandaag.
Maar als ik typ gewoon de naam van een alias, vertelt me ​​wat het betekent.
Merk op dat de citaten zijn verdwenen en de backslash is verdwenen.
Deze tekenreeks hier het resultaat van die alias definitie
en nu is het gewoon! ^ in.
Dit is gaan kijken in het bestand snaren voor alles.
Dus als ik dat doe grstrings_file snaren, heb ik niet geven niets om te zoeken naar daar,
maar het ziet er in strings.
Het zag er niet het woord snaren vinden in het bestand strijkers, maar het doet vinden abc.
En het maakt niet vinden dat.
Dus hier geven we een argument dat raakt in de omschrijving van de alias,
die in het in.
Het is waar deze uitdrukking vandaan komt.
U kunt meer dan 1 te gebruiken.
Het dakje is een symbool voor het eerste argument.
Als je wilde een tweede argument te gebruiken, zou je dan zeggen: 2.
Er is geen speciaal symbool voor het tweede argument.
En omdat je met behulp van een cijfer, zou je de dikke darm te gebruiken.
Er is echter een keuze hier.
Het dollarteken staat voor het laatste argument.
En omdat dit een symbool, kunt u de dikke darm weg te laten.
Dus het zou het laatste argument in de lijst zijn.
En er is ook die ene.
Asterisk betekent alles, dus dit is de complete lijst met argumenten,
en weer, kunt u de dikke darm weg te laten, want het is niet een cijfer.
Ik hoop dat je alles bekijkt deze allemaal.
>> De geschiedenis mechanisme kan terug naar vroegere lijnen gaan in de geschiedenis lijst.
Je kan dit doen in een alias definitie.
Ik heb nog nooit gedaan.
Het zou tot gevolg trekken uit eerdere opdrachten van de geschiedenis lijst
wanneer u de alias, die kunnen verschillende opdrachten uit te voeren
afhankelijk van waar en wanneer u het uit te voeren.
Denkbaar je zou willen trekken uit een dergelijke verwijzing
gewoon weten wat een eerdere opdracht was.
Ik heb nog nooit zien gebeuren.
Ik veronderstel dat iemand zou willen, maar dit is zeer onwaarschijnlijk.
Er is nog een ding hier.
Als je die geschiedenis-type-aanduiding gebruiken,
dan is alleen de argumenten waarop er verwezen worden gebruikt.
Als u een alias definitie, die een geschiedenis-type-aanduiding niet gebruikt,
als het wordt slechts het begin van het commando
en je hebt andere argumenten, dan alles wat je typt na dat
wordt toegevoegd aan het commando.
In dit geval is het voorbeeld dat ik gaf er gewoon, we gebruikten het eerste argument;
we hebben geen anderen gebruiken.
Als andere argumenten had gekregen op de commandoregel, zouden ze niet worden gebruikt.
Dus als je de geschiedenis verwijzing gebruiken helemaal niet, dan moet je het gebruiken om elk argument te krijgen.
>> Er is nog iets hier Ik wil gewoon om op te noemen, mede haakjes,
namelijk dat deze geschiedenis mechanisme met het uitroepteken
gaat terug naar de oorspronkelijke C-shell.
De tcsh introduceerde geschiedenis operaties
waarin de soorten opdrachten en snaren van de editors,
ofwel Emacs of vi.
Mijn persoonlijke mening is Emacs is veel gemakkelijker te gebruiken voor dit doel
zelfs als u vi gebruiken voor uw reguliere bewerken.
Er zijn verschillende Emacs commando's die nu worden aangepast voor de geschiedenis.
Controle P krijgt de vorige regel in de geschiedenis lijst.
Een andere controle P krijgt u de ene daarvoor.
De pijl doet hetzelfde.
Controle N krijgt de volgende opdracht als u al hebt gebladerd terug sommige opzichten.
Pijl naar beneden doet dat ook.
Je kunt verplaatsen van links naar rechts met de pijlen en diverse andere dingen.
Dit kan gebruik maken van de geschiedenis mechanisme
veel gemakkelijker dan het gebruik van het uitroepteken syntax,
maar je zou dat niet gebruiken in een alias definitie.
We zullen gaan over dat een andere keer.
>> Variabelen.
Je weet wat variabelen zijn in programmeertalen.
De schelpen hebben ze ook.
De C-shell gebruikt de commando set om variabelen toe te kennen,
zodat een variabele wordt ingesteld op de waarde van B -
zoals ik al zei, een nutteloze definitie, maar een illustratie van hoe deze wordt gebruikt.
De set commando zal een variabele als deze nog niet bestaat.
De positionele parameters voor shell scripts kunnen worden beschouwd variabelen,
maar het gebruik ervan en de regels voor hen zijn iets anders.
U kunt een waarde toewijzen aan $ 1 in de loop van een script.
U zou hebben om een ​​nieuwe variabele te definiëren voor dat doel als sommige van je wilde.
Typ set zonder argumenten en krijg je een lijst van alle momenteel gedefinieerde variabelen.
En laten we over aan mijn andere shell hier en zien wat we krijgen als we dat doen.
Een behoorlijk lange lijst daar, toch?
Blader omhoog een beetje. Kijk eens naar al die.
Sommige van deze dingen worden automatisch gedefinieerd door de shell.
De schaal creëert de variabele en geeft het een waarde.
Sommigen van hen worden bepaald door de shell, maar dan opnieuw door de gebruiker
volgens zijn voorkeur.
En sommigen van hen zijn gemaakt door de gebruiker, afhankelijk van wat hij doet die dag.
Dat is gewoon ingesteld zonder argumenten.
Er is een vreemde eigenschap hier van dit ding.
Er moet ofwel geen spaties tussen de gelijk-teken en de naam van de variabele te zijn
en de waarde of ruimten aan beide zijden van het gelijkteken,
zoals in deze.
Dit zal niet werken, en dit is eigenlijk een geldige opdracht
maar het zal niet doen wat je van plan bent.
Dat bevel zal werken, want als je net set en een variabele naam
zonder gelijk-teken of stel en een variabele naam met een gelijk-teken en geen waarde,
het zal de variabele ingesteld op een waarde van nul.
Dus stel een = is een geldige opdracht.
De set commando kan meer dan 1 variabele definiëren op dezelfde lijn.
Dus deze opdracht hier heeft het effect van het definiëren van zowel a en b op null.
Waarschijnlijk niet wat je wilt.
Deze hier, eerder vermeld, zal leiden tot een fout
omdat = b niet een geldige expressie.
Een variabele naam mag niet beginnen met het is gelijk teken.
En er zijn deze verdere dingen hier.
De dubbele punten werden gebruikt om argumenten uit de geschiedenis regels te selecteren,
en ze kunnen worden gebruikt - en ik wilde niet in gaan voor - om die dingen aan te passen.
Ze kunnen ook worden gebruikt om shellvariabelen wijzigen.
Deze hier, $ a, heeft een waarde.
: R zal opstijgen een extensie.
Een uitbreiding zal alles na een dot be,
een punt en iets na het einde van een bestand,
pas aan het einde van de lijst na de laatste slash.
Dus ik heb het hier.
een is dat. Het zal laten vallen. O..
Als er geen verlenging, alleen de padnamen na de laatste slash, zal het geen effect hebben.
a: h, dat variabele expressie, zal opstijgen het laatste element van een directory lijst,
nogmaals, pas na de laatste slash.
Dus / a / b / c wordt / a / b,
maar deze is veranderd, omdat het element nadat de lijst is null.
Hier is er iets wat ik ook wil benadrukken.
Deze qualifiers niet zoeken naar het bestaan ​​van deze bestanden.
Ze gewoon op zoek naar strijkers.
Deze zijn bedoeld om bestandsnamen te manipuleren, padnamen,
maar ze kunnen worden gebruikt op elke snaar ook al is het niet een bestandsnaam.
En ze niet op zoek naar het bestaan,
dus als er geen dergelijk bestand, / a / b / c, dit zal nog steeds werken.
Of het nu van enig nut is een andere vraag, maar het werkt nog steeds.
Variabelen zijn verschillend in de Bourne schelpen. We zullen later op terug.
Dollarteken kunnen worden overgeslagen, net als het uitroepteken en het sterretje.
Teken van de dollar kan worden met een backslash of de enkele aanhalingstekens.
Dubbele aanhalingstekens hebben de oneven effect in alle schelpen
dwingen de evaluatie van een dollarteken variabele expressie.
Dus als het wordt ontsnapt op een manier, kan de dubbele aanhalingstekens het effect
van het veroorzaken van het toch te worden geëvalueerd.
Dit is een beetje verwarrend.
Als er meerdere niveaus te ontsnappen, zoals enkele aanhalingstekens binnen dubbele aanhalingstekens
of dubbele aanhalingstekens binnen enkele aanhalingstekens, moet je testen om te zien wat er zal gebeuren
aan een variabele als je gebruik van een.
Die 2 situaties - dubbele binnenkant van single, een binnenzak van dubbele -
niet noodzakelijkerwijs je hetzelfde resultaat.
Omgevingsvariabelen, gebonden C-shell variabelen.
Omgevingsvariabelen zijn ook variabelen in de C-shell,
en ze zijn ook variabelen in andere shells ook.
In de C-schaal, ze onderscheiden typen.
De dingen die ik eerder zeggen zijn over shell variabelen.
Omgevingsvariabelen zijn een afzonderlijke reeks van variabelen
met uitzondering van enkele variabelen die we gebonden variabelen noemen,
die zijn erg belangrijk en we zullen later krijgen in deze.
Omgevingsvariabelen worden automatisch doorgegeven
naar schelpen of opdrachten die worden uitgevoerd vanuit je shell.
De andere dingen niet. De shell-variabelen, de aliassen zijn niet. Omgevingsvariabelen zijn.
Daarom noemen we ze omgevingsvariabelen,
het idee is dat de omgeving zich voorbij gewoon je huidige shell.
Ze kunnen worden gebruikt om dingen op commando definiëren.
Hier is een voorbeeld. PRINTER, LPDEST.
Deze beide variabelen kan een printer die een commando zal gebruiken om dingen te drukken definiëren.
Als u meerdere printers rond, wilt u misschien degene die je wilt zetten.
De reden dat we 2 variabelen is dat verschillende reeksen commando's werden geschreven
vanuit deze verschillende variabelen.
U kunt hen geven verschillende waarden.
De meeste kans dat je ze allebei dezelfde waarde te geven.
Die dingen werken omdat de commando's die afdrukken doen
waren geprogrammeerd om de waarden van deze variabelen te onderzoeken.
Als een programma niet werden geschreven op die manier, als het ware geschreven om iets anders te doen,
variabele zou irrelevant.
Dus het besturingssysteem is niet op zoek naar deze variabelen
elke keer dat u verwijzen naar een printer.
Een opdracht die afdrukken doet is op zoek naar deze variabelen als deze is geprogrammeerd op die manier.
Deze variabelen worden vaak gedefinieerd in uw initialisatie bestanden
maar niet noodzakelijkerwijs.
U kunt ze op de commandoregel te definiëren.
Ze kunnen worden gedefinieerd in een commando.
Een opdracht die iets loopt misschien haar eigen selectie van variabelen -
variabelen die uniek zijn voor een bepaald softwarepakket zijn bijvoorbeeld.
Deze worden nader bepaald wanneer u dat pakket uit te voeren.
Hoe worden deze variabelen doorgegeven aan een sub-shell?
Wanneer een sub-shell is geschreven, is het niet schrijven in dat gebied.
Het gebied van de sub-shell die is gewijd aan omgevingsvariabelen
is niet geschreven door de sub-shell, het is geschreven door het kopiëren.
Wanneer u een gewone opdracht hebt uitgevoerd, zoals deze opdrachten om af te drukken of wat dan ook,
ze beginnen met het creëren van een nieuwe shell.
De shell zorgt voor een shell en dan overschrijft deel ervan
met de opdracht die je draait, dat is een beetje verwarrend,
maar dat is hoe deze commando's krijgen de omgevingsvariabelen
dat ze dan verwijzen naar later.
Het commando hier voor het definiëren van de variabele setenv.
Dat is hoe je het definieert. Het is 3 elementen: setenv, variabele waarde.
Als je gewoon SetEnv zonder argumenten, wat krijg je dan?
Een overzicht van al deze variabelen.
Nogmaals, het is een mooie lange lijst en in dit geval, net als in de andere,
deze variabelen worden grotendeels bepaald door mijn inloggegevens operatie door de shell zelf
eerder dan door alles wat ik deed.
Er is nog een commando hier, printenv.
Dat drukt ook uit het milieu.
Merken dit laatste wat hier, EDITOR = vi.
Dat zegt dat als ik gebruik iets dat een editor noemt
en ik heb niet een editor opgeven en het laat me de keuze, kan het me vi geven.
Wat als ik doe printenv editor? Het vertelt me ​​wat het is.
Vlak voor dat, was er een variabele, MINDER.
Dit zijn uw standaardinstellingen opties wanneer ik de opdracht less,
die worden de bestanden.
Dus als ik dat doe, kan printenv 1 argument of 0 argumenten nemen,
niet meer dan 1.
Er zijn andere commando's ook, maar we zijn niet van plan om in dat alles vandaag.
Vergeet niet er waren de modifiers voor de shell variabelen als: h,
die het laatste element van een padnaam zal dalen,
of: r, die zal een uitbreiding dalen.
Diegenen die nu gelden voor de omgevingsvariabelen ook. Ze hebben niet gewend zijn.
Vroeger was het zo dat ze niet kon worden gewijzigd. Nu kunnen ze zijn.
Het is een van de voorschotten met de ontwikkelingen van de schelpen door de jaren heen.
Ik zei de dop als deel van de omgevingen
en shell variabelen in de C-shell zijn, met enkele uitzonderingen, verschillende sets.
U kunt een omgevingsvariabele en een shell variabele vast te stellen met dezelfde naam.
Zij zullen verschillende variabelen, ze kunnen verschillende waarden hebben.
De waarde van een wijzigt, wordt de waarde van de ander niet veranderen.
Deze variabelen worden al geëvalueerd met het dollar teken - $ a, $ wat dan ook.
Dus wat als je dit hebt? Weet je welke je krijgt?
In mijn tests kreeg ik de shell variabele,
maar dit is niet gedocumenteerd en je kunt niet op vertrouwen.
Dus ik vraag u, is het creëren van shell en omgevingsvariabelen
met dezelfde namen een goed idee? Nee. Oke.
Wat zijn die grote uitzonderingen waarin het milieu en shellvariabelen
zijn met elkaar verbonden?
Er zijn deze 4.
Hoofdletter TERM omgevingsvariabele,
shell variabele term in kleine letters, type terminal emulatie.
Ik ga gewoon hier op te gaan en ik ga echo, een nuttig commando hier doen,
$ TERM $ termijn. En daar.
xterm is een type terminal voor vensters weergegeven in het X Window System.
xterm-kleur is een variant van dat verschillende kleuren mogelijk maakt.
Waarom hebben we deze omschrijven? Wat is dit goed voor?
Opdrachten die het scherm zoals de editor herschikken
stuur bijzonder sequenties, zogenaamde escape sequences,
een terminal of venster te herschikken enzovoort.
Deze sequenties zijn verschillend voor verschillende terminals.
Dit vertelt het welke te gebruiken.
Soms zijn er problemen daar.
Je zou willen dat veranderen.
Als de dingen niet werken, soms het type terminal is verkeerd ingesteld,
kunt u mogelijk op te lossen door het herdefiniëren van de term variabele.
In deze gevallen veranderen van een variabele milieu variabele of shell variabele
moet het andere veranderen.
Ik heb ontdekt door ervaring dat het veranderen van TERM in hoofdletters
niet altijd shell variabele termijn veranderen in kleine letters.
Dit is een bug.
Ik weet niet of dat is altijd waar. De meeste van de tijd is het niet waar is, maar het kan zijn.
Dus als u een verandering te maken, maar eens dat uit.
Het is niet vaak dat je nodig hebt om die waarde te veranderen, maar eens in de zoveel tijd je doet.
Omgevingsvariabele USER.
Nogmaals, omgevingsvariabele in hoofdletters, shell variabele in kleine letters.
Dit is uw gebruikersnaam.
Het is slechts onder zeer uitzonderlijke omstandigheden
dat je zou willen dat veranderen.
Als uw gebruikersnaam is iemand anders, kan het gooien van alles uit.
Home directory, gebruikers home directory.
Nogmaals, zou je niet willen om dat te veranderen.
Het bericht in al deze gevallen en degene die we over te dekken, het pad variabele,
omgevingsvariabele in hoofdletters en de gebonden shell variabele is in kleine letters.
Als je er een wilt wijzigen, moet u de andere veranderen.
Dit soort binding kan niet worden vastgesteld als je 2 variabelen niet kan binden,
andere dan deze 4, en de binding in deze variabelen kan niet ongedaan gemaakt worden,
je kunt ze niet scheiden.
Dus deze 4 paar variabelen zijn gebonden.
Ze altijd zal zijn. Geen anderen zullen.
Bovendien zou het mogelijk zijn variabelen met dezelfde namen creëren
van hun tegengestelde.
Je zou een shell variabele term in kleine letters maken
of een omgevingsvariabele TERM in hoofdletters.
Die variabelen zou onafhankelijk van deze gepaarde variabelen
en zij onafhankelijk van elkaar.
Ik kan me niet voorstellen waarom je dat zou doen, tenzij je wilt om mensen te verwarren.
Deze hier, weg variabele, dit is echt belangrijk.
Een ander ding is dat er kan worden gevallen
variabelen met gelijke gepaarde namen die niet gebonden zijn aan elkaar.
Er kunnen variabelen, SHELL en shell, in hoofdletters en kleine letters.
Op basis van die naam, weet je niet of dat de variabele is een shell variabele
of een omgevingsvariabele, en ze zijn niet gebonden aan elkaar.
Dus dat soort gekoppelde namen impliceert niet gebonden variabelen.
Het pad variabele, die ik al eerder liet zien,
is een lijst van padnamen waarin de shell zoekt naar opdrachten.
Laten we hier naar dit venster en we echo $ PATH, hoofdletters doen -
omgevingsvariabele - echo $ pad, kleine letters - shell variabele.
Merk op dat de lijst van directories is hetzelfde. Deze zijn gebonden.
Verander een, je de ander veranderen.
In de omgeving variabele elementen worden gescheiden door dubbele punten. Merk op dat.
De shell variabelen worden gescheiden door spaties.
Deze omgeving variabele is een string.
De shell variabele is een array.
De Bourne shell niet arrays.
Bash doet, maar dit is al een vast onderdeel van de schelp.
Dit is een snaar en geen array.
De C-shell had altijd arrays.
De arrays zijn veel gemakkelijker om mee te werken.
U kunt verwijzen naar delen ervan.
Dus echo $ pad [1] en ik krijg / usr / bin, het eerste element.
Nogmaals, herinner dollar teken staat voor het laatste element van de geschiedenis lijst.
Wat gebeurt er? Het probeerde dollarteken vinden als variabele symbool.
Ik ontsnappen. Oeps. Het zou niet te nemen dat ofwel.
Sommige van deze dingen niet zo goed werken.
Misschien zullen we gewoon weg dat uit.
Sterretje verwijst naar de hele zaak, maar dat is wat je krijgt als je niet een element opgeeft.
Een andere manier die array variabelen kunnen worden gemanipuleerd,
aantal elementen daar 7 elementen.
Hier hebben we het hekje voor de variabele naam.
Hier nog een. Zet een vraagteken daar.
Dat is een logische waarde. Dat betekent dat de variabele bestaat.
Het is een andere manier van werken met variabelen.
Dat, door de manier, hoeft niet aan een array variabele.
Dat kan een variabele zijn.
En als ik dat doe, is er geen dergelijke variabele en ik krijg een 0.
Een ander klein ding er over variabele evaluaties.
Terug naar deze ene hier, als om wat voor reden je wilde werken met deze
in plaats van het werken met de matrix, de shell variabele,
er opdrachten die deze dingen kunnen scheiden op basis van de dikke darm.
In feite, als je gaat mogelijk om dit te doen in de Bash shell,
een soort van een script, dat zou waarschijnlijk hoe je het zou doen.
Maar in de C-shell is het veel makkelijker om de array te gebruiken.
In de Bourne shell, worden variabelen toegewezen door een enkele uitdrukking als deze,
zoals de manier waarop je zou een variabele toe te wijzen in een programmeertaal,
en hier is er mag geen spatie zijn.
Het is noodzakelijk dat het gewoon 1 string.
In de Bourne-soort schelpen, alle variabelen shellvariabelen.
Omgevingsvariabelen zijn een subset van de shell-variabelen.
Ze worden onderscheiden van de niet-omgevingsvariabelen door te exporteren.
Het commando om dat te doen is de export, zoals export PRINTER.
Als we dergelijke variabele definiëren
als we wilden een drukkerij opdracht om het te vinden, zou het door een variabele te zijn,
en dat is hoe we het een.
Hier is er iets soort verwarrend.
Deze uitdrukking, te exporteren naar het milieu, is afgeleid van deze Bourne shell concept
en toch deze uitdrukking wordt gebruikt in beschrijvingen van de C-schaal,
waar er geen commando als export.
Als je gewoon export zeggen zelf, krijg je een lijst van de uitgevoerde -
Dus als ik gewoon exporteren hier, niet zoiets.
Oke, daar gaan we.
Deze dingen, door de manier, worden ook gedefinieerd door de shell.
Ik heb geen van deze definiëren door mijzelf.
De schelp doet allerlei dingen op zichzelf.
Het moet dingen automatisch doen.
In Bash of Korn shell, kunt u een opdracht uitvoeren als dit,
die beide geven een variabele een waarde en exporteren in 1 commando.
In de Bourne shell moeten ze aparte commando's als uitvoer een zijn.
Hier is een ander aspect dat is verwarrend.
De set commando in de C-shell bepaalt de variabelen
en zonder argumenten vertelt u wat de waarden van de variabelen 'zijn.
In de Bash shell, het set commando zonder argumenten doet hetzelfde,
maar met argumenten die zij doet iets heel anders.
Dus dit zijn de verschillende argumenten hier.
Sommige van deze zijn omgevingsvariabelen, sommigen van hen zijn shellvariabelen.
Ze zijn allemaal shellvariabelen echt. Sommige van deze zijn omgevingsvariabelen.
De set commando met argumenten kunnen worden gebruikt om te werken
de positionele parameters om een ​​script
wat een manier om ze allemaal tegelijk.
We kunnen niet echt ingaan vandaag.
Het kan ook worden gebruikt om shell gedrag.
Vooral in Bash zijn er variabelen die zal bepalen hoe de shell zich gedraagt.
Dan ook slechts deze ene opdracht die je zou kunnen zien, deze opdracht.
Gezet gevolgd door variabelen en variabele types wordt gebruikt in de Korn en Bash schelpen.
Het is niet verplicht, maar het kan worden gebruikt om de waarden van variabelen beperken
die nuttig om fouten te voorkomen kan zijn, en het is vrij gebruikelijk.
Dus ik ben gewoon te vermelden dat in het geval je het ziet ergens.
Het waarbij opdracht.
Herinner ik al eerder zei het waar commando in de C-shell,
die u kunt vertellen de locatie van een commando padnaam.
Hier is opdracht substitutie.
U moet vinden op je toetsenbord ergens een teken dat er zo uitziet.
De locatie op het toetsenbord gaat variëren.
We hebben het genoemd aanhalingsteken. Het is ongeveer de grootte van een offerte.
Het gaat van linksboven naar rechtsonder.
Hier op mijn Mac-toetsenbord is het in de linker bovenhoek.
Dat teken kan worden gebruikt om een ​​opdracht binnen een opdracht uit te voeren.
Als u een expressie binnen aanhalingstekens,
die uitdrukking is een bevel, het wordt gerund.
De uitvoer van deze opdracht
Vervolgens wordt vervangen door de gehele uitdrukking backquote
in een langere opdracht die loopt dan met die uitgang
als onderdeel van de reeks argumenten enzovoort.
Hier is een opdracht waarin dat gebruik maakt.
Laten we tonen hier de operatie.
Laten we hier gaan, neem de aanhalingstekens.
Een controle krijgt me aan het begin van de lijn met de Emacs syntax.
Tot dusver is de padnamen is wat waar doet,
maar als ik het zo doen, vervolgens stekkers in die lijst van padnamen
in plaats van deze hele aanhalingsteken expressie en loopt ls-l op hen.
Soort handig, hè?
Dus dat is een keurige ding. Dat is hoe aanhalingstekens werken.
Nu gaan we nog iets verder omlaag.
Dit zijn aliassen. Ik heb eigenlijk gebruik maken van deze.
Ik zal proberen om dit in te krijgen met 1 bewerking.
Oke.
Laten we nu eens kijken hoe die definities kwam.
alias LBH me te vertellen hoe het is gedefinieerd.
Let op het is alleen dit, maar de buitenste citaten zijn genomen uit
en het uitroepteken wordt gehaald.
*, Compleet overzicht van alle argumenten.
In een alias definitie zal het terug van toepassing op waar ik dit gebruiken.
LWH ksh bash. Oke.
Zie je hoe dat werkt? Het bespaart me wat te typen.
Laten we een beetje gewoon om iets anders te noemen.
Let hier op deze verschillende schelpen. Ik had dit al eerder heb genoemd.
De csh heeft een 2 hier en dat doet / bin / tcsh.
We kunnen vaststellen op een andere manier, dat die eigenlijk hetzelfde bestand.
Vergeet ik al zei als je typt je sh bash krijgen.
Vul dit en je dit hoort.
Maar die zijn niet gekoppeld. Die hebben enkele sprekers er.
En dit is niet het soort bestand dat een ander kan noemen.
Dus dat zijn aparte bestanden, de C-shell daarvan zijn hetzelfde bestand.
Hier terug naar beneden, de andere hier, dit alias,
rekening mee dat draait deze opdracht, bestand.
Dat alias loopt dat. Bestand vertelt u het type van een bestand.
Dus FWH ksh dreun. Oke.
Dat is de output van de bestandsopdracht.
Ik weet niet of je weet wat dit betekent hier,
Mach-O universal binary met 2 architecturen.
Er zijn 2 mogelijke types processor in de Mac,
en sommige programma geschreven om te kunnen draaien met zowel
en het bestand commando kan bepalen dat, dus dat is wat dit betekent.
Beide bestanden zijn geschreven op die manier.
Zo zien we hoe de alias werkt, zien we hoe de aanhalingsteken werkt,
zien we hoe de eigenlijke bestand ls of het bestand werkt.
Dit zou niet werken. Probeer "waar waar" en "LWH waar". Oke, laten we proberen dat.
waar waar.
waar is een shell ingebouwd.
Vergeet niet eerder toonden we aan dat Bash hoefde niet waar.
Als u typt waar in de Bash shell, krijg je een foutmelding.
Het is gewoon een deel van de schelp in plaats van een aparte opdracht.
Wat gebeurt er als ik het type LBH op zoek naar waar? Kijk wat er gebeurt.
Ran waar waar, kreeg deze uitgang, en vervolgens probeerde ls lopen
zoals ik op waar is een shell ingebouwd.
waar is er, maar de anderen niet bestaan.
Geen van deze bestaan, eigenlijk.
Dus dat werkt niet altijd, en het illustreert ook hoe sommige dingen
niet doen helemaal wat je zou hebben gedacht.
Laten we naar beneden gaan een beetje verder hier.
Dit hier is in Bash. Dat is ook opdracht substitutie, zoals het aanhalingsteken.
Maar in tegenstelling aanhalingsteken, gebruikt deze variabele stijl.
Er zijn een aantal uitdrukkingen die beginnen met een dollarteken,
en terwijl deze zijn niet variabelen, zij leenden het gebruik van het dollarteken
om een ​​uitdrukking van een soort aan te geven.
Dat kan worden omgeven door haakjes of haken of dubbele haakjes,
die heeft een ander doel.
Single haakjes zijn hier een opdracht substitutie net als de aanhalingstekens.
Dubbele haakjes is eigenlijk een rekenkundige bewerking.
Er zijn andere syntaxis, andere operaties.
Aanhalingsteken syntax is verkrijgbaar in Bash.
Echter, deze voorkeur. Het is veel gemakkelijker om te lezen en het laat nestelen.
U kunt binnen $ (commando) hebben een andere opdracht,
iets als -
Ik krijg een lijst daar.
Dat zou werken als ik de aanhalingsteken ook.
Wat als ik zoiets willen doen -
Je zou waarschijnlijk niet daadwerkelijk gebruik maken van deze opdracht,
maar deze interne opdracht substitutie echo's de namen van alle bestanden die beginnen met een,
dan is dit een loopt ls-l op die bestanden,
en dan is dit een enkel echo's van de output.
Je zou waarschijnlijk niet dit te doen, je gewoon zou doen de echo of ls,
maar dit illustreert hoe de nesten van commando's werkt.
Dus gewoon een andere functie hier.
Ik noemde dit eerder, dat wanneer je waar in de C-shell,
Typ werken in de Bourne-soort schelpen voor het lokaliseren van commando's.
Ingebouwde commando, net wat ik daar zei.
Commando's maken deel uit van de schaal, zoals waar.
Wanneer de shell voert het commando uit als ls, lokaliseert het door het pad,
vindt het in een directory ergens,
leest dat in het geheugen, maakt een nieuwe shell,
leest het commando ls of wat dan ook in de schelp
waar de omgevingsvariabelen al zijn gevestigd,
en maakt zij uitvoering aan.
Ingebouwde opdracht, de code voor die opdracht is in de schaal,
dus de shell begint net uitvoeren deel van zijn eigen code.
waar is zo'n commando. Het wordt eigenlijk sneller.
Het hoeft niet om iets in het geheugen te lezen, het is al in het geheugen.
Ingebouwde commando's hebben altijd voorrang op commando's met dezelfde naam.
Commando's die in mappen in het pad kunnen dezelfde naam hebben,
commando's in verschillende mappen, bestanden in verschillende mappen.
Degene die eerder in het pad gebeurt is degene die je krijgt.
Als er een ingebouwde opdracht, altijd krijg je het.
Er is geen manier om het een lagere prioriteit dan een commando in het pad.
Als u wilt dat de commando pad te krijgen, kunt u het volledige pad typen.
Als er een commando en het pad ergens
je kon / bin / waar te typen en je zou krijgen.
Als u niet wilt dat de hele padnaam typt, kan u een alias definiëren.
In feite, als je gaf de alias met dezelfde naam als de ingebouwde opdracht, zou het werken
omdat de alias definitie wordt geëvalueerd
voordat het reservoir bepaalt dat het een ingebouwde opdracht die moet worden uitgevoerd.
Dan krijgt dit iets ingewikkelder met enkele commando's hier.
Bij sommige opdrachten zijn eigenlijk ingebouwd commando en in het pad.
Een van hen is echo, de opdracht gebruikte ik gewoon een tijdje geleden in die voorbeelden.
Echo is een opdracht in het pad en het is in elke schelp.
Ze hoeven niet per se allemaal op dezelfde manier gedragen.
Het was oorspronkelijk een opdracht alleen in het pad.
Het werd later ingebouwd in de schelpen.
Omdat er opties die afhankelijk milieu
en de command line opties, de ingebouwde commando's
geschreven hetzelfde als het commando dat de weg was functioneren,
het is onwaarschijnlijk dat ze zouden zijn geschreven op die manier
indien de opdracht nog niet was geschreven voor het pad.
Dus dit heeft bijwerkingen. De geschiedenis heeft effecten hier.
Er zijn opties er zijn.
Er is ook een optie die door een variabele in de tcsh genaamd echo_style.
Dat is een van deze variabelen die de manier die werkt echo kan veranderen.
Er zijn andere gevallen waarin u een variabele kunt toewijzen
dat verandert de manier waarop de shell operatie, met inbegrip van een ingebouwde opdracht, werkt.
Het zou niet van invloed op iets anders
aangezien andere commando's hebben geen toegang tot de shell variabelen,
alleen de omgevingsvariabelen.
Maar shell operaties kunnen de shellvariabelen lezen.
Dat zal niet werken voor csh. Dat is alleen tcsh. Dat is een van de verbeteringen.
Parsing heeft sequenties het oog op evaluatie metacharacters,
het oog op evaluatie variabelen, aliassen, geschiedenis referenties.
Er is een bepaalde volgorde voor deze dingen.
Als dat zo is dingen in een bepaalde volgorde
en krijgt om iets dat is een uitdrukking van een soort
reeds geëvalueerd zal niet opnieuw evalueren.
Als het wordt, dan zal het alleen maar te vellen over de personages.
Dus als de evaluatie van een aantal uitdrukkingen als opdracht substitutie
of variabele of wat leidt tot een expressie
die je zou willen worden geëvalueerd,
dat werkt alleen als die evaluatie later in de reeks plaatsvindt.
Ik hoop dat ik daar te zijn duidelijk.
Dat parsing sequence, een operatie in de C-shell,
is niet voor ingebouwde opdrachten als voor niet-ingebouwde opdrachten.
Ik ben niet zeker over Bash daar.
Als bijvoorbeeld een shell variabele produceerde een geschiedenis referentie,
het zou waarschijnlijk niet terug in de geschiedenis te gaan.
Het zou gewoon het uitroepteken.
In feite kunnen we gewoon proberen dat nu uit.
a = en we moeten dit in daar te zetten.
Oh, wacht. Sorry. Ik deed dit in de Bash. Ik wilde het hier doen.
Zien, zodat het niet dat de geschiedenis verwijzing evalueren
omdat het reeds voorbij het evalueren geschiedenis expressies
wanneer evalueerde de variabele.
Dus dat is 1 effect van parsing.
En nogmaals, ingebouwde commando's worden niet op dezelfde manier gedaan.
Oke. Laten we gaan naar de volgende hier.
Dit is bedoeld om 1 lijn te zijn, maar het maakt het makkelijker om te lezen.
Wat doet dat?
U herinnert zich misschien dat we sterretjes kunnen evalueren als bestandsnaam wildcards,
en er zijn andere bestandsnaam wildcards zoals het vraagteken en beugel uitdrukkingen.
Dat soort evaluatie wordt genoemd globbing.
ingesteld noglob aan het begin van deze opdracht zegt doe dat niet.
unset noglob zegt ga terug naar dat te doen.
Merk op dat set glob zou dat effect hebben.
In gewone taal, zou opzetten glob of uitgeschakeld noglob lijken gelijk te zijn,
maar hier is het niet. Het is uitgeschakeld noglob.
Nu Tset. tset stond voor terminal set.
Het is niet dat nu vaak gebruikt, maar voordat venstersystemen beschikbaar kwam
en je een enkel terminal had, moet u mogelijk het type te bepalen.
En als er iets zou komen over een Ethernet-of uit het netwerk,
je zou willen zeggen dat het een vt100.
VT100 is een soort van een standaard in de terminal business. Het komt uit het december terminal.
Als je gewoon een inbelverbinding te doen - merken dat? Dit gaat terug een manieren, huh?
Dus als we gewoon TSET hier,
als ik gewoon tset doen, is het resetten van mijn terminal, maar je zag niets.
Het heeft niet echt iets te veranderen.
-S
Oke.
setenv TERM xterm-kleur.
We weten al dat de term werd ingesteld op die manier, zodat niet veranderen.
Dat is de manier waarop we zouden willen doen.
Maar merk op dat dit commando, tset-s, net uitgang deze opdrachten. Het maakte hen niet uit te voeren.
Het duurde niet deze opdrachten uitvoeren, maar de uitgang hen.
Dus dit is bedoeld om commando's die dan zal worden uitgevoerd produceren.
Je herinnert je het commando in dat bestand Ik liet je een Q in het had.
Dus laten we dat doen.
De Q onderdrukt enkele output, maar dat maakt hier niet uit, zoals je kunt zien.
Ik ben gewoon om dat te doen om te laten zien dat het niet uitmaakte.
Dit is aanhalingsteken syntax.
Let op de aanhalingsteken hier, aanhalingsteken hier.
Ik ben hier weg te laten die dingen.
Dit zijn gevallen van het vertellen wat te doen
in het geval van bepaalde soorten terminals -
Ethernet, netwerk, inbelverbinding, wat je hebt.
Het maakt niet uit hier omdat we eigenlijk niet een van deze dingen te doen.
Ik ben gewoon ter illustratie van de opdracht.
Als ik dit doe met het aanhalingsteken, wat ga ik krijgen?
Merk ook hier dat dit inbegrepen de set noglob en de uitgeschakelde noglob,
dus die nu overbodig is geworden in de definitie.
Dat was niet altijd het geval, maar nu zijn ze opgenomen in deze opdracht.
Maar laten we eens kijken wat er gebeurt als ik dat doe
en ga naar het begin van de regel met Control A en ik dat doen.
Oke, stel: Opdracht niet gevonden. Dat is een beetje vreemd, is het niet?
set is een bekende commando. Het is een deel van de schelp.
set: Commando niet gevonden? Waarom is dat?
Hmm. Nou, laten we over nadenken.
Het runnen van een aanhalingsteken opdracht substitutie,
en dat optreedt bij een bepaald deel van de sequentie van het ontleden van de opdracht.
set is een ingebouwde opdracht.
Dus tegen de tijd dat het doet dat opdracht substitutie,
het is al voorbij het punt van de identificatie van ingebouwde opdrachten gekregen.
Zo behandelt ingesteld alsof het een opdracht in het pad.
Onnodig te zeggen, is het niet vinden en je een foutmelding krijgt.
Well. Er is een voorbeeld van parsing volgorde.
En wat doen we dat?
Let hier op deze zeer interessante opdracht, eval.
Ik vraag me af wat dat doet.
Als je kijkt naar de handleiding - en laten we dat doen
om te laten zien hoe verwarrend deze handleidingen zijn -
man tcsh, verward handleiding, het vinden van dingen hier is niet gemakkelijk.
Hier gaan we, eval arg, dus kunnen we 1 of meer argumenten
en er is een lijst van dingen daar.
Behandelt de argumenten als input voor de shell
en voert de resulterende opdrachten in het kader van de huidige shell.
Dit wordt meestal gebruikt om commando gegenereerd als gevolg van commando
of variabele substitutie omdat parsing plaatsvindt vóór deze substituties.
Zeer goed.
En hier zijn ze zelfs verwijzen naar de tset opdracht voor een steekproef gebruik
zoals degene die ik net liet zien.
Nu moet ik het venster terug naar een nuttige plaats te krijgen.
Laten we hier en we zullen zien dat eval wordt gebruikt net daarvoor.
Dus laten we eens kijken wat er gebeurt als we - hier zijn we gaan met de pijltjes om die opdracht
and Control A naar het begin, eval.
Oke, dus het werkt.
Wanneer u eval doen, het duurt wat erna komt en maakt het een commando.
Zo kunt u in wezen ontleden het tweemaal.
De sectie loopt hier deze opdracht tussen de aanhalingstekens,
krijgt de uitgang.
Uitgang wordt verondersteld hier worden uitgevoerd als die commando's zoals deze
in deze en deze.
Dus die commando's zijn nu hier in deze volgorde,
maar deze zijn ingebouwd commando's en het kan ze niet meteen.
Dus gaan we naar eval, eval pikt dat op, begint de hele zaak helemaal opnieuw, en het werkt.
Een voorbeeld van beide backquoting, eval, parsing, gevolgen van parsing,
en een opdracht die waarschijnlijk van weinig nut voor jou tegenwoordig.
Oke. Oke, umask.
Laten we eens kijken naar deze opdracht hier, umask 022. Ik vraag me af wat dat doet.
Laten we gewoon typen umask met niets na. 22. Oke.
022 en het opnieuw doen.
Zoals je misschien al geraden, umask zonder argumenten kan u de actuele masker;
umask met argumenten maakt het dat, maar dat was degene die ik al had.
Wat betekent 022 bedoel je?
Dat zijn hier de bescherming voor een bestand.
Zij bepalen wie mag lezen of schrijven of uitvoeren van het bestand.
Beschermingen worden ook wel permissies.
De R staat voor lezen, de w voor schrijven,
en x, die niet aanwezig zijn, betekent voeren.
Er zijn 3 categorieën zijn.
De laatste 3 elementen zijn in de categorie van de gebruiker. Die op mij van toepassing, de gebruiker.
Deze 3 hier van toepassing op de groep.
Het bestand behoort tot 1 groep, kan de gebruiker toebehoren aan meerdere groepen,
maar als de gebruiker in de groep waartoe het bestand behoort,
dan is deze bescherming geldt voor hem als hij niet de gebruiker.
En deze is iedereen anders.
Deze categorieën sluiten elkaar uit.
De gebruiker bescherming op hem van toepassing,
de groep bescherming van toepassing op leden van de groep anderen dan de gebruiker,
en de andere beveiligingen uitsluitend betrekking op andere dan de gebruiker en de leden van de groep mensen.
Als er een r of aw of een x, betekent dat bescherming wordt verleend.
Als er een koppelteken, betekent dit dat het niet is.
Er zijn eigenlijk andere dingen die hier kan worden gebracht naast deze,
die ik nu niet zal krijgen in.
De umask definieert een standaard voor bestanden die u maakt.
En als een masker, in principe het zegt dat de stukjes die je niet instellen.
Hoe is dit uitgegroeid tot stukjes?
Als u denkt dat van elk van deze als een octaal getal,
Dit is de 1s bit, is de 2s, dit is de 4s.
Dus 0 tot 7
zal beschrijven welke combinatie van r's, w's, en x's die je hebt voor deze 3
en evenveel voor deze en vervolgens deze.
Dus 022 betekent 0 voor andere, 2 voor de groep, 2 voor de gebruiker.
Maar dit is een masker. Het masker is wat je niet hebt.
Het spijt me. Ik gaf je dingen in de verkeerde volgorde.
Het is de eerste 3. Deze 3 zijn de gebruiker, deze 3 zijn de groep, deze 3 zijn de andere.
Sorry dat ik je deze gaf in de verkeerde volgorde.
De 0, die de eerste van deze, niet de waarde weer,
maar als een nummer is er niet, het is een 0.
Dat betekent dat alle 3 van deze zouden worden toegestaan.
Merk op dat dit een van de x is niet toegestaan.
De reden is dat de schil kan vaststellen
of een bestand mag niet worden uitgevoerd of.
Aangezien dit niet een uitvoerbaar bestand, heeft zij niet de x set.
De 2 betekent dat de toestemming, de tweede categorie te schrijven hier,
de een in het midden, wordt ontkend.
Dus nogmaals, dit zijn de dingen die hij ontkende.
Nou, is x toegestaan, maar het is niet hier, want het is niet uitvoerbaar
en zo vervolgens de anderen.
Dus dat is een veel voorkomende umask.
Een andere voorkomende is 700 - geef jezelf alles en niemand anders iets.
En er zijn andere mogelijkheden.
Ik kom terug om dat te gaan. Met behulp van de geschiedenis kan ik terug zoeken naar dat, LWH naar daar.
Oke. Dus hier, dit zijn de schelpen.
Bash, de eigenaar die het systeem rekening, kan alles doen.
Groep en iedereen kan doen lezen of uit te voeren, maar niet schrijven.
Deze heeft niet eens toestaan ​​dat de eigenaar te schrijven.
Indien de eigenaar wilde schrijven aan het, het systeem rekening,
hij zou de bescherming eerste veranderen.
Maar nogmaals, de umask stelt de standaard door te maskeren,
aangegeven door de bits die niet wordt ingesteld.
Dit is typisch een van de initialisatie bestanden die de. Cshrc voor de C-shell
of het profiel. voor de Bourne-soort schelpen.
Het kan ook elders zijn als er andere initialisatie bestanden op het systeem.
Maar goed, dat is umask.
Er is iets wat een beetje vreemd hier,
en dat is, waarom is er een enkel commando voor?
Als ik dit zou schrijven, zou ik het een variabele, umask = enige waarde te maken.
Waarom is er een hele opdracht alleen voor dit doel?
De reden is dit gaat gewoon terug naar de oorsprong van Unix.
Unix was slechts enkele programmering project bij Bell Labs in de vroege jaren 1970.
Mensen kregen gewoon bij elkaar te programmeren.
Ze waren van plan nooit aan een wereldwijd opererend systeem.
Verschillende mensen schreven verschillende delen zonder na te denken veel
van hoe ze zouden worden gebruikt - nogal vaag.
En het kwam samen als dat, en het is nog steeds zo in sommige opzichten.
Zodat weerspiegelt de geschiedenis, en er zijn nog deze inconsistenties en oneven elementen ervan.
Oke. Volgende hier.
Zoals ik al eerder schreef, is de C-shell niet echt gewend heel veel voor de programmering,
maar het kan zijn.
Het voert langzamer, weer de trade-off tussen interactief gebruik,
die meer verwerking betrokken dan snelheid heeft,
die kan zonder verwerking.
De extra functies om de Bourne shell toegevoegd door Korn en Bourne-weer schelpen
niet lijken te vertragen, en ik weet niet waarom dat is.
Het zou zomaar kunnen betere programmering, maar ik ben niet in een positie om te weten.
Snelheid hier eigenlijk niet zo'n big deal, maar het wordt genoemd.
De reden is dat shell scripts eigenlijk vrij snel.
Als er veel commando's als in een calculationele programma,
je zou het waarschijnlijk niet doen in een shell script.
De operaties zijn er vrij eenvoudig en ongecompliceerd.
Degenen die ik heb meegemaakt die te langzaam
betrekken herhaalde aanvragen van langzame opdrachten.
Eerder noemde ik al de stream editor sed. Dat bevel is traag.
Als je sed vele malen uit te voeren, zul je een langzame script te krijgen, maar het is niet de shell dat is traag.
Draait het in de Bourne shell zal niet veel sneller dan het runnen van het in de C-shell is,
hoewel er misschien wat voordelen er zijn.
De aanvullende programmeermogelijkheden, anderzijds,
zijn belangrijke redenen waarom u de Bourne-soort schelpen zou gebruiken.
C-shell heeft oneven functies om het -
het feit dat je niet weet of een variabele is een shell variabele of een omgevingsvariabele.
Het kan heel verwarrend zijn.
Het is niet zo gemakkelijk om te schrijven
alleen gebaseerd op uw ervaring van programmeren in andere talen.
Ik denk dat je de Bourne-soort schelpen meer in overeenstemming met uw ervaring te vinden.
Sommige scripts, hoewel, kunnen duizenden regels lang.
Degenen die ik heb gezien zijn gebruikt voor het patchen van besturingssystemen.
Die kunnen heel langzaam uit te voeren, maar je hoeft niet lopen die heel vaak.
Het is pas wanneer je patchen doet,
en het is alleen de systeembeheerder die deze dingen doet,
dus het is niet echt veel van een probleem.
Degenen die honderden lijnen zijn lang daadwerkelijk uit te voeren vrij snel.
Waarin dit hier, wat zijn die verbeteringen?
Ik heb reeds een paar van hen - arrays, berekeningen,
de $ () uitdrukking voor berekeningen in de Bash shell,
de andere soort van opdracht substitutie.
Er zijn verschillende soorten testen opdrachten
waarmee je kunt conditionele tests op het bestaan ​​van een bestand of andere dingen.
Duren hier, deze opdracht hier.
Wat betekent dit doen, en waarom zou iemand gebruiken?
printenv variabelenaam.
We weten wat printenv doet. Het vertelt ons de waarde van een variabele.
En printenv variabelenaam zal ons niet veel vertellen, want er is geen dergelijke variabele.
Blank.
Maar laten we het eens iets zinvols.
Dat is er niet. Oke. Ik denk dat ik nooit gedefinieerd dat.
Laten we eens kijken gewoon mijn omgeving.
Dit is een ander commando waarmee je kunt je omgeving te inspecteren.
Er is goede oude EDITOR, degene die we eerder zagen.
Wat doet dat?
Hier hebben we een aanhalingsteken expressie.
Vergeet niet dat dit de C-shell.
Dus printenv EDITOR zal ons een waarde van REDACTEUR geven. Het is vi.
En dan zal het die waarde ingesteld op variabele een, het set commando.
Dus nu als ik echo $ a, krijg ik vi.
Dat lijkt niet erg zinvol.
Echter, het eigenlijk wel een doel.
Aangezien we niet weten of een variabele is een shell variabele of een omgevingsvariabele
door gebruik te maken van de evaluatie syntaxis dollarteken, kunnen we printenv gebruiken
om ervoor te zorgen dat het een omgevingsvariabele.
Dus als er een shell variabele editor, zou dit niet hebben gekregen het.
Dit werkt alleen met de omgevingsvariabele.
Als er een shell variabele en ik wilde haar waarde,
Dan moet ik een andere manier om het te doen.
Een manier om dat te doen zou zijn door te doen set en leidingen.
Dit is een van de metacharacters speciale karakters.
Het stuurt de uitgang van de set naar iets anders.
Laten we eens kijken wat we daar zouden kunnen vinden.
Niets. Oke. Laten we gewoon kijken wat er in zit allemaal samen.
Het was echo_style, degene die ik eerder genoemd. Oke, laten we dat doen.
Herinner me dat ik eerder al noemde, echo_style
bepaalt de manier waarop de echo commando wordt uitgevoerd.
BSD staat voor Berkeley Standard Distribution.
Dit is de Berkeley Unix uit de jaren 1970.
Dat is een van de manieren die echo kan draaien.
Instellen echo_style die waarde in de TC-shell zal veroorzaken echo om op die manier gedragen.
Dus stel dat doet, maar alleen ingesteld krijgt shellvariabelen.
Het zou EDITOR, die niet een shell variabele niet vinden.
Niets.
Dus dat is een manier om te onderscheiden hen.
Maar het feit dat je moet gaan door een aantal vreemde commando als dat
onderscheid te maken tussen shell variabelen of omgevingsvariabelen
toont het soort onpraktisch aard van de C-shell voor sommige doeleinden.
En nu, de laatste en misschien minst, dit is de man pagina's.
Degenen van wie u wellicht weet, is de man de opdracht kort voor de handleiding.
De man pagina's voor de schelpen zijn moeilijk te lezen. Ze zijn erg lang.
Ze zijn georganiseerd op een manier die het moeilijk maken om te vinden wat u zoekt.
Dus als u op zoek bent naar iets met een doel,
mag u niet weten of dat doel is een shell variabele of iets anders,
dus je kan niet weten waar te zoeken.
U kunt zoeken naar verschillende strings, maar de snaren worden vaak herhaald.
Dus het is over het algemeen moeilijk te lezen.
We keken naar de TC-shell man pagina een beetje voor de eval-commando te vinden.
Sommige dingen gaan sneller.
Een benadering is om te zoeken naar een string.
U kunt de pager gebruiken.
Pager heeft de schuine streep op zoek naar een commando of een string in een pager operatie.
Man standaard zullen gebruiken pagers, ofwel meer of minder.
Ik weet niet of je bekend bent met die bent, maar die kunnen bestanden beetje bij beetje laten zien.
Ik gebruik MINDER deze specifieke bestanden die we hier hebben laten zien.
U kunt binnen zoeken daar.
U kunt proberen met behulp van verschillende zoekstrings.
Ook man pagina's in verschillende besturingssystemen kan niet hetzelfde zijn.
Ze kunnen aparte pagina's voor csh en tcsh.
Ze zijn niet op de Mac, maar ze zouden kunnen worden als die twee aparte commando.
Als sh niet echt Bash doet oproep, is er waarschijnlijk een aparte man-pagina zijn.
Sommige systemen hebben een aparte man pagina's alleen voor de ingebouwde C-shell commando's.
Soms als u wilt lezen een beschrijving van een ingebouwde opdracht
dat is ook in het pad, zoals echo, moet u de man pagina lezen op dat commando op echo
om te bepalen hoe het zal werken als een ingebouwde opdracht
zelfs als je niet belt de ingebouwde opdracht.
Dat is een nadeel van het besturingssysteem in het algemeen, niet alleen voor de schelpen,
hoewel voor de schelpen in het bijzonder de man-pagina's zijn vrij lang,
deels omdat ze nuttige functies heeft toegevoegd aan hen, die een positief kan zijn.
Oke. Zijn er nog vragen? Elke onderwerpen die u wilt brengen?
Iets relevant hier?
Nou, het is al heel leuk gesprek met u allen.
Ik hoop dat je iets uit dit seminar
dat zal nuttig zijn voor u in uw toekomstige inspanningen.
[CS50.TV]