[Seminari - closques d'Unix, Entorns]
 [Douglas Kline - Harvard University]
 [Aquest és CS50. - CS50.TV]
 

El tema d'avui és la shell d'Unix.
 Estic Douglas Kline, expert, o almenys raonablement usuari competent, de la closca.
 Un shell és la interfície per a l'usuari per al sistema operatiu de l'ordinador.
 El nom és enganyós ja que, a diferència de la petxina d'un animal,
 que és dur i de protecció, la closca ordinador permet la comunicació.
 Així membrana porosa, probablement seria una millor metàfora.
 

La closca original per a Unix és el shell Bourne.
 Bourne s'escriu B-O-O-R-N-E.
 Bourne va ser un dels autors originals d'Unix,
 de manera que la closca es nomena després d'ell.
 El nom d'aquesta petxina com una ordre és simplement sh.
 Aquest és el comandament que es pot executar.
 La closca s'inicia en iniciar la sessió.
 En iniciar sessió en l'ordinador, el shell només comença a funcionar per a vostè,
 i això és el que porta a les seves ordres.
 Es pot començar en altres ocasions també.
 Si obre una finestra sense cap altra indicació, s'iniciarà una petxina per a vostè.
 Això és com és que vostè pot anar a una finestra i començar a escriure les ordres
 i així successivament allà tot i que no es va registrar a aquesta finestra.
 A més, si vostè fa un inici de sessió remot,
 a continuació, s'iniciarà un shell en l'equip remot.
 I és possible executar ordres sense un shell interactiu.
 Això pot significar dins de la seva operació actual,
 i també pot significar una operació remota.
 Vostè pot enviar una comanda a un altre equip,
 que inclou la posada en marxa d'una petxina d'allà.
 De fet, ha d'incloure la posada en marxa una closca hi
 encara que aquest no és el seu objectiu final.
 Quan alguna cosa es posa en marxa com aquesta, no s'inicia necessàriament un nou shell.
 Si obre una nova finestra, és possible dir que perquè aparegui un editor
 o algun altre comandament.
 En aquest cas, l'editor s'iniciarà a partir de zero.
 Quan acaba l'editor, la finestra acaba.
 Això és una mica inusual, però es pot fer.
 En aquests casos, no serà una closca.
 Així que no és necessàriament el cas que una finestra o alguna aplicació s'obrirà un shell.
 

Shell analitza els comandaments.
 Parsing significa identificar els diferents elements i la seva classificació.
 Dins d'un comandament, la cadena completa que escriu,
 haurà 1 o més ordres individuals per a ser executats.
 Altres elements poden ser arguments.
 També pot haver caràcters especials que afecten l'execució d'un comandament.
 Podeu enviar la sortida en algun lloc que no sigui la pantalla
 si la comanda ordinàriament enviar-lo a la pantalla.
 Pot redirigir l'entrada, sinó que pot fer altres coses també.
 Hi ha diversos altres símbols, caràcters, etc.
 Parsing implica detectar i interpretar les coses.
 

Ara bé, si no hi ha més preguntes, la qual cosa és bastant probable, ja que no hi ha més gent,
 anem a passar a la meva propera pàgina aquí.
 

Vaig dir abans que el shell Bourne és l'intèrpret d'ordres inicial.
 Hi ha altres.
 Un és el C-shell. La comanda és csh.
 El nom de C-shell és només un joc de paraules.
 Aquesta closca es va introduir amb Berkeley Unix a mitjans de la dècada de 1970.
 Berkeley Unix era un esdeveniment fonamental en el desenvolupament d'Unix.
 Va ser una gran revolució i va incloure la introducció d'aquesta petxina.
 La raó que el joc de paraules, C-shell,
 és que el C-intèrpret té algunes característiques en el que s'assemblen el llenguatge C,
 que el shell Bourne no té -
 o no tenia en aquest moment.
 També hi ha el TC-shell.
 Aquest és un superconjunt de la C-shell.
 Té característiques addicionals, molts dels quals són útils per a l'ús interactiu,
 com recordant les ordres en el mecanisme de la història,
 que vaig a descriure una mica més tard -
 d'una manera senzilla, el model d'un editor.
 També té enllaços que li permeten enllaçar una cadena de clau de curt a una ordre més.
 No entrarem en això avui.
 Té algunes característiques que són útils per a la programació.
 No obstant això, el C-shell no s'usa sovint per a la programació del shell.
 Programes de Shell, si vostè no sabés ja,
 són programes que consisteixen en les característiques de shell.
 Podeu executar aquests programes.
 Vostè escriu un munt de comandaments de la shell en un arxiu i executar l'arxiu.
 No és necessari per compilar. Aquest és un llenguatge interpretat.
 La frase C-shell esdevé ambigu ja que pot referir-se només a l'original C-shell, csh,
 o tots els C-petxines, incloent tcsh. És una mica ambigu.
 

Una petxina més tard és el shell Korn, ksh, anomenat així pel programador, Korn.
 Aquesta closca intentar incorporar en 1 pela
 els avantatges de la C-shell per a ús interactiu
 i el shell Bourne per a la programació.
 S'ha utilitzat com un shell interactiu per algunes persones - una minoria.
 Més tard, però, hi va haver una altra presentació, el shell Bash, BASH,
 de nou un joc de paraules, Bourne-again shell.
 És una extensió del shell Bourne. Korn també. Tots dos són.
 Té els mateixos objectius del shell Korn de la fusió de la C-shell
 i avantatges de Bourne shell en shell 1.
 Moltes de les millores del shell Korn també s'inclouen en Bash. Bash, però, té més i per tant és preferible.
 The Bourne-again shell i el shell Korn es diuen petxines de tipus Bourne
 ja que inclouen les característiques del shell Bourne,
 que són incompatibles en alguns aspectes amb els C-petxines.
 Hi ha altres petxines, a més d'ells, uns destinats a l'ús restringit,
 potser limitat a alguns comandaments, potser amb fins especialitzats, no s'utilitzen sovint.
 

Okay. Següent article aquí.
 L'intèrpret d'ordres s'ha associat amb diverses formes de Linux.
 No estic segur de si això és cert de totes les formes.
 Hi ha moltes formes per aquí i no tots ells han utilitzat,
 però en els que he fet servir s'ha convertit en associats.
 Fins on jo sé, no hi ha res sobre Bash
 que fa que sigui més compatible amb Linux
 que qualsevol altra combinació de closca i el sistema operatiu.
 Crec que això probablement només reflecteix les inclinacions dels programadors.
 Que ha arribat a ser associat amb Linux és una altra raó per preferir Bash per ksh
 ja que les coses són susceptibles de ser escrit en ell i és probable que es propagui.
 Et vaig a donar altres raons d'això més endavant.
 Scripts de shell Bourne s'han d'executar sota la shell Korn o bash.
 Si escriviu alguna cosa per al shell Bourne,
 Probablement es pot executar sota ksh o bash.
 Scripts de shell Korn probablement s'executaran sota Bash, però no puc garantir-ho.
 Més tard aquí, els scripts de C-shell s'han d'executar en el marc del TC-shell.
 El C-shell va ser en realitat mai s'utilitza àmpliament per al scripting
 des del shell Bourne i més tard les petxines de tipus Bourne eren preferibles per a aquest propòsit.
 Així que realment no és tan important.
 Hi ha un bon munt de Bourne shell scripts que van ser escrits fa molt de temps,
 abans que el shell Korn o el Bourne-Again Shell van ser introduïdes.
 Els que encara estan en ús, que forma part dels sistemes operatius,
 i així que vostè els trobarà si ens fixem en el sistema operatiu
 o alguns paquets de programació d'edat.
 

Bash és fins a cert punt convertint-se en una mena de llengua franca per als sistemes operatius.
 Ja s'ha estès a Windows i VMS.
 VMS, per si no ho sap, és un sistema operatiu propietari
 de Digital Equipment Corporation, que encara està en ús, en gran part darrere de les escenes.
 I si estarà en execució en diversos sistemes operatius diferents,
 probablement les persones tendeixen a passar per això.
 Però aquest desenvolupament és relativament recent.
 Això és només el començament, així que no puc predir si això arribarà a ser realment aquest tipus de lingua franca.
 Així mateix, atès que les rutes d'accés d'arxius i biblioteques difereixen
 entre aquests diferents sistemes operatius,
 vostè probablement no sigui capaç d'escriure un script bash en un sistema operatiu
 i després executar-lo en un altre.
 Vostè ha de ser capaç de moure entre diferents Unix, Linux
 Sistemes operatius Mac OS, però no necessàriament per a Windows o VMS.
 Podria ser necessari canviar les descripcions d'arxius nom de ruta,
 i algunes biblioteques poden ser diferents,
 el que pot afectar la manera en què alguns comandaments funcionen
 o com es processen els arguments i similars.
 A més d'això, una altra precaució aquí és que no hi ha cap garantia
 que totes les diferents petxines que he esmentat - Bourne shell, C-shell,
 TC-shell, Korn, Bourne-Again Shell - estarà disponible en virtut de qualsevol Unix
 o Linux o Mac OS.
 Ells simplement no poden ser-hi.
 Aquesta és una de les precaucions aquí.
 És una trista limitació en aquest cas ja que desitja que les coses funcionin a tot arreu,
 però, per desgràcia, no es pot confiar en això.
 

Okay. Següent 1 aquí.
 Diguem que vostè vol escriure un script de shell,
 un programa que consta d'ordres de shell.
 Vostè escriu les seves ordres, posar-los en un arxiu i executar l'arxiu.
 Què passa si vostè vol incloure arguments?
 En el cas d'operacions de shell, els arguments s'anomenen paràmetres o paràmetres posicionals
 i que seran convocades per un signe de dòlar i el nombre, $ 1, $ 2.
 Així que si el guió té aquest nom, el meu primer argument podria ser l'argument 1
 i el meu segon podria ser l'argument 2,
 i dins del meu script si vull referir-me a aquestes coses -
 Anem a esborrar aquesta ja que no estic realment va a executar -
 dins del meu guió que podria tenir $ 1 per a referir-se a arg1,
 $ 2, que sortirà d'aquesta manera, arg2.
 Així que aquests símbols estan disponibles per fer referència als arguments,
 i els que s'apliquen a totes les petxines.
 A més, hi ha altres caràcters.
 $ * Es refereix a tota la llista d'arguments, tots ells.
 $ # Es refereix al nombre d'arguments.
 Un cop més, això s'aplica a totes les petxines.
 Aquests símbols, * i #, es poden utilitzar amb els significats en altres llocs també.
 No entrarem en aquesta.
 

Línia especificador Shell. Què és això?
 Diguem que vostè ha escrit un guió i és un shell determinat i desitja executar.
 Com saps quin shell del sistema operatiu utilitzarà per executar la seqüència de comandaments?
 En un moment es podia suposar que anava a executar en el shell Bourne
 si vostè no va dir una altra cosa,
 però les persones no estan escrivint scripts en el shell Bourne que molt més
 i ni tan sols es pot confiar en això.
 Així que aquí tenim una línia especificador shell aquí. Que especifica Bash.
 Tingueu en compte que s'especifiquen en el nom de ruta, / bin / bash.
 Si un equip té l'intèrpret d'ordres, però no en el directori bin, / bin, això no funcionarà.
 Aquest és un altre qualificador, una altra precaució aquí.
 El signe és el signe de comentari de línia.
 Això s'aplica a totes les petxines.
 El cas particular aquí, #! al principi d'una seqüència d'ordres, és un cas especial.
 Que especifica el shell en què s'executi l'script.
 Al que anava, que podria no ser el mateix lloc / bin.
 A més, hi ha una altra cosa aquí.
 Si vostè només ha d'utilitzar el signe de nombre sense signe d'exclamació i el nom de ruta,
 que ha d'indicar un C-shell.
 No obstant això, no recomano fer això perquè no sóc capaç de garantir
 que sempre que funcionarà.
 Si vols un C-shell, seria millor dir que sí.
 Llavors hi ha alguna cosa bastant confús aquí.
 Si utilitzeu una línia especificador shell com / bin / bash
 i que la closca no està disponible allà,
 no hi ha tal cosa com / bin / bash en aquest equip en particular,
 ja sigui perquè no té Bash o perquè està en una ubicació diferent,
 obtindrà un error que indica que la seqüència de comandaments es va executar no existeix.
 I, per descomptat, hi ha la seqüència de comandaments, de manera que el missatge d'error és confús.
 La raó que el sistema operatiu li dóna aquest error
 o, més exactament, que el shell interactiu en el que s'està executant aquesta dóna aquest error,
 és que mostra la comanda que va utilitzar, que és el nom de l'script.
 Aquest comandament diu efectivament la closca amb el nom de la seqüència de comandaments.
 Aquí és on vostè aconsegueix aquest missatge d'error confús.
 Una altra forma de cridar l'script de shell
 és mitjançant l'especificació de la petxina en la línia d'ordres, com en aquest cas.
 Aquest és un manament. Això diu executar Bash i després executar el meu script en Bash.
 Això prendrà precedència sobre una línia especificador,
 i això té la característica que li permet oferir als diferents rutes d'accés.
 Si vostè acaba de donar una ordre, el sistema operatiu buscarà aquest comando
 en diversos llocs.
 Si està disponible, ha trobar-lo.
 L'equip es troba Bash allà on es troba i executar-lo,
 pel que no cal llavors que preocupar-se per on el troba.
 Hi potencialment altres preocupacions aquí,
 com si hi ha més d'1 versió de Bash, que és possible, encara que poc probable.
 Aquesta és una altra manera de tractar aquestes coses.
 Línies Prescripció poden trucar a qualsevol shell.
 També poden dir les coses diferents de petxines.
 Exemples que tinc aquí són set, que és l'editor de flux;
 awk, que és un llenguatge de processament de patrons;
 i Perl, un llenguatge de script molt desenvolupat.
 Si vostè posa una línia especificador indica un d'aquests programes, al principi,
 anirà directament a aquest programa en lloc d'iniciar un intèrpret d'ordres.
 Aquests programes tenen límits de les seves capacitats.
 Perl és molt capaç. Sigueu és un editor. Es poden fer coses més enllà de la simple edició.
 Però pot ser difícil de programar que.
 A més, el pas d'arguments i aquestes coses a l'escriptura és impossible o confús.
 Així que en aquests casos, amb awk o set, que és, almenys en la meva experiència,
 preferible escriure un guió i l'anomenat awk o set shell des del script de shell
 en lloc de cridar awk o set com la línia especificador guió.
 Perl és un llenguatge molt diversificada, com ja he dit.
 No es pot executar comandaments interactius en perl,
 el que significa que no es pot provar parts de seqüència que vostè està en desenvolupament
 executant de forma interactiva.
 No obstant això, és un llenguatge molt capaç
 i s'ha convertit en una eina molt àmpliament utilitzat.
 Això és només una mica més d'un comentari entre parèntesi al voltant de les línies de especificador.
 

En la totalitat o la majoria de les formes de Linux - de nou, no puc estar segur que és tot -
 i en Mac OS, si escriu csh vostè aconsegueix tcsh,
 i si escriu SH s'obté bash.
 Ells estaven tractant de no donar-li les versions més avançades d'aquestes petxines,
 però això pot ser confús.
 Si s'escriu un guió utilitzant tcsh o Bash característiques, mentre que trucar a csh o sh
 i després tractar d'executar en un ordinador que no té tcsh o Bash,
 el que podria tenir alguns errors si hi ha ordres allà
 que aquests projectils no reconeixen.
 A més, és possible que hi hagi anomenat el seu shell en l'equip local
 qualificant-la com sh o csh i després aconseguir les petxines més avançats.
 O potser no pensar en el fet que vostè està utilitzant el shell més avançada.
 Així que aquest és un problema potencial.
 Com es determina que si escriu sh vostè aconsegueix Bash,
 si escriu csh vostè aconsegueix TSCH?
 Hi ha coses en aquests ordinadors anomenats enllaços
 que poden connectar-se als noms de fitxer per referir-se a la mateixa cosa.
 O bé pot ser de 2 noms per al mateix arxiu o un arxiu que té per objecte fer referència a un altre arxiu.
 Se'ls coneix com enllaços durs i simbòlics. Nosaltres no anem a això més avui.
 També pot haver arxius separats - 1 arxiu sh, 1 arxiu Bash -
 però tots dos funcionen Bash.
 Després hi ha un altre qualificatiu aquí.
 Si vostè està trucant a un d'aquests dipòsits per un nom,
 es podria pensar que tindries la mateixa funcionalitat que dir-per un altre nom. Bé, això en realitat no és necessàriament cert.
 Aquestes ordres poden examinar el nom pel qual van ser anomenats
 i poden, sobre la base d'aquest nom, es comporten de manera diferent.
 Pot haver problemes de tractar d'ajustar a una norma.
 Alguns de vostès poden haver sentit parlar de l'estàndard POSIX o d'una altra,
 potser altres característiques.
 Això pot ser seleccionat de vegades pels arguments de línia de comandes
 o establint les variables de shell.
 Anomenar com sh o bash en realitat pot conduir a una execució diferent
 fins i tot si és el mateix arxiu que s'està executant.
 Una altra cosa a considerar és que, fins i tot si un altre equip té tcsh o Bash,
 si no estan vinculats com estan a l'ordinador local
 si vostè té un equip local de Linux o Mac OS,
 després una altra vegada obtindrà la closca que es diu sh o csh, no el que és possible que prefereixi.
 The Bourne shell actual té millores menors que els de Bash
 però més enllà dels de l'intèrpret d'ordres Bourne original.
 Com a resultat que, fins i tot en el shell actual Bourne, SH,
 tot i que no és Bash, s'assembla al llenguatge C més que el C-shell fa.
 Això no era cert quan es va crear el C-shell primer, però s'ha desenvolupat d'aquesta manera.
 Vostè pot notar aquí que tots aquests noms de shell, excepte per al shell Bourne
 tenir alguna cosa que indiqui que la closca que són - csh, bash -
 però el shell Bourne és només sh.
 Per què? Aquest va ser el shell inicial.
 Va ser el Shell llavors, no una petxina,
 i ja que era la petxina, no hi havia cap raó per distingir d'un altre projectil.
 Així que per això té aquest nom i encara ho fa.
 

Aquesta samarreta aquí és una línia d'una base de dades de la contrasenya d'un compte que tinc allà
 en un altre equip.
 Vaig a tractar d'aconseguir que el nom perquè pugui veure aquesta part al final, la closca.
 La base de dades de la contrasenya té les característiques d'accés per a tots els usuaris.
 Al principi, és el nom d'usuari, que es pot veure els últims 2 cartes meves ara.
 Els camps aquí són separats per dos punts.
 L'últim camp, com es pot veure, és bin / tcsh, la closca.
 Aquest és l'especificador de shell.
 Hi ha alguna cosa interessant aquí.
 Quan Unix va ser desenvolupat per primera vegada, només hi havia 1 pela,
 així que no hi havia una altra opció que hi ha.
 Llavors, per què van permetre un camp a la base de dades de contrasenyes per especificar un shell?
 No sé, però és una sort que ho van fer.
 És bastant difícil fer canvis en el format de dades de contrasenyes
 perquè molts programes fan referència al seu format
 i hauria de ser reescrit.
 És un feliç desenvolupament o fortuït que inclouen aquest camp.
 Aquest tipus d'una línia d'arxiu de contrasenyes s'utilitza en tots els equips Unix i Linux pel que jo sé.
 El Mac té el seu propi sistema.
 En realitat, té un arxiu de contrasenyes amb les línies en aquest format,
 però no és aquí on es defineixen les característiques dels usuaris.
 Un altre comentari entre parèntesi allà.
 

Si diu un shell, se li pot anomenar com un sub-shell de les seves petxines existents.
 Així que si vaig allà, anem a desfer d'aquestes coses.
 Sóc aquí al C-shell.
 Aquesta variable, que identifica amb precisió de la meva closca,
 en realitat no és sempre una manera fiable de determinar quin shell s'està executant,
 però en aquest cas és.
 Què passa si jo només escric -
 Ara estic en Bash.
 Algunes coses van a ser els mateixos. ls em diuen els meus manaments.
 Si suspenc una tornada al meu C-shell, ls, igual. Cert?
 fg, primer pla, de tornada al meu shell Bash.
 pwd, directori actual, de nou a la C-shell.
 pwd, directori diferent - en realitat no és un directori diferent en aquest cas.
 És el mateix directori.
 Diguem que vull trucar a una ordre aquí: on ls.
 Què vol fer?
 Em diu quan la comanda ls,
 el que em dóna un llistat de directori, es troba en ls.
 Tornem a Bash shell. Intentarem el mateix.
 Hmm, interessant allà, on: command not found.
 Per què?
 La comanda on s'integra al C-shell.
 Això no és una ordre que ha de ser llegit en la memòria d'alguna altra part i executat.
 El C-shell s'executa mitjançant la transferència de l'execució de part del seu propi codi
 i no és en el shell Bash.
 Així Bash, que no tingui una ordre integrat, el busca, no el troba,
 i obtenim un error.
 Així que aquí tenim un intèrpret d'ordres s'executa amb un C-shell, i cridem a això un sub-shell.
 I en cas que és curiós, Bash shell té la seva pròpia manera de localitzar les ordres.
 hash es refereix al fet que es pot executar més ràpidament,
 trobant-se amb més rapidesa.
 Aquesta és una de les millores incorporades en algunes d'aquestes petxines.
 

Petxines de tipus Bourne es prefereixen per a la programació.
 Tenen estructures de control, com bucles, sentències condicionals,
 el tipus de comandes que pot utilitzar en llenguatges de programació com C
 o qualsevol idioma. Potser vostè està programant en Java o el que sigui.
 Els dipòsits tenen aquells massa.
 Les petxines de tipus Bourne, en particular Bash, tenen més
 i que estan dissenyats amb una major flexibilitat.
 L'intèrpret d'ordres té arrays. El shell Bourne original no ho fa.
 Així que pot ser considerablement més avantatjosa per a la programació.
 El C-shell realitat existeixen matrius, però no té una gran quantitat d'aquestes altres característiques. Les petxines de tipus Bourne s'executaran més ràpid
 si no tenen les característiques previstes per a l'ús interactiu.
 Es carregui les coses amb un propòsit, el que els carrega cap avall per a un altre propòsit.
 Aquí està aquesta disjuntiva allà.
 Aquestes característiques que estan destinades per a ús interactiu
 realment són de poc o cap ús de seqüència.
 És possible utilitzar un sub-shell interactiu com el que jo vaig començar allà
 per posar a prova les ordres que es va a utilitzar en un script.
 Això és el que no pots veure amb perl. Vostè pot fer-ho amb les petxines.
 Fins i tot les estructures com els bucles i així successivament es poden executar de forma interactiva.
 Ells són en ocasions útils per executar de forma interactiva,
 però el més probable és que vostè està utilitzant per desenvolupar un guió.
 

Alias.
 Això serà sobre el C-shell.
 Mecanisme d'Història on s'arriba de nou a les ordres anteriors
 o parts d'ells que ha ja ha executat.
 Una vegada més, sobre el C-shell, la shell Bourne i Korn shell tenen aquestes coses,
 però jo no vaig a entrar-hi.
 Així que aquí hi ha alguns àlies útils que tinc.
 En lloc d'escriure ls - és una ordre comú -
 només has d'escriure l i s'estalviarà 1 caràcter.
 ls amb diverses opcions, totes les feines.
 Tingueu en compte que aquestes definicions tenen cometes al voltant d'ells.
 En aquests casos, les cometes no són necessàries.
 Si vostè pot definir els àlies sense cometes, encara funcionaria.
 Són recomanats.
 Hi ha situacions en què no es pot utilitzar la cita
 perquè vostè vol que succeeixi alguna cosa que la cita impediria.
 De vegades es pot citar part de la definició, però no tots de la mateixa.
 També es recomana en general utilitzar cometes simples en lloc de cometes dobles.
 Les cometes dobles tenen efectes sobre la definició de les variables,
 sobretot fent que aquests siguin avaluats en lloc de detenir.
 Per què anàvem a voler aturar l'avaluació?
 I com fer que les cotitzacions per a nosaltres?
 

Aquest és una ordre que vostè pot ser que trobi interessant.
 'Ls g *'
 g *, com vostè probablement sap, és una expressió comodí
 per a tots els noms d'arxiu que comencen amb g.
 Si acabo d'escriure en un ordre ls g *, vaig a aconseguir una llista de tots els noms en el meu directori actual.
 Si jo defineixo aquest àlies, ja que és aquí amb les cometes,
 s'executarà aquest comando en el directori actual on s'està executant això.
 Però si executa la definició d'àlies sense cometes,
 avaluarà el comodí g * quan s'executa aquesta comanda de definició.
 Així que la definició de l'àlies es ls seguit per la llista d'arxius en el directori
 en què s'executa la comanda àlies,
 independentment d'on realment es va a executar la comanda.
 Això no és de molta utilitat, i les cometes simples a evitar l'avaluació de l'asterisc.
 Així que vostè acaba d'obtenir la definició ser ls g *.
 Després, quan s'executa l'àlies, LGS, llavors es posa això.
 Ara ja no hi ha cites, i avaluaran l'asterisc quan s'executa la comanda àlies.
 Així que això és una cosa.
 Les cometes dobles tindrien el mateix efecte aquí,
 però hi ha altres casos en què les cometes dobles no anava a funcionar tan bé.
 

Aquí és un altre.
 Potser coneguis la comanda grep.
 La comanda grep es pot utilitzar per examinar un arxiu per a les línies que tenen certes cadenes.
 Així que anirem d'aquí i sortiré de la meva shell Bourne.
 Okay. Aquí hi ha un arxiu.
 Diguem que és cadenes ABC grep. Aquí està.
 Si ho faig zddd grep, no aconsegueixo res. Okay.
 Així que troba una cadena, s'informa, no el troba, no n'informa.
 Genera qualsevol línia que té aquesta cadena en ell.
 Hi ha tot tipus d'opcions aquí que es poden trobar a la documentació.
 Heus aquí una manera de fer-ho.
 I aquesta, àlies grabc 'grep abc'?
 Això va a incloure 1 argument quan es defineix l'àlies.
 Així que si ho faig aquí, ara si ho faig grabc,
 ara l'àlies inclou més que el simple ordre. També té l'argument.
 Fins ara funciona.
 Tinc un altre comandament aquí, aquest, de manera que aquestes són les diferents cadenes d'aquí
 i demostrar que aquest no troba res allà ja que no coincideix.
 

Què passa si vull incloure en la definició d'àlies al fitxer que vaig a buscar
 i vull donar com a argument per l'àlies de la cadena que estic buscant?
 Podria voler dir abc com a argument al meu àlies,
 però l'àlies ja va determinar l'arxiu.
 I aquí és on entra en joc aquesta expressió
 Noteu aquí que hem grep igual que abans.
 Tenim l'arxiu aquí, cordes.
 \! ^, Tipus d'una expressió estranya, suposo, si vostè no ha vist això abans.
 Signe d'exclamació és part del mecanisme de la història de C-shell.
 Es pot recordar les ordres anteriors, es pot recordar arguments dels comandaments i així successivament.
 El mecanisme d'historial s'utilitza com a part d'aliasing.
 Si especifiqueu una línia després del signe d'exclamació, es referirà a aquesta línia en la llista de la història,
 que no estarem ficant ara, ja que és un tema totalment diferent.
 És possible especificar part d'una línia.
 So! 03:02 seria el segon argument de comandament número 3.
 El símbol d'intercalació en aquesta expressió representa el primer argument. Si no li donen una indicació de quina funció és referint,
 es refereix a la comanda immediatament anterior,
 i el símbol d'intercalació és un símbol per al primer argument.
 Com que és el símbol d'intercalació i no el nombre, no cal utilitzar els dos punts,
 so! ^ vol dir que el primer argument de l'ordre anterior.
 Una mica barrejat aquí.
 En aquest cas, quan s'utilitza això com una definició d'àlies,
 la referència de la història fa referència de nou a les ordres en què s'utilitza l'àlies.
 Així que això va a tornar 1 de comandaments com una operació de la història,
 sinó com una operació àlies fa referència a l'ordre en què hauria d'escriure,
 dir, grstrings_file.
 Tenim aquí les cometes en el mateix. Quina és la barra invertida per?
 En aquest cas, com en altres, no volem executar el mecanisme de la història
 mentre es defineix l'àlies.
 Si no tinguéssim la barra invertida allà, la closca es retiraria en el primer argument
 del comandament de la dreta abans que córrer aquesta comanda àlies, el que no volem.
 Volem que això s'integra en la comanda àlies per cridar en una discussió posterior.
 Les cometes simples no escapen a un signe d'exclamació, la referència de la història.
 Potser vostè sap la fuita expressió significa canviar el significat d'alguna cosa.
 En aquest cas, significa deixar una mica de tenir un significat especial.
 Significat especial del signe d'exclamació és història.
 Escapa i no té aquest significat.
 Cotitzacions no fan això; barra invertida fa.
 Així que en realitat estem fent servir 2 nivells d'escapar d'aquí.
 Vaig a moure aquesta comanda a l'altra finestra sense escriure-
 mitjançant l'ús d'aquestes operacions d'edició, que poden ser d'utilitat.
 Una altra cosa que aquí us vaig a mostrar.
 Si vostè acaba d'escriure àlies sense arguments, que li diu a tots els seus arguments.
 Es tracta d'un munt d'àlies que ja tenia aquí
 a més dels que he estat usant aquí avui.
 Però si acabo d'escriure amb el nom d'un àlies, em diu el que vol dir.
 Observi que les cotitzacions s'han anat i la barra invertida s'ha anat.
 Aquesta cadena d'aquí és el resultat d'aquesta definició d'àlies,
 i ara s'acaba! ^ en ella.
 Això es va a veure en les cordes d'arxiu per a res.
 Així que si ho faig cadenes grstrings_file, jo no li vaig donar res a buscar allà,
 però està buscant en les cordes.
 No trobava les paraules cadenes en les cordes d'arxiu, però sí trobar abc.
 I no troba això.
 Així que aquí estem donant un argument que impacta en la definició de l'àlies,
 que s'insereix en ell.
 És el lloc on aquesta expressió ve.
 Vostè pot utilitzar més d'1.
 El símbol d'intercalació és un símbol per al primer argument.
 Si voleu utilitzar un segon argument, vostè llavors dir: 2.
 No hi ha símbol especial per al segon argument.
 I perquè vostè està utilitzant un nombre, vostè hauria de fer servir els dos punts.
 Hi ha, però, una altra opció aquí.
 La mostra de dòlar representa l'últim argument.
 I perquè es tracta d'un símbol, pot ometre el còlon.
 Pel que seria l'últim argument en la llista.
 I també està aquesta.
 L'asterisc significa que tots, de manera que aquesta és la llista d'arguments completa,
 i de nou, es pot ometre el còlon a causa que no és un nombre.
 Espero que estiguis tot observant tot això.
 

El mecanisme de la història pot tornar a les línies anteriors a la llista de l'historial.
 Vostè pot fer això en una definició d'àlies.
 Mai he vist aquest fet.
 Això tindria l'efecte de treure les ordres anteriors a la llista històrica
 quan s'executa l'àlies, el que podria haver diferents ordres
 depenent de quan i on l'executa.
 És concebible que és possible que vulgueu retirar d'aquesta referència
 només per saber el que era una ordre anterior.
 Mai he vist que això passi.
 Suposo que algú podria desitjar, però això és molt poc probable.
 Hi ha una altra cosa aquí.
 Si utilitzeu aquesta referència de tipus de la història,
 a continuació, només s'utilitzen els arguments pels quals existeix aquesta referència.
 Si vostè té una definició d'àlies que no utilitza una referència de tipus de la història,
 Si només es converteix en el principi de la comanda
 i té més arguments, llavors qualsevol cosa que escrigui després que
 s'afegeixen a la comanda.
 En aquest cas, l'exemple que acabo de donar-hi, utilitzem el primer argument;
 no fem servir cap altre.
 Si s'haguessin donat altres arguments en la línia d'ordres, no s'utilitzarien.
 Així que si vostè utilitza la referència de la història en absolut, llavors vostè ha d'utilitzar per obtenir qualsevol argument.
 

Hi ha una altra cosa aquí només vull esmentar, en part, entre parèntesis,
 és a dir, que aquest mecanisme de la història amb el signe d'exclamació
 es remunta a la C-shell originals.
 El tcsh introduir operacions història
 que utilitzen el tipus de comandaments i cadenes dels editors,
 ja sigui Emacs o vaig veure.
 La meva opinió personal és que Emacs és molt més fàcil d'utilitzar per a aquest propòsit
 encara que utilitzi vaig per a l'edició regular.
 Hi ha diversos comandaments de Emacs que ara s'han adaptat a la història.
 Control P posa la línia anterior en la llista d'historial.
 Una altra Control P li aconseguirà l'anterior a aquesta.
 La fletxa cap amunt fa el mateix.
 Control No obté la següent comanda si ja s'ha desplaçat cap enrere alguns aspectes. Fletxa cap avall fa això també.
 Podeu moure d'esquerra a dreta amb les fletxes i diverses altres coses.
 Això pot fer ús del mecanisme de la història
 molt més fàcil d'utilitzar la sintaxi d'exclamació,
 però que no es farà servir que en una definició d'àlies.
 Anem a anar més que en un altre moment.
 

Variables.
 Saps el que les variables estan en llenguatges de programació.
 Les closques d'ells tenen també.
 El C-shell utilitza la comanda set per assignar les variables,
 pel que estableix la variable a un valor de b -
 com he dit, una definició inútil sinó una il · lustració de com s'utilitza.
 La comanda setembre crearà una variable si no existeix ja.
 Les posicions per als scripts de shell es poden considerar les variables,
 però l'ús dels mateixos i les regles per a ells són una mica diferents.
 No es pot assignar un valor a $ 1 en el transcurs d'un guió.
 Vostè hauria de definir una nova variable per a aquest propòsit si alguns de vostès volien.
 Escriu SET sense arguments i s'obté una llista de totes les variables definides actualment.
 I anem a arribar al meu altre shell aquí i vegem el que obtenim si fem això.
 Tota una llarga llista, oi?
 Desplaceu-vos amunt una mica. Mira tot això.
 Algunes d'aquestes coses es defineixen automàticament pel shell.
 El shell crea la variable i li dóna un valor.
 Alguns d'ells són definits pel shell, però després redefinides per l'usuari
 d'acord amb les seves preferències.
 I alguns d'ells són creats per l'usuari en funció del que està fent aquest dia.
 Això és només set sense arguments.
 Hi ha una estranya característica aquí d'aquesta cosa.
 Ha de ser o cap espai entre signe igual i el nom de la variable
 i el valor o els espais a banda i banda del signe igual,
 com en aquest un.
 Això no funcionarà, i això realment és una ordre vàlid
 però no va a fer el que tenia planejat.
 Aquest comandament funcionarà perquè si acabes de dir i establir un nom de variable
 sense signe igual o conjunt i un nom de variable amb un signe igual i sense valor,
 s'estableix la variable en un valor nul.
 Per tal d'establir a = és una ordre vàlid.
 La comanda setembre pot definir més d'1 variable sobre la mateixa línia.
 Així que aquesta comanda d'aquí té l'efecte de definir a i b a valors nuls.
 Probablement no és el que vols.
 Aquest d'aquí, es va esmentar anteriorment, donarà lloc a un error
 ja = b no és una expressió vàlida.
 Un nom de variable no pot començar amb el signe igual.
 I hi ha aquestes coses noves aquí.
 Els dos punts s'utilitzen per seleccionar els arguments de les línies de la història,
 i que poden ser utilitzats - i jo no van entrar en abans - per modificar aquestes coses.
 Ells també es poden utilitzar per modificar les variables de shell.
 Aquest d'aquí, $ a, té un valor.
 : R s'enlairarà una extensió.
 Una extensió serà qualsevol cosa després d'un punt,
 un punt i res després que al final d'un arxiu,
 només al final de la llista després de l'última barra.
 Així que tinc aquí.
 una és que. Es deixarà caure l'. O.
 Si no hi ha extensió, només els noms de ruta després de l'última barra, no tindrà cap efecte.
 a: h, que una expressió variable, s'enlairarà l'últim element d'una llista de directoris,
 de nou, només després de l'última barra.
 Així que / a / b / c es converteix en / a / b,
 però aquest es canvia perquè l'element després de la llista és nul.
 Aquí hi ha alguna cosa que també vull remarcar.
 Aquests qualificadors no busquen l'existència d'aquests fitxers.
 Ells només busquen cadenes.
 Aquests pretenen manipular els noms d'arxius, rutes d'accés,
 però es poden utilitzar en qualsevol cadena, encara que no és un nom de fitxer.
 I ells no busquen l'existència,
 pel que si no existeix tal arxiu, / a / b / c, això seguirà funcionant.
 Ja sigui d'alguna utilitat, és una altra qüestió, però encara funciona.
 Les variables són diferents en els shells Bourne. Ja arribarem a això més endavant.
 Signe de dòlar es pot escapar de la mateixa manera que el signe d'exclamació i l'asterisc.
 Signe de dòlar es pot escapar amb una barra invertida o les cometes simples.
 Les cometes dobles tenen l'estrany efecte en totes les petxines
 d'obligar a l'avaluació d'una mostra de dòlar expressió variable.
 Així que si està sent escapar d'una manera, les cometes dobles poden tenir l'efecte
 de causant que es pot avaluar de totes maneres.
 Això és una mica confús.
 Si hi ha diversos nivells d'escapar, com les cometes simples dins de cometes dobles
 o cometes dobles dins de cometes simples, s'ha de provar per veure què passarà
 a una variable si està utilitzant un.
 Aquestes situacions 2 - doble a l'interior d'un sol interior, únic de doble -
 no necessàriament li donarà el mateix resultat.
 Les variables d'entorn, variables de C-shell consolidats.
 Les variables d'entorn són també variables en el C-shell,
 i també són variables en altres closques massa.
 En el C-shell, són conjunts diferents.
 Les coses que jo deia abans són sobre les variables de shell.
 Les variables d'entorn són un conjunt diferent de variables
 amb l'excepció d'algunes variables que anomenem variables lligades,
 que són molt importants i entrarem en això més tard.
 Les variables d'entorn es transmeten automàticament
 a les petxines o els comandaments que s'executen des de la shell. Les altres coses no ho són. Les variables de shell, els àlies no ho són. Les variables d'entorn són.
 És per això que els anomenem variables d'entorn,
 La idea és que el medi ambient s'estén més enllà només la seva shell actual.
 Ells es poden utilitzar per definir les coses per les ordres.
 Heus aquí un exemple. IMPRESSORA, LPDEST.
 Ambdues variables es poden definir una impressora que una ordre s'utilitzarà per imprimir les coses.
 Si té diverses impressores en tot, és possible que vulgueu posar el que més t'agradi.
 La raó per la qual tenim 2 variables és que els diferents conjunts d'ordres es van escriure
 l'ús d'aquests diferents variables.
 Vostè pot donar-los valors diferents.
 El més probable és que els donis tant el mateix valor.
 Aquestes coses funcionen perquè les ordres que fan la impressió
 van ser programats per examinar els valors d'aquestes variables.
 Si un programa no es van escriure d'aquesta manera, si fos escrit per fer una altra cosa,
 la variable seria irrellevant.
 De manera que el sistema operatiu no està a la recerca d'aquestes variables
 cada vegada que es refereixen a una impressora.
 Un comando que fa la impressió està a la recerca d'aquestes variables si està programat d'aquesta manera.
 Aquestes variables es defineixen sovint en els arxius d'inicialització
 però no necessàriament.
 Vostè pot definir en la línia d'ordres.
 Poden definir-se en una ordre.
 Un comando que s'executa alguna cosa podria tenir la seva pròpia selecció de variables -
 variables que són exclusius d'un paquet de programari en particular, per exemple.
 Aquests seran definits quan s'executa el paquet.
 Com són aquestes variables passen a un sub-shell?
 Quan s'escriu un sub-shell, no escriu en aquesta àrea.
 L'àrea de la sub-shell que es dedica a les variables d'entorn
 que no està escrit pel sub-shell, sinó que està escrit per còpia.
 Quan s'executa una ordre comú, com ara aquestes comandes per imprimir o el que sigui,
 que comencen per la creació d'un nou shell.
 El shell crea una petxina i després sobreescriu part
 amb la comanda que s'està executant, que és una mica confús,
 però així és com aquestes comandes obtenen les variables d'entorn
 que a continuació es refereixen al futur.
 La comanda aquí per definir el setenv variable.
 Així és com es defineixen. És 3 elements: setenv, variables, valor.
 Si només setenv sense arguments, què s'obté?
 Una llista de totes aquestes variables.
 De nou, és una bona llista llarga i en aquest cas, com en els altres,
 aquestes variables es defineixen en gran part per la meva intervenció d'inici de sessió pel mateix dipòsit
 no per res del que vaig fer.
 Hi ha un altre comandament aquí, printenv.
 Això també imprimeix el medi ambient.
 Observeu aquest últim que aquí, = Editor vaig veure.
 Això diu que si estic fent servir una cosa que crida a un editor
 i no específic un editor i em permet l'elecció, pot donar-me vaig veure.
 Què passa si faig EDITOR printenv? Em diu el que és.
 Just abans d'això, hi havia una variable, MENYS.
 Aquestes són les opcions per defecte quan executo la comanda MENYS,
 que mostra fitxers.
 Així que si faig això, printenv pot prendre 1 o 0 argument arguments,
 no més d'1.
 Hi ha altres ordres també, però no entrarem en tot el que avui en dia.
 Recordeu que no eren els modificadors de les variables de shell, com: h,
 que el portarà fins a l'últim element d'una ruta d'accés,
 o: r, que es reduirà una extensió.
 Aquells ara s'apliquen a les variables d'entorn també. Ells no solien fer-ho.
 Solia ser que no podien ser modificats. Ara que pot ser.
 És un dels avenços amb els desenvolupaments de les petxines en els últims anys.
 Deia que les petxines com a part dels entorns
 i les variables de shell al C-shell són, amb algunes excepcions, conjunts diferents.
 Podeu establir una variable d'entorn i una variable de shell amb el mateix nom.
 Seran diferents variables, ja que poden tenir diferents valors.
 Canviar el valor d'un no canviarà el valor de l'altra.
 Aquestes variables es van avaluar amb el signe de dòlar - $ a, $ el que sigui.
 I què si vostè té això? Sap vostè quin s'obté?
 En els meus proves em van donar la variable de shell,
 però això no està documentat i no es pot confiar en això.
 Així que em pregunto, és la creació de les variables de shell i el medi ambient
 amb els mateixos noms una bona idea? No D'acord.
 Quins són els principals excepcions en què les variables de l'entorn i shell
 estan vinculats l'un a l'altre?
 Hi ha aquests 4.
 Variable d'entorn TERM Majúscula,
 shell terme variable en lletres petites, tipus d'emulació de terminal.
 Jo només vaig a anar d'aquí i jo faré ressò, una ordre útil en aquest cas,
 $ $ TERM termini. I aquí.
 xterm és un tipus de terminal per a les finestres que apareixen en el sistema X Window.
 xterm-color és una variació del que permet que diferents colors.
 Per què ens definim aquests? Què és això bo?
 Les comandes que reorganitzen la pantalla com l'editor
 enviar seqüències particulars, trucades seqüències d'escapament,
 a un terminal o una finestra per reorganitzar i així successivament.
 Aquestes seqüències són diferents per a diferents tipus de terminals.
 Això li diu a ella que els utilitzin.
 De vegades hi ha problemes allà. És possible que vulgueu canviar això.
 Si les coses no funcionen, de vegades el tipus de terminal es configura malament,
 vostè pot ser capaç d'arreglar per redefinir el terme variable.
 En aquests casos, el canvi d'una variable, la variable d'entorn o la variable de shell,
 ha de canviar l'altre.
 He descobert a través de l'experiència que el canvi TERM en majúscules
 no sempre canviar variable de shell terme en minúscules.
 Això és un error.
 No sé si això és sempre veritat. La majoria de les vegades no és veritat, però que pot ser.
 Així que si vostè fa un canvi, simplement comprovar que fos.
 No és freqüent que es necessita canviar aquest valor, però de tant en tant ho fa.
 Variable d'entorn USER.
 Un cop més, la variable d'entorn en majúscules, shell variable en minúscules.
 Aquest és el seu nom d'usuari.
 És només en circumstàncies molt excepcionals
 que t'agradaria canviar això.
 Si el seu nom d'usuari és una altra persona, que pot llençar tot tipus de coses.
 Directori d'inici, el directori home de l'usuari.
 Una vegada més, no vol canviar això.
 Fixeu-vos en tots aquests casos i la que estem a punt de cobrir, la variable de ruta,
 variable d'entorn és en majúscules i la variable de shell unit és en minúscules.
 Si canvia un, vostè ha de canviar a l'altra.
 Aquest tipus d'unió no es pot establir com no es pot obligar a 2 variables,
 a part d'aquests 4, i la unió d'aquestes variables no es pot desfer,
 no es pot separar.
 Així que aquests 4 parells de variables estan obligats.
 Ells sempre seran. Cap altres seran.
 A més, seria possible crear variables amb els mateixos noms
 dels tipus oposats.
 Vostè podria fer un terme variable de shell en minúscules
 o una variable d'entorn TERM en majúscules.
 Aquelles variables serien independents d'aquestes variables aparellades
 i que serien independents l'un de l'altre.
 No puc imaginar per què faria això a menys que vulgui confondre la gent.
 Aquest d'aquí, variable de la ruta, aquesta és una molt important.
 Una altra cosa és que no pot haver-hi casos
 de variables amb noms aparellades similars que no estan vinculats entre si.
 No hi pot haver variables, Shell i Shell, en majúscules i minúscules.
 Sobre la base d'aquest nom, que no saps si aquesta variable és una variable de shell
 o una variable d'entorn, i estan no lligats entre si.
 Així que aquest tipus de parells de noms no implica variables lligades.
 La variable de la ruta, que estava mostrant abans,
 és una llista dels noms de les rutes en què el shell busca els comandaments.
 Anem a aquesta finestra aquí i farem tot el echo $ PATH, majúscules -
 variable d'entorn - echo $ PATH, minúscules - shell variable.
 Observeu que la llista de directoris és el mateix. Aquests estan obligats.
 Canvia un, canvia l'altre.
 A la variable d'entorn els elements estan separats per dos punts. Tingueu en compte que.
 Les variables de shell estan separats per espais.
 Aquesta variable d'entorn és una sola cadena.
 La variable de shell és una matriu.
 El shell Bourne no tenia arrays.
 Bash fa, però això ja és una part fixa de la closca.
 Es tracta d'una sola cadena i no una matriu.
 El C-shell sempre va tenir arrays.
 Les matrius són molt més fàcils de treballar.
 Pot fer referència a parts d'ella.
 $ Ruta Llavors trobo [1] i em surt / usr / bin, el primer element.
 Un cop més, recordi signe de dòlar representa l'últim element de la llista de l'historial.
 Què passa aquí? Es va tractar de trobar el signe de dòlar com un símbol de la variable.
 M'escapo ella. Ho sentim. No caldria que sigui.
 Algunes d'aquestes coses no funcionen tan bé.
 Potser només haurem de deixar això a terme.
 L'asterisc es refereix a tota la cosa, però això és el que s'obté si no s'especifica un element.
 Una altra forma en què les variables de matriu es poden manipular,
 nombre d'elements allà, 7 elements.
 Aquí posem el signe de nombre abans del nom de variable.
 Hi ha un altre. Poseu un signe d'interrogació allà.
 Aquest és un valor lògic. Això indica que la variable existeix.
 És una altra forma de treballar amb variables.
 Que, per cert, no ha de ser una variable de matriu.
 Això podria ser qualsevol variable.
 I si ho faig, no hi ha tal variable i em sento un 0.
 Una altra petita cosa que hi ha sobre les avaluacions de variables.
 Tornar a aquest d'aquí, si per alguna raó vostè volia treballar amb aquest
 en lloc de treballar amb la matriu, la variable de shell,
 hi ha comandes que poden separar aquestes coses sobre la base dels dos punts.
 De fet, si vostè va a estar fent això en l'intèrpret d'ordres, possiblement,
 una mena de guió, que seria probablement la manera com ho faria.
 Però en el C-shell és molt més fàcil d'usar de la reparació.
 En el shell Bourne, variables que són assignades per una sola expressió d'aquest tipus,
 com la forma en què vostè pot assignar una variable en un llenguatge de programació,
 i aquí no hi ha espais.
 Cal que sigui sols 1 cadena.
 En les petxines de tipus Bourne, totes les variables són variables de shell.
 Les variables d'entorn són un subconjunt de les variables de shell.
 Es distingeixen de les variables no ambientals mitjançant l'exportació. La comanda per fer-ho és l'exportació, com IMPRESSORA exportació.
 Si haguéssim de definir una variable d'aquest tipus,
 si volíem una ordre d'impressió per trobar-lo, hauria de ser una variable d'entorn,
 i així és com ho fem un.
 Aquí hi ha alguna cosa una mica confús.
 Aquesta expressió, la seva exportació al medi ambient, es deriva d'aquest concepte shell Bourne,
 i no obstant això, aquesta expressió s'utilitza en la descripció de la C-shell,
 on no hi ha tal ordre com d'exportació.
 Si vostè acaba de dir exportació per si mateix, s'obté una llista dels exportats -
 Així que si jo simplement exporto aquí, no hi ha tal cosa.
 Bé, aquí anem.
 Aquestes coses, per cert, també es defineixen pel shell.
 No em defineixo qualsevol d'aquests per mi mateix.
 La conquilla fa tot tipus de coses per si mateix.
 S'ha de fer les coses de forma automàtica.
 En Bash o Korn, es pot executar una ordre com el següent,
 que tots dos donen una variable un valor i exportar en 1 comandament.
 Al shell de Bourne han de ser ordres separats com exportació a.
 Hi ha un altre aspecte que és confús.
 La comanda set en el C-shell defineix variables
 i sense arguments et diu quins són els valors de les variables són.
 En l'intèrpret d'ordres, la comanda set sense arguments fa el mateix,
 però amb arguments que fa una cosa molt diferent.
 Així que aquests són els diversos arguments aquí.
 Alguns d'aquests són les variables d'entorn, algunes d'elles són les variables de shell.
 Totes elles són variables de shell realment. Algunes d'aquestes són les variables d'entorn.
 La comanda set amb arguments pot ser usat per operar
 sobre els paràmetres de posició a un guió,
 que és una forma d'accedir-hi d'una sola vegada.
 En realitat no podem entrar en això avui.
 També es pot utilitzar per canviar el comportament de la closca.
 Particularment en Bash hi ha variables que determinaran el comportament del shell.
 Llavors també només aquesta comanda que vostè pot veure, aquesta comanda.
 Typeset seguit de variables i tipus de variables s'usa en els shells Korn i Bash.
 No és obligatori, però pot ser utilitzat per restringir els valors de les variables,
 que pot ser útil per evitar errors, i és bastant comú.
 Així que només estic esmentant que en cas que vegi en algun lloc.
 La comanda on.
 Recordes que he esmentat abans, el lloc on el manament al C-shell,
 que li pot indicar la ubicació d'una ruta d'accés d'ordres.
 Aquí està la substitució de comandes.
 Vostè ha de trobar en el seu teclat en algun lloc d'un personatge que s'assembla a això.
 La ubicació en el teclat variarà.
 L'hem anomenat backquote. És aproximadament de la mida d'una cotització.
 Va des de la part superior esquerra a la inferior dreta.
 Aquí a la meva teclat Mac està a la cantonada superior esquerra.
 Aquest caràcter es pot utilitzar per executar una ordre en una ordre.
 Si vostè té una expressió dins cometes inverses,
 aquesta expressió és una ordre, s'executa.
 La sortida d'aquest ordre
 és substituït després per tota l'expressió backquote
 dins d'un comando ja que llavors s'executa amb que la producció
 com a part de la seva sèrie d'arguments i així successivament.
 Aquest és una ordre que utilitza això.
 Demostrem l'operació aquí.
 Pugem aquí, treure les cometes inverses.
 Control d'A m'arriba al principi de la línia amb la sintaxi d'edició d'Emacs.
 Fins ara, la rutes d'accés és el que d'on ve,
 però quan ho faig d'aquesta manera, llavors es connecta a aquesta llista de noms de ruta
 en lloc de tota aquesta expressió backquote i s'executa ls-l en ells.
 Una cosa còmode, no?
 Així que això és una cosa ordenada. Així és com funcionen cometes inverses.
 Ara anirem una mica més lluny.
 Aquests són els àlies. En realitat jo ús aquests.
 Vaig a tractar d'aconseguir-ho amb 1 operació d'edició.
 Okay.
 Ara anem a veure com aquestes definicions van sortir.
 àlies LWH dir-me com es defineix.
 Observi que és només això, però les cotitzacions externes s'han tret
 i el signe d'exclamació se l'emporten fora.
 ! *, La llista completa de tots els arguments.
 En una definició d'àlies que s'aplicarà de nou a on jo faig servir això.
 LWH festa ksh. Okay.
 Veus com funciona? Em estalvia una mica de tecleig.
 Pugem una mica sol per esmentar alguna cosa més aquí.
 Noteu aquí aquests projectils diferents. Hauria haver-ho dit abans.
 El csh té un 2 per aquí i també ho fa / bin / tcsh.
 Podríem establir per mitjans que no són en realitat el mateix arxiu.
 Recorda que jo estava dient si escriu SH s'obté bash.
 Introduïu això i vostè té això.
 Però els que no estan vinculats. Aquells tenen els sols allà.
 I aquest no és el tipus d'arxiu que es digui a un altre.
 Així que aquests són arxius separats, les C-shell són el mateix arxiu.
 Tornar aquí baix, l'altre aquí, aquest àlies,
 tingui en compte que s'està executant aquesta comanda, arxiu.
 Això àlies funciona això. Arxiu indica el tipus d'un fitxer.
 Festa ksh Així FWH. Okay.
 Aquest és el resultat de la comanda file.
 No sé si vostè sap el que això significa aquí,
 Mach-O binari universal, amb 2 arquitectures.
 Hi ha 2 possibles tipus de processadors a Mac,
 i alguns programes van ser escrits per ser capaç d'executar amb tots dos,
 i la comanda file pot determinar que, pel que això és el que això significa.
 Tots dos arxius van ser escrits d'aquesta manera. Així veiem com funciona l'àlies, veiem com funciona el backquote,
 veiem com funciona el ls real dels arxius o d'arxius.
 Això podria no funcionar. Try "on on" i "LWH on". Bé, intentarem això.
 on on.
 on és una closca integrada.
 Recordeu que ja va demostrar que Bash no tenia on.
 Si escriu en quina part de l'intèrpret d'ordres, apareix un missatge d'error.
 És només una part de la coberta en lloc de ser una ordre independent.
 Què passa si escric LWH buscant on? Mireu el que passa allà.
 Ran on on, aconseguit aquest resultat, i després va tractar d'executar ls
 com l en on és una closca integrada.
 on hi és, però no existeixen els altres.
 Cap d'ells existeix, en realitat.
 Així que no sempre funciona, i també il · lustra com algunes coses
 no fas exactament el que vostè podria haver pensat.
 Baixem una mica més aquí.
 Això aquí és en Bash. Aquesta és també la substitució d'ordres com la cometa inversa.
 Però a diferència d'backquote, utilitza aquest estil variable.
 Hi ha una sèrie d'expressions que comencen amb un signe de dòlar,
 i si bé aquests no són variables, van prendre prestat l'ús del signe de dòlar
 per indicar una expressió d'algun tipus.
 Això pot estar envoltat de parèntesi o claudàtors o parèntesis dobles,
 que té un propòsit diferent.
 Parèntesi Solter aquí són una substitució d'ordres igual que els accents greus.
 Parèntesi dobles és en realitat una operació aritmètica.
 Hi ha altres sintaxi, altres operacions.
 Sintaxi backquote està disponible en Bash.
 No obstant això, aquest és preferible. És molt més fàcil de llegir i que permet la implantació.
 Vostè pot tenir dins de $ (comanda) un altre ordre,
 una mena -
 Puc obtenir una llista allà.
 Això funcionaria si tingués la cometa inversa també.
 I si vull fer alguna cosa així -
 Vostè probablement no realment utilitzar aquesta comanda,
 però aquesta substitució d'ordre intern es fa ressò dels noms de tots els arxius que comencen amb a,
 llavors aquest s'executa ls-l en aquests arxius,
 i llavors aquest només es fa ressò de la sortida.
 Vostè probablement no faria això, només faries el ressò o ls,
 però això il · lustra el funcionament de la implantació d'ordres.
 Així que una altra de les característiques aquí.
  He esmentat això abans, que quan es té en quin lloc del C-shell,
 escriure obres en les petxines de tipus Bourne per a la localització de les ordres.
 Ordres incorporats, just el que estava dient que no.
 Les comandes són part de la closca, com on.
 Quan el shell executa una ordre com ls, es localitza a través de la ruta,
 el troba en algun directori en algun lloc,
 diu que en la memòria, es crea un nou shell,
 llegeix la comanda ls o el que sigui a la closca
 on ja se situen les variables d'entorn,
 i després es transfereix l'execució a la mateixa.
 Incorporat en el comandament, el codi per aquest comando és l'interior de la closca,
 de manera que el shell només comença a executar part del seu propi codi.
 on és una ordre. En realitat es fa més ràpid.
 No ha de llegir res en la memòria, sinó que ja és a la memòria.
 Ordres integrats sempre tenen prioritat sobre les ordres amb el mateix nom.
 Les comandes que es troben en els directoris en la ruta d'accés poden tenir el mateix nom,
 comandaments en diferents directoris, arxius en directoris diferents.
 La que es produeix abans en el camí és el que s'obté.
 Si hi ha una ordre integrat, que sempre ho aconsegueix.
 No hi ha manera de donar-li una prioritat més baixa que un comando en el camí.
 Si vol aconseguir que la comanda path, pot escriure el nom de ruta complet.
 Si hi havia una ordre on a la ruta d'accés en algun lloc,
 podria escriure / bin / on i que ho entendries.
 Si no voleu escriure tota la ruta, es podria definir un àlies.
 De fet, si vostè li va donar l'àlies el mateix nom que la comanda integrat, que funcionaria
 perquè s'avalua la definició d'àlies
 abans que el shell determina que es tracta d'un comando integrat en el qual s'ha d'executar.
 Llavors això es torna una mica més complicat amb alguns comandaments aquí.
 El cas d'alguns comandaments són en realitat construïda en els comandaments i en el camí.
 Un d'ells és l'eco, la comanda que acaba d'utilitzar fa una estona en aquests exemples.
 Echo és una ordre a la ruta i que es troba en tots els dipòsits.
 No necessàriament tots es comporten de la mateixa manera.
 En el seu origen va ser una ordre només en el camí.
 Va ser construït en les petxines més tard.
 Com que hi ha opcions que depenen del medi ambient
 i les opcions de línia d'ordres, les ordres integrats
 van ser escrits per a funcionar el mateix que el comandament que havia estat en el camí,
 és poc probable que haguessin estat escrites d'aquesta manera
 si la comanda ja no havia estat escrit pel camí.
 Així que això té efectes secundaris. La seva història té efectes aquí.
 Hi ha opcions que hi ha.
 També hi ha una opció definida per una variable en el tcsh anomenat echo_style.
 Aquesta és una de les variables que poden canviar la forma en què es fan ressò les obres.
 Hi ha altres casos en què pot assignar una variable
 que canvia la forma en què l'operació de la closca, com una ordre integrat, funciona.
 No afectaria qualsevol altra cosa
 ja que altres ordres no tenen accés a les variables de shell,
 només les variables d'entorn. Però les operacions de shell poden llegir les variables de shell.
 Això no funcionarà per csh. Això és només tcsh. Aquesta és una de les millores.
 Parsing té seqüències quan s'avalua metacaracteres,
 quan s'avalua les variables, àlies, referències d'història.
 Hi ha una seqüència particular per a aquestes coses.
 Si fa les coses d'una seqüència particular
 i arriba a alguna cosa que és una expressió d'una espècie
 que ja ha estat avaluat, no va a avaluar de nou.
 Si ho aconsegueix, llavors, només es passarà en els personatges.
 Així que si l'avaluació d'algunes expressions com la substitució de comandes
 o variable o el que sigui dóna lloc a una expressió
 que li agradaria que per ser avaluats,
 que funcionarà només si aquesta avaluació es produeix al final de la seqüència.
 Espero que estic sent clar que no.
 Aquesta seqüència d'anàlisi, una operació al C-shell,
 no és el mateix per les ordres integrats com ho és per als comandaments dels no integrats.
 No estic segur sobre Bash allà.
 Per exemple, si una variable Shell va produir una referència història,
 probablement no tornaria a la història.
 Seria acaba d'obtenir el signe d'exclamació.
 De fet, només podem provar això ara mateix.
 establir a = i haurem de posar això aquí.
 Oh, espera. Ho sento. Ho vaig fer en el Bash. Jo volia fer-ho aquí.
 Veure, pel que no va avaluar que la referència la història
 perquè ja era passat el punt d'avaluació d'expressions d'història
 quan es va avaluar la variable.
 Així que això és 1 efecte d'anàlisi.
 I de nou, comandaments integrats no es fan de la mateixa manera.
 Està bé. Anem a anar a la següent aquí.
 Aquest pretén ser 1 línia, però està fent més fàcil la lectura.
 Què vol fer?
 Vostè pot recordar que puguem avaluar asteriscs com comodins de nom d'arxiu,
 i hi ha altres determinats comodins, com el signe d'interrogació i expressions amb claudàtors.
 Aquest tipus d'avaluació es denomina globbing.
 establir noglob a principis d'aquesta comanda diu no facis això.
 noglob unset diu tornar a fer això.
 Tingueu en compte que conjunt globus no tindria aquest efecte.
 En el llenguatge ordinari, globus establir o noglob unset semblen ser equivalents,
 però aquí no ho és. És noglob desarmat.
 Ara tset. tset va parar per al grup terminal.
 No s'usa sovint que ara, però abans de disposar de sistemes de finestres
 i que tenia una sola terminal, potser hagi de determinar el tipus.
 I si alguna cosa havia de venir a través d'Ethernet o de la xarxa,
 vostè podria voler dir que és un vt100.
 VT100 és una espècie d'estàndard en el negoci de terminals. Prové de la terminal DEC.
 Si vostè acaba de fer dial-up - adonar que? Això es remunta un llarg camí, eh?
 Així que si simplement no tset aquí,
 si jo només faig tset, ha de restablir la meva terminal, però no va veure res.
 En realitat no canvia res.
 -S
 Okay.
 setenv TERM xterm-color.
 Ja sabem que el terme es va establir d'aquesta manera, així que això no canviava.
 Aquesta és la manera que ens agradaria fer-ho.
 Però noti que aquesta comanda, tset-s, la sortida només aquestes comandes. No executar-los.
 No executar aquestes comandes, sinó que la sortida d'ells.
 Així que aquesta és la intenció de produir comandaments que després s'executen.
 Te'n recordes de l'ordre en aquest arxiu que acabo mostrar que tenia una Q al mateix.
 Així que anem a fer això.
 El Q suprimeix alguna sortida, però això no passa allí, com es pot veure.
 Jo només vaig a fer això per mostrar que no tenia importància.
 Això està en la sintaxi backquote.
 Tingueu en compte el backquote aquí, backquote aquí.
 Estic ometent aquestes coses aquí.
 Aquests són els casos de dir-li què fer
 en el cas de determinats tipus de terminals -
 Ethernet, xarxa telefònica, el que vostè té.
 No importa aquí perquè no estem fent en realitat cap d'aquestes coses.
 Només estic il · lustrant la comanda.
 Si faig això amb la cometa inversa, què vaig a rebre?
 Tingueu també aquí que aquesta inclòs el noglob set i el noglob unset,
 Així que aquests són ara redundants en la definició.
 Això no va ser sempre així, però ara estan incloses en aquesta ordre.
 Però anem a veure què passa si faig el que
 i vaig al principi de la línia amb Control A i ho faig.
 Bé, estableixi: Command not found. Això és una mica estrany, no?
 conjunt és una ordre molt conegut. És part de la closca.
 estableix: Command not found? Per què?
 Hmm. Bé, anem a pensar en això.
 S'està executant una substitució d'ordres backquote,
 i que es produeix a una certa part de la seqüència d'analitzar la comanda.
 conjunt és una ordre incorporat.
 Així que per al moment en que fa que la substitució d'ordres,
 que ja ha aconseguit més enllà del punt d'identificació d'ordres integrats.
 Per tant, tracta a establir com si es tractés d'un comando en el camí.
 No cal dir, que no el troba i s'obté un error.
 Bé. Hi ha un exemple de seqüència d'anàlisi.
 I què fem al respecte?
 Observeu aquesta comanda molt interessant aquí, eval.
 Em pregunto el que fa.
 Si ens fixem en el manual - i farem això
 per mostrar el confús aquests manuals són -
 man tcsh, manual confusa, la recerca de les coses que aquí no és fàcil tampoc.
 Aquí anem, eval arg, perquè puguem tenir 1 o més arguments
 i hi ha una llista de coses que hi ha. S'usa per tractar els arguments com entrades a l'intèrpret d'ordres
 i executa les ordres resultants en el context de la shell actual.
 Això s'utilitza generalment per executar ordres generats com a resultat de comandament
 o la substitució de variables, perquè l'anàlisi es produeix abans que aquestes substitucions.
 Molt bo.
 I aquí fins i tot es refereixen a l'ordre tset per a un ús de la mostra
 com la que acabo de mostrar.
 Ara he de aconseguir la finestra de nou a un lloc útil.
 Anem per aquí i anem a veure que eval s'utilitza just abans d'això.
 Així que anem a veure què passa si posem - aquí anem amb les fletxes a aquest ordre
 i controlar una al principi, EVAL.
 Bé, pel que funciona.
 En fer eval, que triga el que ve després i ho fa una ordre.
 Això li permet essencialment Parse dues vegades.
 La secció aquí s'executa aquesta comanda dins de les cometes inverses,
 obté la sortida.
 Se suposa que la sortida que s'executin com aquests comandaments aquí com aquests
 en aquest i aquest.
 Així que aquests comandaments estan ara aquí en aquesta seqüència,
 però aquests estan incorporats en els comandaments i no poden obtenir immediatament.
 Així que anem a eval, eval recull que fins, comença tot de nou, i funciona.
 Un exemple tant de backquoting, eval, l'anàlisi, les conseqüències de l'anàlisi sintàctica,
 i una ordre que és probablement de molt poca utilitat per a vostè avui en dia.
 Okay. Molt bé, umask.
 Fem una ullada a aquesta comanda aquí, umask 022. Em pregunto el que fa.
 Anem a escriure umask sense res després d'ella. 22. Okay.
 022 i fer-ho de nou.
 Com ja hauran endevinat, umask sense arguments et diu la màscara actual;
 umask amb arguments fa que sigui això, però aquesta era la que ja tenia.
 Què significa 022?
 Aquests són aquí les proteccions per a un arxiu.
 Ells determinen qui pot llegir o escriure o executar l'arxiu.
 Proteccions també s'anomenen els permisos.
 La r representa de lectura, el w per escriptura,
 i la X, que no està present allà, significa executar.
 Hi ha 3 categories d'allà.
 Els 3 últims elements es troben en la categoria d'usuari. Aquells s'apliquen a mi, l'usuari.
 Aquests 3 aquí s'apliquen al grup.
 L'arxiu pertany al grup 1, l'usuari pot pertànyer a diversos grups,
 però si l'usuari està en el grup al qual pertany l'arxiu,
 a continuació, aquestes proteccions s'apliquen a ell si ell no és l'usuari.
 I aquest és tot el món.
 Aquestes categories són mútuament excloents.
 Les proteccions d'usuari s'apliquen a ell,
 les proteccions de grup s'apliquen als membres del grup que no sigui l'usuari,
 i les altres proteccions només s'apliquen a persones diferents de l'usuari, i els membres del grup.
 Si hi ha una ro aw o x, significa que s'ha concedit la protecció.
 Si hi ha un guió, vol dir que no és.
 De fet, hi ha altres coses que es poden posar aquí a més d'aquests,
 que no vaig a entrar en ara.
 El umask defineix un valor predeterminat per als arxius que vostè cregui.
 I com una màscara, bàsicament, diu que els bits que no s'hagin establert.
 Com s'ha convertit en trossos?
 Si vostè pensa en cada un d'ells com un nombre octal,
 aquest és el bit de 1s, això és els 2s, això és els 4s.
 Així que de 0 a 7
 descrigui quina combinació de r, w de, i les x que té per aquests 3
 i després un nombre similar d'aquests i després per aquests.
 Així que 022 significa 0 per a l'altra, per al grup 2, 2 per a l'usuari.
 Però això és una màscara. La màscara és el que no hi ha.
 Ho sento. M'acabo de donar les coses en l'ordre equivocat.
 És la primera març. Aquests 3 són l'usuari, aquests 3 són el grup, aquests 3 són els altres.
 Ho sento, et vaig donar aquests en l'ordre equivocat.
 El 0, que és el primer d'ells, no es mostra el valor,
 però si un nombre no és aquí, és un 0.
 Això vol dir que tots els 3 d'ells es permetria.
 Observeu que en aquest en particular no es permet que la x.
 La raó és que la pela és capaç de determinar
 si un arxiu ha de ser executat o no.
 Atès que això no és un arxiu executable, que no va posar la x.
 Els 2 significa que el permís d'escriptura, la segona categoria aquí,
 el que està al mig, se li nega.
 Així que de nou, aquestes són les coses que es va negar.
 Bé, està permès x però no és aquí perquè no és executable
 i el mateix per als altres.
 Així que això és un umask comú.
 Una altra comuna és 700 - donar-te tot i ningú més res.
 I hi ha altres possibilitats.
 Vaig a tornar a això. L'ús de la història que puc buscar de nou per això, LWH cap allà.
 Okay. Així que aquí, aquestes són les petxines.
 Bash, l'amo, que és el compte del sistema, pot fer-ho tot.
 Grup i tots els altres poden fer lectura o d'execució, però no escriure.
 Aquest ni tan sols permet al propietari per escriure-hi.
 Si el propietari volia escriure en ell, el compte del sistema,
 hauria de canviar la protecció primer.
 Però, de nou, la umask estableix el valor predeterminat per emmascarar,
 indicant les parts que no es poden establir.
 Això és en general en un dels arxius d'inicialització, que és l'arxiu. Cshrc pel C-shell
 o el perfil. per a les petxines de tipus Bourne.
 Pot ser en un altre lloc també si hi ha altres arxius d'inicialització en el sistema.
 De tota manera, això és umask. Hi ha alguna cosa una mica estrany aquí,
 i és que, per què hi ha un sol comandament per això?
 Si estigués escrivint això, m'agradaria que sigui una variable, umask = algun valor.
 Per què hi ha tot una ordre per a aquest propòsit?
 La raó és aquesta només es remunta als orígens de Unix.
 Unix era només un projecte de programació en els Laboratoris Bell en la dècada de 1970.
 La gent només es van reunir per al programa.
 Ells mai van tenir la intenció que es converteixi en un sistema operatiu a tot el món.
 Diferents persones van escriure diferents parts sense pensar molt
 de com es van a utilitzar - més aviat succinta.
 I es van unir així, i segueix sent així en alguns aspectes.
 Així que reflecteix la història, i encara hi ha aquestes incoherències i els elements estranys de la mateixa.
 Okay. Següent 1 aquí.
 Com he escrit abans, el C-shell no s'usa realment molt per a la programació,
 encara que pot ser.
 S'executa més lentament, de nou l'equilibri entre l'ús interactiu,
 que tenen més informació que la velocitat de processament implicat,
 que es pot fer sense el processament.
 Les característiques addicionals afegides a la shell Bourne pel Korn i Bourne-Again petxines
 no sembla que disminueixi la seva velocitat, i jo no sé per què és així.
 Potser només sigui una millor programació, però no estic en condicions de saber.
 Accelerar aquí en realitat no és una cosa molt important, tot i que s'esmenta.
 La raó és que els scripts de shell realment aconsegueixen bastant ràpid.
 Si hi ha una gran quantitat d'ordres com en un programa de càlcul,
 és probable que no ho faries en un script de shell.
 Les operacions no són bastant simple i directe.
 Els que jo he experimentat que són massa lents
 involucrar les aplicacions repetides d'ordres lents.
 Abans he esmentat l'editor de flux set. Aquesta comanda és lent.
 Si executeu set moltes vegades, obtindràs un script lent, però no és la closca que és lent.
 Si l'executa en el shell Bourne no serà molt més ràpid que corrent al C-shell,
 encara que no hi ha tal vegada alguns avantatges allà.
 Les capacitats de programació addicionals, d'altra banda,
 són raons importants per les quals s'utilitzen les closques de tipus Bourne.
 C-shell té característiques estranyes a ella -
 el fet que vostè no sap si una variable és una variable de shell o una variable d'entorn.
 Pot ser molt confús.
 No és tan fàcil d'escriure
 només es basa en la seva experiència en programació en altres idiomes.
 Crec que és possible que les petxines de tipus Bourne més consistent amb la seva experiència.
 Algunes seqüències d'ordres, però, poden ser milers de línies de longitud.
 Els que he vist s'utilitzen per parchar els sistemes operatius.
 Aquests poden executar molt lentament, però que no es quedi els molt sovint.
 És només quan vostè està fent pegats,
 i és només l'administrador del sistema que faci aquestes coses,
 així que no és realment un gran problema.
 Els que són centenars de línies de llarg realment s'executen amb força rapidesa.
 En esmentar això aquí, quins són aquestes millores?
 Ja he esmentat alguns d'ells - Arrays, càlculs,
 els $ () d'expressió per als càlculs en l'intèrpret d'ordres,
 l'altre tipus de substitució d'ordres.
 Hi ha diferents tipus d'ordres de prova
 mitjançant el qual és possible realitzar proves a l'existència d'un fitxer o altres coses.
 L'última vegada aquí, aquesta comanda aquí.
 Què fa això, i per què ningú fa servir?
 nomVariable printenv.
 Sabem el printenv fa. Se'ns diu que el valor d'una variable.
 I nomVariable printenv no ens dirà molt perquè no hi ha tal variable.
 En blanc.
 Però anem a donar-li alguna cosa significativa.
 Això no és allà. Okay. Suposo que mai vaig definir això.
 Anem a comprovar el meu entorn.
 Aquest és un altre ordre mitjançant el qual vostè pot inspeccionar el seu entorn.
 Hi ha bona EDITOR d'edat, la que vam veure abans.
 Què vol fer?
 Aquí tenim una expressió backquote.
 Recordeu que aquest és el C-shell.
 Així EDITOR printenv ens donarà un valor de EDITOR. És vaig veure.
 I llavors serà establir aquest valor a la variable a, la comanda set.
 Així que ara si faig echo $ a, em surt vaig veure.
 Això no sembla massa útil.
 No obstant això, el que realment té un propòsit.
 Atès que no sabem si una variable és una variable de shell o una variable d'entorn
 mitjançant l'ús de la sintaxi d'avaluació signe del dòlar, podem utilitzar printenv
 per assegurar-se que es tracta d'una variable d'entorn.
 Així que si hi havia un editor de variables de shell, això no hauria aconseguit.
 Això només funciona amb la variable d'entorn.
 Si hi hagués una variable de shell i volia el seu valor,
 Hauria de trobar una altra manera de fer-ho.
 Una manera de fer això seria fent joc i la canonada.
 Aquest és un dels metacaracteres, caràcters especials.
 Envia la sortida del conjunt a una altra cosa.
 Anem a veure el que ens anàvem a trobar allà.
 Res. Okay. Anem a veure el que hi ha allà tots junts.
 Va ser echo_style, la que he esmentat abans. Està bé, farem això.
 Recordes que he esmentat abans, echo_style
 determina la forma en què la comanda fet s'executarà.
 bsd significa Distribució Berkeley estàndard.
 Aquest és el Berkeley Unix des de la dècada de 1970. Aquesta és una de les formes en què es fan ressò es pot executar.
 Ajust echo_style a aquest valor al TC-shell farà ressò a comportar d'aquesta manera.
 Per tal d'establir fa això, però només aconsegueix establir les variables de shell.
 No seria trobar Editor, que no és una variable de shell.
 Res.
 Així que aquesta és una forma de distingir-los.
 Però el fet que has d'anar a través d'algun comandament estrany com això
 distingir entre les variables de shell o variables d'entorn
 mostra el tipus de caràcter pràctic de la C-shell en determinats casos.
 I ara, el passat i potser menys, es tracta de les pàgines del manual.
 Aquells dels que vostès saben, l'home és el curt mandat de manual.
 Les pàgines del manual de les petxines són difícils de llegir. Són molt llarg.
 Estan organitzats d'una manera que pot fer que sigui difícil de trobar el que estàs buscant.
 Així que si estàs buscant alguna cosa amb un propòsit,
 vostè no pot saber si aquest propòsit és una variable de shell o alguna cosa més,
 pel que no pot saber on buscar.
 Vostè pot buscar diverses cadenes, però les cadenes es repeteixen sovint.
 Així que és generalment difícil de llegir.
 Ens mirem a la pàgina de manual TC-shell una mica abans de trobar la comanda eval.
 Algunes coses van més ràpid.
 Un enfocament consisteix a buscar una cadena.
 Podeu utilitzar el localitzador.
 Pager té la barra a la recerca d'una ordre o una cadena dins d'una operació de paginació.
 Home per defecte farà servir localitzadors, ja sigui més o menys.
 No sé si esteu familiaritzats amb ells, però els puc mostrar arxius a poc a poc.
 He estat utilitzant MENYS per visualitzar aquests arxius en particular que tenim aquí.
 Vostè pot buscar en l'interior hi ha.
 Pots provar a utilitzar cadenes de cerca diferents.
 També les pàgines de manual en diferents sistemes operatius poden no ser els mateixos.
 Poden ser pàgines separades per csh i tcsh.
 Són no estan en la Mac, però que podrien ser si aquestes són ordres separats.
 Si sh realment no diuen Bash, probablement seria una pàgina de manual separat.
 Alguns sistemes tenen pàgines man separades només pel C-shell ordres integrats.
 De vegades, si voleu llegir una descripció d'un comando integrat
 això és també en el camí, com eco, vostè necessita llegir la pàgina del manual sobre aquest comando en eco
 per determinar com funcionarà com una ordre integrat
 encara que no està trucant la comanda incorporat.
 Això és un inconvenient del sistema operatiu en general, no només per a les petxines,
 encara que per les petxines, en particular, les pàgines del manual són bastant llargs,
 en part perquè s'han agregat característiques útils per a ells, el que pot ser una cosa positiva.
 Okay. Hi ha alguna pregunta? Qualsevol tema que voleu que aparegui?
 Tot el rellevant aquí?
 Bé, ha estat molt agradable parlar amb tots vostès.
 Espero que tinguis alguna cosa fora d'aquest seminari
 que seran d'utilitat per a vostè en les seves activitats futures.
 [CS50.TV]