[Seminario - Cunchas Unix, Ambientes]
 [Douglas Kline - Harvard University]
 [Isto é CS50. - CS50.TV]
 

Tema de hoxe é o shell de Unix.
 Estou Douglas Kline, experto, ou polo menos bastante usuario competente, da shell.
 A shell é a interface para o usuario do sistema operativo do ordenador.
 O nome é erro, como, ao contrario de shell dun animal,
 que é dura e protectora, o invólucro do ordenador permite a comunicación.
 Entón membrana porosa probablemente sería unha metáfora mellor.
 

O escudo orixinal para Unix é o shell Bourne.
 Bourne está escrito B-O-K-R-N-E.
 Bourne foi un dos autores orixinais do Unix,
 e así que o shell é nomeado tras el.
 O nome do que shell como unha orde é simplemente sh.
 Ese é o comando que pode realizar.
 A casca comeza no inicio da sesión.
 Cando fai sesión no ordenador, o shell só comeza a funcionar para ti,
 e iso é o que leva os seus comandos.
 Pode comezar noutras ocasións tamén.
 Se abre unha ventá con ningunha outra indicación, ha comezar unha shell para ti.
 É así que é que pode ir a unha xanela e comezar a escribir comandos
 e así por diante alí aínda que non se rexistrar para esta xanela.
 Ademais, se fai un login remoto,
 a continuación, el ha comezar un shell no ordenador remoto.
 E é posible executar comandos sen un shell interactivo.
 Isto pode significar dentro da súa operación actual,
 e tamén pode significar unha operación remota.
 Podería enviar un comando a outro ordenador,
 que inclúe iniciar un shell alí.
 En realidade, ten que incluír o inicio dunha cuncha alí
 aínda que iso non é o seu propósito final.
 Cando algo comeza a ser así, iso non significa necesariamente comezar un novo shell.
 Se abre unha nova ventá, é posible dicir que para abrir un editor
 ou algún outro comando.
 Neste caso, o editor vai comezar de cero.
 Cando a edición remata, a xanela remata.
 Isto é un pouco raro, pero iso se pode facer.
 Nestes casos, non será unha cuncha.
 Polo tanto, non é necesariamente o caso de que unha xanela ou algunha aplicación será unha shell.
 

Shell analiza comandos.
 Análise significa identificar os distintos elementos e clasificalos los.
 Dentro dun comando, a cadea completa que escribe,
 haberá un ou máis comandos simples a seren executados.
 Outros elementos poden ser argumentos.
 Tamén pode haber caracteres especiais que afectan a execución dun comando.
 Poden enviar a saída noutro lugar que a pantalla
 se a orde normalmente sería envialo á pantalla.
 Pode redireccionar a entrada, que pode facer outras cousas tamén.
 Existen outros símbolos, carácteres, e así por diante.
 Análise implica detectar e interpretar as cousas.
 

Agora, se non hai máis preguntas, o que é moi probable, xa que non hai máis xente,
 imos pasar a miña seguinte páxina aquí.
 

Eu dixen anteriormente que o shell Bourne é o shell de inicio.
 Hai outros.
 Un deles é o C-shell. A orde é csh.
 O nome C-shell é só un xogo de palabras.
 Este escudo foi introducido con Berkeley Unix, a mediados da década de 1970.
 Berkeley Unix foi un acontecemento decisivo no desenvolvemento de Unix.
 Foi unha gran revolución e incluíu a introdución deste shell.
 A razón para que o xogo de palabras, C-shell,
 é que o C-shell ten algunhas características nel que semellan linguaxe C,
 cal o shell Bourne non ten -
 ou non tiña na época.
 Hai tamén o TC-shell.
 Este é un superconjunto do C-shell.
 Ten características adicionais, moitos dos cales son útiles para o uso interactivo,
 tal como recordando comandos no mecanismo de histórico,
 que eu vou describir un pouco máis tarde -
 dunha forma sinxela, modelado tras un editor.
 Tamén ten enlaces que lle permiten conectar unha cadea clave curta para unha orde máis longo.
 Non imos estar recibindo en que hoxe.
 Ten algunhas características que son útiles para a programación.
 Con todo, o C-shell non é frecuentemente utilizado para programación shell.
 Programas Shell, se xa non soubese,
 son programas que consisten en características de fachada.
 Pode realizar estes como programas.
 Vostede escribe unha morea de comandos shell nun arquivo e executar o arquivo.
 Non necesita compilalo. Esta é unha linguaxe interpretativa.
 A frase C-shell é agora ambiguo, xa que pode referirse só ao orixinal C-shell, csh,
 ou para as C-shells, incluíndo tcsh. É un pouco ambigua.
 

A shell máis tarde é o shell Korn, ksh, en homenaxe ao programador, Korn.
 Esta cuncha intentou incorporar nun shell
 as vantaxes do C-shell para uso interactivo
 eo Bourne shell para a programación.
 El foi usado como un escudo interactivo por algunhas persoas - unha minoría.
 Máis tarde, porén, houbo outra entrada, o shell bash, Bash,
 de novo un xogo de palabras, Bourne-again shell.
 É unha extensión do shell Bourne. Korn shell tamén é. Ambos son.
 Ten os mesmos obxectivos do shell Korn de amalgamando do C-shell
 e as vantaxes de Bourne shell nun shell.
 Moitas das melloras do shell Korn tamén están incluídos en Bash. Bash, con todo, ten máis e é por iso preferible.
 The Bourne-again shell eo shell Korn chámanse Bourne tipo cunchas
 porque inclúen características do Bourne shell,
 que son incompatibles nalgúns aspectos con C-cunchas.
 Hai outras cunchas, ademais daqueles, outros destinados ao uso restrinxido,
 quizais limitado a algúns comandos, quizais propósitos especializados, moitas veces non se usa.
 

Okay. Next elemento aquí.
 O Bash shell converteuse en asociada a varias formas de Linux.
 Eu non estou seguro se iso é verdade de todas as formas.
 Existen moitas formas aí e eu non usei todos eles,
 pero os que eu usei, converteuse en asociado a el.
 Ata onde eu sei, non hai nada sobre Bash
 o que o fai máis compatible con Linux
 do que calquera outra combinación de cuncha e sistema operativo.
 Eu creo que iso probablemente reflicte as inclinacións dos programadores.
 Isto converteuse en asociado con Linux é máis unha razón para preferir Bash a ksh
 sempre que as cousas tenden a ser escrito sobre el e é probable a se espallar.
 Vou che dar outras razóns para iso máis tarde.
 Scripts shell Bourne debe ser executado baixo o shell Korn ou Bash.
 Se escribir algo para o shell Bourne,
 probablemente pode executa-lo baixo ksh ou bash.
 Scripts shell Korn probablemente será executado baixo Bash, pero non podo garantir isto.
 Posteriormente, aquí, os scripts de C-shell debe ser executado baixo o TC-shell.
 O C-shell foi realmente nunca usado extensivamente para script
 desde o shell Bourne e despois as cunchas Bourne tipo eran preferibles para esa finalidade.
 Entón, o que realmente non é tan importante así.
 Hai unha morea de scripts shell Bourne que foron escritas hai moito tempo,
 antes do shell Korn ou o Bourne-again shell foron introducidas.
 Os que aínda están en uso, parte dos sistemas operativos,
 e así vai atopalos se ollar para o sistema operativo
 ou algúns paquetes de programación antigas.
 

Bash é de certa forma a tornar-se unha especie de lingua franca para sistemas operativos.
 É xa foi estendido para Windows e VMS.
 VMS, no caso de que non sabe, é un sistema operativo propietario
 de Digital Equipment Corporation, que aínda está en uso, en gran parte, nos bastidores.
 E se el vai estar en execución en varios sistemas operativos diferentes,
 probabelmente as persoas tenden a ir a el.
 Pero este desenvolvemento é relativamente recente.
 É só o comezo, entón eu non podo prever se isto vai pasar a ser realmente este tipo de lingua franca.
 Ademais, porque camiños de arquivo e bibliotecas difiren
 entre estes sistemas operativos distintos,
 pode non ser capaz de escribir un guión Bash nun sistema operativo
 e logo, executa-lo noutro.
 Vostede debe ser capaz de movelo entre diferentes Unix, Linux
 Sistemas operativos Mac OS, pero non necesariamente para Windows ou VMS.
 Pode ter que cambiar as descricións do ficheiro Pathname,
 e algunhas bibliotecas pode ser doutro xeito,
 o que pode afectar a forma que algúns comandos funcionan
 ou como eles procesan argumentos e afíns.
 Ademais, outra precaución aquí é que non hai ningunha garantía
 que todas as distintas cunchas que eu mencionen - Bourne shell, C-shell,
 TC-shell, Korn, Bourne-again shell - estarán dispoñibles en calquera Unix
 ou Linux ou Mac OS.
 Eles simplemente non poden estar alí.
 Esa é unha das precaucións aquí.
 É unha limitación infeliz aquí sempre que quere que as cousas funcionen en todas as partes,
 pero, desgraciadamente, non se pode contar con iso.
 

Okay. Next one aquí.
 Imos dicir que quere escribir un shell script,
 un programa que consta de comandos shell.
 Vostede escribe os seus mandos, poñelos nun arquivo e executar o arquivo.
 E se queres incluír argumentos?
 No caso de operacións de fachada, os argumentos son chamados parámetros ou parámetros posicionais
 e eles van ser chamados por un sinal de dólar e numeral, $ 1, $ 2.
 Polo tanto, se a escritura ten ese nome, o meu primeiro argumento pode ser argumento 1
 e meu segundo se pode argumento 2,
 e dentro do meu guión, se eu queira referirse a esas cousas -
 imos borrar iso dende que eu realmente non estou indo a executa-lo -
 dentro do meu script que eu poida ter un dólar para referirse a arg1,
 $ 2, que vai saír desa forma, arg2.
 Entón, eses símbolos están dispoñibles para referirse aos argumentos,
 e os que se aplica a todas as cunchas.
 Ademais, existen outros caracteres.
 $ * Refírese a toda a lista de argumentos, todos eles.
 $ # Refírese ao número de argumentos.
 Unha vez máis, isto é aplicable a todas as cunchas.
 Estes símbolos, * e #, pode ser usado con estes significados noutros lugares tamén.
 Non vai ter para iso.
 

Liña especificador Shell. ¿Que é iso?
 Digamos que teña escrito un guión e é por unha cuncha especial e quere executalo.
 Como vostede sabe o que desembolsar o seu sistema operativo vai empregar para executar o script?
 Nun punto, podería supoñer que vai executa-lo no shell Bourne
 se non dicir o contrario,
 pero a xente non están a escribir scripts en Bourne Shell que moito máis
 e non pode mesmo contar con iso.
 Polo tanto, temos aquí unha liña de especificador shell aquí. Isto especifica Bash.
 Nótese que especifica-la no camiño, / bin / bash.
 Se un ordenador ten o shell bash, pero non no directorio bin, / sbin, iso non vai funcionar.
 Ese é outro cualificado, outro coidado aquí.
 O sinal de libra é o carácter de comentario de liña.
 Isto é aplicable a todas as cunchas.
 O caso particular aquí, #! no inicio dun guión, é un caso especial.
 Isto especifica o shell en que para realizar o guión.
 Como eu estaba dicindo, pode non ser o mesmo lugar / bin.
 Ademais, hai outra cousa aquí.
 Se usar só o signo de libra, sen punto de admiración e camiño,
 que debe indicar un C-shell.
 Sen embargo, eu non recomendo facelo porque eu non son capaz de garantir
 que iso vai funcionar sempre.
 Se quere un C-shell, sería mellor dicir así.
 Entón, hai algo un pouco confuso aquí.
 Se usar unha liña de shell especificador, como / bin / bash
 e que a casca non está dispoñible alí,
 non hai tal cousa como / bin / bash nese ordenador particular,
 ou porque non ten Bash ou porque está nun lugar diferente,
 recibirá un erro informando que a escritura que correu non existe.
 E, por suposto, existe a escritura, de xeito que a mensaxe de erro é confuso.
 A razón pola que o sistema operativo dálle ese erro
 ou, máis precisamente, que o shell interactivo no que está a executar o que dá ese erro,
 é que relata a orde utilizado, que é o nome do script.
 Este comando efectivamente chamado shell co nome do script.
 É alí onde comeza a mensaxe de erro confuso.
 Outro xeito de chamar script shell
 é especificando o shell na liña de comandos, como aquí.
 Este é un comando. Isto di Bash realizar e, a continuación, executar o meu script en Bash.
 Isto vai ter precedencia sobre unha liña de especificador,
 e este ten a característica de permitir que fornecer para camiños distintos.
 Se acaba de dar unha orde, o sistema operativo pode ollar para a orde
 en varios lugares.
 Se está dispoñible, debe atopalo.
 O ordenador vai atopar Bash onde está situado e executalo,
 para que non precisa, entón, a preocuparse onde atopa-lo.
 Hai potencialmente outras preocupacións aquí,
 como se fai máis que unha versión do Bash, que é posible, aínda que improbable.
 Entón, iso é outra forma de xestionar estas cousas.
 Liñas de especificador pode chamar calquera shell.
 Eles poden chamar outros de cunchas cousas.
 Exemplos que teño aquí son sed, que é o editor de fluxo;
 awk, que é unha linguaxe de procesamento estándar;
 e Perl, unha linguaxe de script moi altamente desenvolvida.
 Se pór unha liña especificador indicando un destes programas, en principio,
 ha directamente ao programa, en vez de iniciar unha shell.
 Estes programas teñen límites para as súas habilidades.
 Perl é moi capaz. Sed é un editor. Pode facer cousas ademais de simplemente editando.
 Pero pode ser difícil de programa que.
 Ademais, o paso de argumentos e outras cousas para a escritura é imposible ou confuso.
 Entón, neses casos, con awk ou sed, é, polo menos na miña experiencia,
 preferible escribir un shell script e chamada awk ou sed do script shell
 ao contrario de chamar awk ou sed como a liña de especificador de script.
 Perl é unha linguaxe altamente diversificada, como dixen.
 Non pode executar comandos interactivos en perl,
 o que significa que non pode probar pezas de scripts que está en desenvolvemento
 , Executando-os de forma interactiva.
 Con todo, é unha linguaxe moi capaz
 e chegou a ser unha ferramenta moi utilizada.
 Isto é só un pouco máis de unha observación entre parénteses sobre as liñas de especificador.
 

En todas ou a maioría das formas de Linux - unha vez máis, eu non podo estar seguro de que é todo -
 e en Mac OS, se escribir csh comeza tcsh,
 e se insire sh comeza bash.
 Estaban tratando alí para darlle as versións máis avanzadas deses cunchas,
 pero isto pode ser confuso.
 Se escribir un guión utilizando tcsh ou Bash presenta ao chamar csh ou sh
 e probe executalo en un ordenador que non ten tcsh ou Bash,
 pode obter algúns erros se hai comandos alí
 que esas cunchas non recoñece.
 Ademais, pode chamar a súa cuncha no seu computador local
 chamando-o como sh ou csh e logo, obter as cunchas máis avanzados.
 Pode até non pensar no feito de que está a usar o shell máis avanzado.
 Polo tanto, esta é unha trampa potencial.
 Como é establecido que se insire sh comeza Bash,
 Se insire csh comeza tsch?
 Hai cousas nestes ordenadores chamados enlaces
 que pode conectarse a nomes de ficheiro para referirse á mesma cousa.
 El quere pode ser de 2 nomes para o mesmo ficheiro ou un ficheiro cuxa finalidade é para referirse a outro ficheiro.
 Son chamados de ligazóns físicos e simbólicos. Non imos estar indo a máis que hoxe.
 Tamén pode haber arquivos separados - un ficheiro sh, 1 arquivo Bash -
 pero ambos executar Bash.
 Despois, hai outro calificador aquí.
 Se está conectando a un destes shells por un nome,
 pode pensar que quere obter a mesma funcionalidade que chamala por outro nome. Ben, iso realmente non é necesariamente verdade.
 Estes comandos poden examinar o nome polo cal eles foron chamados
 e poden, en base a que o nome, se comportan de forma distinta.
 Pode haber problemas de tentar obedecer a un estándar.
 Algúns de vostedes poden ter oído falar do estándar POSIX ou doutra,
 quizais outros recursos.
 Isto pode ser seleccionado, por veces, a través de argumentos de liña de comandos
 ou definindo variables shell.
 Chamando-o como sh ou bash realmente pode levar a unha execución distinta
 aínda que sexa o mesmo ficheiro que está executando.
 Outra cousa a considerar é que, mesmo se outro ordenador ten tcsh ou Bash,
 se eles non están ligados como están no seu computador local
 se ten un ordenador local Linux ou Mac OS,
 logo de novo vai ter o shell que chama sh ou csh, non o que pode preferir.
 A cadea de Bourne shell ten melloras menor que aqueles en Bash
 pero pasado os do shell Bourne orixinal.
 Como resultado diso, ata o shell actual Bourne, sh,
 aínda que non é Bash, aseméllase á linguaxe C máis que o C-shell fai.
 Isto non era certo cando o C-shell foi creada por primeira vez, pero desenvolveu-se desta forma.
 Pode notar aquí que todos estes nomes de fachada, excepto para o shell Bourne
 ten algo para indicar cal shell que son - csh, o bash -
 pero o shell Bourne é só sh.
 Por que? Ese foi o shell de orixe.
 Foi o Shell de entón, non unha cuncha,
 e unha vez que era a casca, non había ningunha razón para distinguilo lo doutro shell.
 Entón é por iso que ten ese nome e aínda o fai.
 

Este top aquí é unha liña de unha base de datos de contrasinal dunha conta que eu teño alí
 noutro ordenador.
 Vou tentar obter ese nome para que poida ver que parte ao final, o shell.
 A base de datos de contrasinal detén as características de login para todos os usuarios.
 En principio é o nome de usuario, que se pode ver os últimos 2 cartas de meu momento.
 Os campos aquí están separados por dous puntos.
 O último campo, como podes ver, é bin / tcsh, o shell.
 Ese é o especificador de shell.
 Hai algo interesante aquí.
 Cando Unix foi desenvolvido en primeiro lugar, había só un shell,
 entón non había opción alí.
 Entón, por que eles permiten que un campo na base de datos de contrasinal para especificar un shell?
 Eu non sei, pero é bo que eles fixeron.
 É un pouco difícil de facer cambios no formato de base de datos de contrasinal
 porque moitos programas refírense a seu formato
 e tería que ser reescrito.
 É un desenvolvemento feliz ou fortuíto que incluíron nese campo.
 Este tipo de unha liña do ficheiro de contrasinal é usado en todos os ordenadores Unix e Linux, tanto como sei.
 O Mac ten o seu propio sistema.
 El realmente ten un ficheiro de contrasinais coas liñas en que formato,
 pero iso non é o lugar onde as características do usuario son definidos.
 Outra observación entre parénteses alí.
 

Se está chamando dunha cuncha, pode chamalo como un sub-shell de súas cunchas existentes.
 Entón, se eu ir aquí, imos nos librar destas cousas.
 Aquí estou eu no C-shell.
 Esta variable, que identifica con precisión o meu escudo,
 en realidade, non sempre é unha forma fiable de determinar o que desembolsar está executando,
 pero neste caso é.
 E se eu simplemente escribir -
 Agora estou en Bash.
 Algunhas cousas van ser os mesmos. ls dime os meus mandamentos.
 Se eu a suspender volver para o meu C-shell, sl, mesmo. Non?
 fg, primeiro plano, volver para o meu shell Bash.
 pwd, directorio actual, ao seu C-shell.
 pwd, directorio diferente - en realidade non é un directorio diferente neste caso.
 É o mesmo directorio.
 Imos dicir que quero chamar un comando aquí: onde ls.
 O que isto fai?
 Dime onde a orde ls,
 o que me dá unha listaxe de directorio, está situado na ls.
 Imos voltar Bash shell. Imos tentar o mesmo.
 Hmm, interesante alí, onde: comando non atopado.
 Por que isto?
 A orde onde está construído para o C-shell.
 Este non é un comando que ten que ser lido á memoria doutro lugar e executado.
 O C-shell executa-lo, trasladando a execución de parte do seu propio código
 e non é o shell Bash.
 Entón, Bash, non tendo tal comando integrado, busca por el, non atopalo,
 e teremos un erro.
 Polo tanto, temos un shell bash executándose nunha C-shell, e chamamos iso de un sub-shell.
 E no caso de que vostede está curioso, Bash shell ten a súa propia forma de localizar os comandos.
 hash refírese ao feito de que se pode executar máis rápido,
 sendo atopados máis rapidamente.
 Esa é unha das melloras construídas en algunhas destas cunchas.
 

Bourne tipo cunchas son os preferidos para a programación.
 Teñen estruturas de control como loops, instrucións condicionais,
 o tipo de comandos que pode usar en linguaxes de programación como C
 ou calquera outra lingua. Pode que a programación en Java ou calquera outra cousa.
 Shells ter os demais.
 As cunchas do tipo Bourne, particularmente Bash, teñen máis
 e eles están deseñados con maior flexibilidade.
 O Bash shell ten arrays. The Bourne shell orixinal non fai.
 Así que pode ser considerablemente vantaxoso para a programación.
 O C-shell realmente ten matrices, pero non ten unha morea deses outros recursos. As cunchas do tipo Bourne ha executar máis rápido
 se eles non teñen os elementos que se destinan a utilización interactiva.
 Leva as cousas con un propósito, o que leva-los a outra finalidade.
 Hai que trade-off alí.
 Estes recursos que están destinados para uso interactivo
 Realmente son de pouco ou ningún uso de scripts.
 É posíbel usar un sub-shell interactivo así como o que eu comece alí
 para probar as ordes que pretende empregar nun guión.
 Iso é o que non pode facer con Perl. Podes facelo coas cunchas.
 Mesmo as estruturas como loops e así por diante pode ser executado de forma interactiva.
 Son ocasionalmente útil para realizar de forma interactiva,
 pero é máis probable que está a usar para desenvolver un guión.
 

Aliases.
 Este vai ser sobre o C-shell.
 Mecanismo de Historia, onde volver aos comandos anteriores
 ou partes deles que xa teña executado.
 Unha vez máis, sobre a C-shell, o shell Bourne e shell Korn ten esas cousas,
 pero eu non vou entrar na deles.
 Entón, aquí están algúns alias útiles que eu teño.
 No canto de escribir ls - é unha orde común -
 escriba l e salva-se un personaxe.
 ls con varias opcións, as obras.
 Nótese que estas definicións teñen comiñas en torno a eles.
 Nestes casos, as citas non son necesarias.
 Se pode establecer os alias sen as comiñas, el continuaría traballando.
 Son recomendados.
 Hai situacións nas que non se pode usar a citación
 porque quere que algo aconteza, que a cita impediría.
 Ás veces, pode citar parte da definición, pero non todo isto.
 Tamén é xeralmente recomendado o uso de aspas en vez de comiñas dobres.
 Comiñas ter efectos sobre a configuración das variables,
 particularmente levándoos a ser avaliada en vez de impedir isto.
 Por que iríamos querer parar a avaliación?
 E como citas facelo por nós?
 

Aquí está unha orde que pode considerar interesante.
 'Ls g *'
 g *, como probablemente sabe, é unha expresión comodín
 para todos os nomes de ficheiros que comezan con g.
 Se eu escribir nun comando ls g *, eu vou incorporarse unha lista de todos os nomes no meu directorio actual.
 Se eu definir ese feito como é aquí coas citas,
 ha executar este comando no directorio actual onde está executando-o.
 Pero se realizar a definición de alias sen as comiñas,
 ha avaliar o comodín g * cando se executa este comando de definición.
 Así, a definición do alias será ls seguido pola lista de ficheiros no directorio
 en que a orde alias corre,
 independentemente de onde o que realmente quere executar o comando.
 Este non é de gran utilidade, e as comiñas previr a avaliación do asterisco.
 Entón acaba de obter a definición de ser ls g *.
 Entón, cando executar o alias, LGS, el pon iso.
 Agora non hai citas, e ha avaliar o asterisco cando executar o comando alias.
 Entón, iso é unha cousa.
 Comiñas tería ese mesmo efecto aquí,
 pero hai outros casos en que as comiñas dobres non funcionan tan ben.
 

Aquí é outra.
 Podes saber o comando grep.
 A orde grep se pode usar para dixitalizar un arquivo para as liñas que teñen determinadas secuencias.
 Entón, imos pasar por riba aquí e eu vou saír da miña cuncha Bourne.
 Okay. Aquí está un arquivo.
 Imos dicir que é cordas abc grep. Aquí está.
 Se eu fai zddd grep, recibín nada. Okay.
 Entón, el atopa unha corda, el relata, que non encontra, non relato-lo.
 El produce calquera liña que ten esa corda nel.
 Hai todo tipo de opcións aquí que pode atopar na documentación.
 Aquí está un xeito de facelo.
 E este aquí, de feito grabc 'grep abc'?
 Isto incluirá un argumento cando o alias está definido.
 Entón, se eu facer iso aquí, agora se eu fai grabc,
 agora o alias inclúe máis que o simple comando. Tamén ten o argumento.
 Ata o momento que funciona.
 Eu teño un outro comando aquí, un regalo, entón eses son diferentes cordas en alí
 e amosar que iso non atopar nada alí, xa que non corresponde.
 

E se eu queira incluír na definición de alias do ficheiro que eu vou buscar
 e quero dar como un argumento para o alias a corda que estou buscando?
 Podería querer dicir abc como argumento para o meu apelido,
 pero o alias xa determinado arquivo.
 E é aí onde esta expresión vén dentro
 Teña en conta aquí temos grep como antes.
 Temos o ficheiro aquí, strings.
 \ ^!, Tipo dunha expresión estraña, creo que, se aínda non viu iso antes.
 Punto de exclamación forma parte do mecanismo de historia C-shell.
 Pode chamar comandos anteriores, pode lembrar argumentos para as ordes e así por diante.
 O mecanismo de historial se utiliza como parte serrilhado.
 Se especifica unha liña despois do signo de admiración, ha referirse a esa liña na lista do historial,
 que non será metendo agora, xa que é un tema completamente diferente.
 É posíbel especificar parte dunha liña.
 Entón! 03:02 sería o segundo argumento do número de orde 3.
 O acento circunflexo aquí nesta expresión representa o primeiro argumento. Se non darlle unha indicación de cal comando está referíndose,
 refírese ao mando inmediato anterior,
 eo acento circunflexo é un símbolo para o primeiro argumento.
 Porque é o acento circunflexo e non o número, non usar o colon,
 así! ^ significa que o primeiro argumento para a orde anterior.
 Un pouco confuso aquí.
 Neste caso, cando usa isto como unha definición de alias,
 a referencia historia remite para as ordes de que o alias se usa.
 Entón, iso vai volver un comando como unha operación de historia,
 senón como unha operación apelido refírese ao mando en que escribe,
 dicir, grstrings_file.
 Temos as comiñas aquí dentro. Cal é a barra invertida para?
 Neste caso, como noutros lugares, nós non queremos para realizar o mecanismo de historial
 mentres que a definición do alias.
 Se non tivésemos a barra invertida alí, o shell puxaria o primeiro argumento
 da orde dereita antes que foi esta orde apelido, o que nós non queremos.
 Queremos que este sexa construído para o comando alias para chamar un argumento máis tarde.
 As aspas non escapar un punto de admiración, a referencia historia.
 Quizais coñeza a expresión fuga significa cambiar o sentido da cousa.
 Neste caso, iso significa algo para deixar de ter un significado especial.
 Significado especial desde o punto de exclamación é historia.
 Fuxa e non ten ese significado.
 Citas non fagas iso; barra invertida fai.
 Entón, nós estamos realmente a usar dous niveis de escapar aquí.
 Vou pasar este comando para a outra fiestra sen escriba-lo
 usar estas operacións de edición, que pode considerar útil.
 Outra cousa aquí que eu vou te amosar.
 Se acaba de escribir apelido sen argumentos, dille a todos os seus argumentos.
 Iso é unha chea de apelidos eu xa tiña aquí
 ademais dos que eu teño usado aquí hoxe.
 Pero se eu simplemente escribir o nome dun alias, el me di o que significa.
 Nótese que as citas sumiron ea barra invertida foise.
 Esta cadea aquí é o resultado desa definición alias,
 e agora ten só! ^ nel.
 Isto vai mirar nas cordas de ficheiro para calquera cousa.
 Entón, se eu fai cordas grstrings_file, eu non darlle algo para mirar para alí,
 pero está mirando en cordas.
 Non atopou a palabra cordas nas cordas de arquivo, pero non atopa ABC.
 E non creo que.
 Entón, aquí estamos dando un argumento que bate na definición do alias,
 que está inserida nela.
 É onde esta expresión vén.
 Podes empregar máis que 1.
 O acento circunflexo é un símbolo para o primeiro argumento.
 Se quere usar un segundo argumento, vostede, entón, dicir: 2.
 Non hai ningún símbolo especial para o segundo argumento.
 E por que está a usar un numeral, que tería que usar o colon.
 Non é, no entanto, unha outra opción aquí.
 O sinal de dólar representa o último argumento.
 E por que se trata dun símbolo, pode omitir o colon.
 Polo tanto, sería o último argumento na lista.
 E hai tamén aquel.
 Asterisk significa que todos, polo que esta é a lista de argumentos completa,
 e, de novo, pode omitir o colonos, porque non é un numeral.
 Espero que estea todo observando todo isto.
 

O mecanismo historia pode volver para as liñas anteriores na lista de histórico.
 Podes facelo nunha definición de alias.
 Nunca vin este feito.
 Tería o efecto de tirar as ordes anteriores da lista do historial
 cando executa o alias, o que podería ser diferentes comandos
 dependendo de cando e onde executalo.
 É concebible que pode querer saír desta referencia
 só para ver o que un comando anterior era.
 Eu nunca vin isto acontecer.
 Supoño que alguén pode querer, pero iso é moi improbable.
 Hai outra cousa aquí.
 Se usar esta referencia do tipo da historia,
 logo se usan só os argumentos para os que existe unha tal referencia.
 Se vostede ten unha definición de alias que non usar unha referencia do tipo da historia,
 se só se fai o inicio da orde
 e ten outros argumentos, entón calquera cousa que escriba despois que
 será engadido ao comando.
 Neste caso, o exemplo que eu só dei alí, foi utilizado o primeiro argumento;
 Non usamos calquera outro.
 Se outros argumentos fora dado na liña de comandos, eles non serían utilizados.
 Entón, se usa a referencia historia en todo, entón ten que usalo para obter calquera argumento.
 

Hai outra cousa aquí eu só quero mencionar, en parte, entre parénteses,
 ou sexa, que este mecanismo de historia, co punto de exclamación
 vai volver para o C-shell de orixe.
 O tcsh introduciu operacións de historia
 que utilizan os tipos de ordes e cordas dos editores,
 ou Emacs ou vin.
 A miña opinión persoal é Emacs é moito máis doado de usar para esa finalidade
 mesmo se usa o vin para a edición regular.
 Existen varios comandos do Emacs, que agora están adaptados para a historia.
 Control P recibe a liña anterior na lista do historial.
 Outra Control P chegará o antes diso.
 A frecha para arriba fai o mesmo.
 Control N obtén o seguinte comando que xa teña rodado atrás nalgúns aspectos. Frecha para abaixo fai iso tamén.
 Pode mover á esquerda a dereita coas frechas e varias outras cousas.
 Isto pode facer uso do mecanismo de historia
 moito máis fácil do que usar a sintaxe punto de exclamación,
 pero non vai usar isto nunha definición de alias.
 Nós imos pasar por riba de que outra hora.
 

Variables.
 Vostede sabe o que son variables en linguaxes de programación.
 As cunchas de te-los tamén.
 O C-shell usa o comando set para asignar variables,
 de xeito que define a variable dun valor de b -
 como dixen, unha definición inútil, pero unha ilustración de como este é utilizado.
 A orde set creará unha variable se aínda non existe.
 Os parámetros posicionais para shell scripts poden considerarse variables,
 pero o uso deles e as normas para eles son un pouco diferentes.
 Non pode asignar un valor a US $ 1 no curso dun guión.
 Vostede tería que definir unha nova variable para o efecto, algúns de vostedes querían.
 Escriba set sen argumentos e terá unha lista de todas as variables actualmente definidas.
 E imos para o meu outro shell aquí para ver o que teremos que facer.
 Unha lista moi longa alí, non?
 Ir a arriba un pouco. Olle para todo isto.
 Algunhas destas cousas son definidas automaticamente pola shell.
 O shell crea a variable e dálle un valor.
 Algúns deles son definidos pola casca, pero, a continuación, redefinida polo usuario
 segundo as súas preferencias.
 E algúns deles son creados polo usuario de acordo co que está a facer aquel día.
 Isto é só un conxunto sen argumentos.
 Hai unha característica raro aquí desa cousa.
 Non ten que ser tanto sen espazos entre signo igual eo nome da variable
 eo valor ou espazos en ambos os dous lados do signo igual,
 como neste.
 Iso non vai funcionar, e que realmente é un comando válido
 pero non vai facer o que quere.
 Este comando funcionará, porque se acaba de dicir e establecer un nome de variable
 sen signo igual ou conxunto e un nome de variable cun signo igual e ningún valor,
 que vai definir a variable a un valor nulo.
 Polo tanto, definir a = é un comando válido.
 A orde set pode definir máis dunha variable na mesma liña.
 Polo tanto, esta orde aquí ten o efecto de establecer tanto a eb para valores nulos.
 Probablemente non é o que quere.
 Este aquí, mencionado anteriormente, levará a un erro
 porque = b non é unha expresión válida.
 Un nome de variable non pode comezar co sinal de igual a igual.
 E hai estas cousas aquí.
 Os dous puntos foron usados ​​para seleccionar os argumentos de liña de historia,
 e poden ser usados ​​- e eu non quería entrar en diante - para modificar as cousas.
 Eles poden ser usados ​​para modificar as variables do escudo.
 Este aquí, $ a, ten un valor.
 : R vai despegar unha extensión.
 Unha extensión será nada tras un punto,
 un punto e calquera cousa que se lle segue, ao final dun ficheiro,
 só ao final da lista despois da última barra.
 Entón, eu teño aquí.
 unha é que. Que vai caer o. O.
 Se non hai ningunha extensión, só os camiños despois da última barra, non terá ningún efecto.
 a: h, esa expresión variable, vai despegar o último elemento dunha lista de directorios,
 de novo, só despois da última barra.
 Entón, / a / b / c convértese en / a / b,
 pero este é alterado porque o elemento despois a lista é nulo.
 Aquí hai algo que tamén quero salientar.
 Estes cualificados non buscar a existencia destes ficheiros.
 Miran só para cadeas.
 Estes destina-se a manexar nomes de ficheiros, nomes de camiño,
 pero poden ser usados ​​en calquera secuencia, mesmo se non é un nome de arquivo.
 E eles non miran para a existencia,
 polo que, se non hai tal ficheiro, / a / b / c, que aínda funciona.
 Se é de algunha utilidade é outra cuestión, pero aínda funciona.
 As variables son diferentes no Bourne. Nós imos chegar a iso máis tarde.
 Sinal de dólar se pode escapar así como o punto de exclamación e un asterisco.
 Sinal de dólar pode ser precedidos por unha barra invertida ou as aspas.
 Comiñas dobres teñen o efecto estraño en todas as cunchas
 de forzar a avaliación dun sinal de dólar expresión variable.
 Entón, se está a ser escapou dun xeito, as comiñas dobres pode ter o efecto
 de facer que ser avaliada de calquera maneira.
 Isto é un pouco confuso.
 Se hai varios niveis de fuga, como aspas dentro de comiñas dobres
 ou comiñas dobres dentro aspas, ten que probar a ver que ocorrerá
 a unha variable, se está a usar un.
 Estas dúas situacións - o dobre dentro de interior único, single do dúo -
 non necesariamente darlle o mesmo resultado.
 As variables de ambiente, variables C-shell conectados.
 As variables de ambiente tamén son variables en C-shell,
 e eles tamén son variables noutros shells tamén.
 O C-shell, son conxuntos distintos.
 As cousas que eu estaba dicindo antes son sobre variables shell.
 As variables de ambiente son un conxunto distinto de variables
 coa excepción dunha serie de variables que chamamos variables ligadas,
 que son moi importantes e nós imos entrar en quen máis tarde.
 As variables de ambiente son pasadas automaticamente
 de cunchas ou comandos que son executados a partir da súa cuncha. As outras cousas que non son. As variables shell, os apelidos non son. As variables de ambiente son.
 É por iso que nós os chamamos variables de ambiente,
 a idea é que o ambiente supera só o seu shell actual.
 Poden ser utilizados para definir as cousas para comandos.
 Aquí é un exemplo. Impresora, LPDEST.
 Ambas variables poden definir unha impresora que un comando vai empregar para imprimir as cousas.
 Se ten varias impresoras arredor, pode querer poñer o que lle gusta.
 A razón pola que temos 2 variables é que diferentes conxuntos de comandos foron escritos
 usar estas distintas variables.
 Pode darlles valores diferentes.
 O máis probable é que vai dar a ambos o mesmo valor.
 Estas cousas funcionan porque os comandos que fan a impresión
 foron programados para examinar os valores destas variables.
 Se un programa non foron escritas desta forma, se fose escrito para facer outra cousa,
 a variable sería irrelevante.
 Así, o sistema operativo non está mirando para estas variables
 cada vez que se referir a unha impresora.
 Unha orde que fai impresión é ollar para estas variables se é programado desta forma.
 Estas variables son frecuentemente definidos nos seus arquivos de inicio
 pero non necesariamente.
 Pode define-los na liña de comandos.
 Poden ser definidos nun comando.
 Unha orde que executa algo pode ter a súa propia selección de variables -
 variables que son exclusivas dun paquete de software específico, por exemplo.
 Eles van ser definidas cando realizar este paquete.
 Como esas variables pasados ​​para un sub-shell?
 Cando un sub-shell está escrito, non escribe para esta área.
 A área da sub-shell que se dedica a variables de ambiente
 non é escrito polo sub-shell, que está escrito por copia.
 Cando fai unha orde común, como os comandos para imprimir ou o que sexa,
 comezan coa creación dun novo shell.
 O shell crea un shell e, a continuación, substitúe parte dela
 coa orde que está executando, o que é un pouco confuso,
 pero é así que estes comandos obter as variables de ambiente
 que, logo referirse a máis tarde.
 A orde aquí para definir o setenv variable.
 É así que definir. É 3 elementos: setenv, variable, valor.
 Se simplemente setenv sen argumentos, o que gañou?
 Unha lista de todas as variables.
 De novo, é unha lista longa e agradable e, neste caso, como nos outros,
 estas variables defínense en gran parte pola miña operación de rexistro polo propio shell
 e non por calquera cousa que eu fixen.
 Hai outro comando aquí, printenv.
 Isto tamén amosa o medio ambiente.
 Teña en conta esta última cousa aquí, editor = vin.
 Isto di que, se está a usar algo que chama un editor
 e eu non especificar un editor e el me permite a elección, me pode dar vin.
 E se eu fai EDITOR printenv? Dime o que é.
 Ben antes diso, houbo unha variable, MENOS.
 Estas son as súas opcións defaults cando executo a orde less,
 que exhibe os arquivos.
 Entón, se eu fai iso, printenv pode levar de 1 ou 0 argumento argumentos,
 non máis que 1.
 Hai outros comandos tamén, pero non imos entrar en todo o que hoxe.
 Lembre que foron os modificadores para as variables de shell como: h,
 que vai caer o último elemento dun camiño,
 ou: r, que vai caer unha extensión.
 Os que agora se aplican ás variables de ambiente tamén. Eles non usaron.
 Ela adoitaba ser que non podería ser modificado. Agora poden ser.
 É un dos avances coa evolución das cunchas ao longo dos anos.
 Estaba dicindo que as cunchas, como parte dos ambientes
 e variables shell no C-shell son, con algunhas excepcións, conxuntos distintos.
 Pode establecer unha variable de ambiente e unha variable de shell co mesmo nome.
 Eles serán variables diferentes, poden ter valores diferentes.
 Cambiar o valor dun non vai cambiar o valor do outro.
 Estas variables son todos avaliados co cifrão - $ a, $ o que quere.
 Así que se tes iso? Vostede sabe cal deles pode?
 Nos meus probas eu teño a variable shell,
 pero isto non é documentado e non pode contar con iso.
 Entón eu lle pregunto, é a creación de variables shell e medio ambiente
 cos mesmos nomes unha boa idea? Non Todo ben.
 Que son esas as principais excepcións en que as variables do ambiente e shell
 están ligados un ao outro?
 Existen estes 4.
 Carta Capital variable de ambiente TERM,
 desembolsar variable termo en letras pequenas, o tipo de emulación de terminal.
 Eu só vou pasar por riba aquí e eu vou facer eco, un comando utilidade aquí,
 $ $ TERM prazo. E alí.
 xterm é un tipo de terminal para fiestras exhibidas no Sistema X Window.
 xterm-cor é unha variación do que a que permite que as cores distintas.
 Por que é que imos configurar isto? ¿Que é iso bo?
 Comandos que reorganizar a pantalla como o editor
 enviar secuencias particulares, chamados de secuencias de escape,
 a un terminal ou unha xanela para reorganizar-lo e así por diante.
 Estas secuencias son diferentes para os diferentes tipos de terminais.
 Isto di-lle que usar.
 Ás veces, hai problemas alí. Pode querer cambiar isto.
 Se as cousas non están funcionando, por veces, o tipo de terminal está configurado mal,
 pode ser capaz de resolve-lo, redefinindo a variable prazo.
 Nestes casos, o cambio dunha variable, a variable de ambiente ou a variable de shell,
 debe cambiar o outro.
 Eu descubrín a través da experiencia que o cambio de prazo en maiúsculas
 non sempre cambiar shell variable termo en letras pequenas.
 Este é un erro.
 Eu non sei se isto é sempre certo. Na maioría das veces iso non é verdade, pero pode ser.
 Entón, se fai un cambio, pode comprobar iso.
 Non é sempre que teña que cambiar ese valor, pero de cando en vez fai.
 USUARIO variable de ambiente.
 Unha vez máis, variable de ambiente en letras maiúsculas, a Shell variable en letras pequenas.
 Este é o seu nome de usuario.
 É só en circunstancias moi excepcionais
 que quere cambiar isto.
 O seu nome de usuario é outra persoa, pode lanzar todo tipo de cousas.
 Directorio persoal, o directorio persoal do usuario.
 De novo, non quere cambiar isto.
 Repare en todos estes casos e ese que estamos a piques de cubrir, a variable de camiño,
 variable de ambiente é en maiúsculas ea variable shell conectado é en letras pequenas.
 Se cambia un, ten que cambiar a outro.
 Este tipo de conexión non pode ser establecida como non pode conectar dúas variables,
 Ademais destas catro, ea conexión destas variables non se pode desfacer,
 non pode separa-los.
 Entón, eses catro pares de variables son vinculadas.
 Eles sempre serán. Ningún outro será.
 Ademais, sería posible a creación de variables cos mesmos nomes
 dos tipos opostos.
 Podería facer un termo variable shell en letras pequenas
 ou unha variábel de entorno TERM en letras maiúsculas.
 Estas variables sería independente destas variables binarias
 e serían independentes unha da outra.
 Eu non podo imaxinar por que faría iso a menos que queira confundir a xente.
 Este aquí, variable de camiño, este é un moi importante.
 Outra cousa é que non pode haber casos
 de variables con nomes vinculados similares que non están ligados uns ós outros.
 Non pode haber variables, Shell e Shell, en letras maiúsculas e minúsculas.
 Con base nese nome, non sabe se esta variable é unha variable shell
 ou unha variable de ambiente, e eles non están ligados un ao outro.
 Entón, este tipo de parellas de nomes non implica variables ligadas.
 A variable de camiño, que eu estaba mostrando antes,
 é unha lista de nomes de camiño no que o shell busca por comandos.
 Imos acabar coa esta xanela aquí e imos facer echo $ PATH, maiúsculas -
 variable de ambiente - echo $ camiño, letras pequenas - Shell variable.
 Teña en conta que a lista de directorios é o mesmo. Estes están vinculados.
 Cambia un, cambiar o outro.
 Na variable de ambiente os elementos están separados por dous puntos. Teña en conta que.
 As variables shell son separados por espazos.
 Esta variable de ambiente é unha única secuencia.
 A variable de shell é unha matriz.
 The Bourne shell non ten arrays.
 Bash fai, pero iso xa é unha parte fixa da shell.
 Esta é unha secuencia única e non un array.
 O C-shell sempre tivo matrices.
 As matrices son moito máis fáciles de traballar.
 Pode referirse a partes del.
 $ Camiño Entón echo [1] e eu recibín / usr / bin, o primeiro elemento.
 Unha vez máis, lembre-se sinal de dólar representa o último elemento da lista de histórico.
 Qué acontece alí? Tentou atopar cifrão como un símbolo variable.
 Eu escapar. Oops. Non levaría o que quere.
 Algunhas destas cousas non funcionan tan ben.
 Quizais nós imos deixar isto para fóra.
 Asterisk refírese a cousa toda, pero é o que gañou se non especifica un elemento.
 Outra forma que as variables de matriz poden ser manipuladas,
 número de elementos de alí, 7 elementos.
 Aquí poñemos o sinal de libra antes do nome da variable.
 Aquí está un máis. Engade un punto de interrogación alí.
 Isto é un valor lóxico. Isto indica que a variable existe.
 É outra forma de traballar con variables.
 Isto, por certo, non ten que ser unha variable de matriz.
 Isto podería ser calquera variable.
 E se eu fai iso, non hai tal variable e eu recibín un 0.
 Outra pequena cousa alí sobre as avaliacións de variables.
 Volver a este aquí, se por algún motivo quería traballar con esta
 ao contrario de traballar coa matriz, a variable de shell,
 hai comandos que poden separar estas cousas baseado no colonos.
 En realidade, se está indo a estar a facer iso no shell Bash, posiblemente,
 algún tipo de script, que sería, probablemente, como faría.
 Pero no C-shell é moito máis doado de usar a matriz.
 O shell Bourne, as variables son asignados por unha única expresión como esta,
 como a forma que pode asignar unha variable nunha linguaxe de programación,
 e aquí non debe haber espazos.
 É necesario que sexa só unha cadea.
 Nos shells Bourne do tipo, as variables son variables shell.
 As variables de ambiente son un subconxunto das variables shell.
 Distínguense das variables non ambiente a través da exportación. A orde para facelo é a exportación, como impresora exportación.
 Se tivésemos que definir tal variable,
 se quería un comando de impresión para atopalo, tería que ser unha variable de ambiente,
 e é así que nós facelo un.
 Aquí hai algo medio confuso.
 Esta expresión, a exportación para o medio ambiente, deriva deste concepto shell Bourne,
 e aínda que a expresión é usada en descricións do C-shell,
 onde non existe tal orde como de exportación.
 Se acaba de dicir exportación por si só, ten unha lista de exportación -
 Entón, se eu simplemente exportar aquí, non hai tal cousa.
 Ok, alí imos nós.
 Esas cousas, de feito, tamén son definidos pola shell.
 Non definir calquera destes por min mesmo.
 A cuncha fai todo tipo de cousas por si só.
 Debe facer as cousas automaticamente.
 No Bash ou Korn, pode executar un comando coma este,
 que ambos dan unha variable dun valor e export-lo en un comando.
 O shell Bourne eles teñen que ser comandos separados como unha exportación.
 Aquí é outro aspecto que é confuso.
 A orde set no C-shell define as variables
 e sen argumentos lle di que os valores das variables son.
 No shell bash, o comando set sen argumentos fai o mesmo,
 pero con argumentos que fai algo completamente diferente.
 Entón, eses son os varios argumentos aquí.
 Algúns destes son variables de ambiente, algúns deles son variables shell.
 Todos eles son variables shell verdade. Algúns deses son variables de ambiente.
 A orde set con argumentos poden ser usados ​​para operar
 sobre os parámetros posicionais para un guión,
 que é un xeito de facelos todos dunha vez.
 Nós realmente non podemos entrar nese hoxe.
 Tamén se pode usar para cambiar o comportamento do depósito.
 Particularmente en Bash existen variables que han determinar o xeito no que o shell se comporta.
 Logo tamén só esta orde que se pode ver, esta orde.
 Maquetada seguido variables e tipos de variables se usa nos shells Korn e Bash.
 Non é obrigatorio, pero se pode usar para restrinxir os valores de variables,
 que pode ser útil para evitar erros, e é bastante común.
 Entón, eu só estou mencionando que en caso de velo en algún lugar.
 A orde onde.
 Lembra que eu mencionen anteriormente a orde onde o C-shell,
 que pode dicir a localización dun camiño de comandos.
 Aquí está a substitución de comandos.
 Ten que atopar o teclado en algún lugar un personaxe que se parece con isto.
 A localización do teclado vai variar.
 Chamamos iso crase. É aproximadamente o tamaño dunha cita.
 El vai de esquerda superior á dereita inferior.
 Aquí no meu teclado Mac é na esquina superior esquerda.
 Este carácter pode ser usado para executar un comando dentro dun comando.
 Se ten unha expresión dentro crase,
 esta expresión é un comando, é executado.
 A saída do comando
 é, entón, substituído por toda expresión backquote
 dentro dun comando máis longo que executa con que a produción
 como parte da súa serie de argumentos e así por diante.
 Aquí está o comando que usa isto.
 Imos demostrar o funcionamento aquí.
 Imos aquí, aproveitar os crase.
 Control A me chega ao inicio da liña coa sintaxe de edición Emacs.
 Ata agora, o camiños é o que fai,
 pero cando fago iso como este, a continuación, liga na lista de nomes de camiños
 no lugar da expresión backquote todo e corre ls-l sobre eles.
 Kind of cómodo, non é?
 Entón, iso é unha cousa legal. É así que funciona crase.
 Agora imos descender un pouco máis.
 Estes son alias. En realidade, eu usalos.
 Vou tentar conseguir isto en con unha operación de edición.
 Okay.
 Agora imos ver como estas definicións saíu.
 alcume LWH me dicindo como é definido.
 Lembra que non é máis que iso, pero os presupostos externas foron retiradas
 eo punto de exclamación é eliminado.
 *, A lista completa de todos os argumentos.
 Nunha definición de alias será aplicado de volta para onde eu uso iso.
 LWH ksh bash. Okay.
 Vexa como funciona isto? Tanto me aforra algún dixitación.
 Imos subir un pouco só para mencionar outra cousa aquí.
 Teña en conta aquí esas distintas cunchas. Eu debería ter mencionado iso antes.
 A csh ten un 2 aquí e así que fai / bin / tcsh.
 Poderiamos establecer por outros medios que aqueles son realmente o mesmo ficheiro.
 Lembre que eu estaba a dicir, se escribir sh comeza bash.
 Escriba iso e conseguir isto.
 Pero os que non están conectados. Os que os solteiros alí.
 E iso non é o tipo de ficheiro que pode chamar outra.
 Polo tanto, estas son arquivos separados, sendo que os C-shell son o mesmo ficheiro.
 Volver aquí abaixo, o outro aquí, este alias,
 teña en conta que está a ser executado esta orde, arquivo.
 Ese apelido que corre. Arquivo informa o tipo dun ficheiro.
 Festa ksh Entón FWH. Okay.
 Esta é a saída do comando subido.
 Eu non sei se vostede sabe o que iso significa aquí,
 Macho-O binario universal con 2 arquitecturas.
 Hai dous posibles tipos de procesadores en Mac,
 e algúns programas foron escritos para poder realizar con ambos,
 eo mando arquivo pode determinar que, de xeito que é o que esta significa.
 Ambos ficheiros foron escritos desa forma. Así, vemos como o alias funciona, ver como a crase funciona,
 vemos como os ls ficheiro reais ou ficheiro funciona.
 Isto pode non funcionar. Probe ", onde onde" e "LWH onde". Ok, imos tentar iso.
 onde para onde.
 onde é un shell built-in.
 Teña en conta que antes amosamos que Bash non tiña onde.
 Se insire onde no shell bash, recibe unha mensaxe de erro.
 É só unha parte da cortiza en vez de ser un comando separado.
 Qué acontece se eu escribir LWH buscar onde? Mira o que acontece alí.
 Ran onde onde, teño esa saída e, a continuación, intentou correr ls
 como l de onde é un shell built-in.
 onde está aí, pero os outros non existen.
 Ningún deles existe, en realidade.
 De xeito que non sempre funciona, e tamén ilustra como algunhas cousas
 non fai exactamente o que podería pensar.
 Imos descender un pouco máis aquí.
 Iso aquí é en Bash. Esta é tamén a substitución de comandos como a crase.
 Pero a diferenza de crase, usa este estilo variable.
 Hai unha serie de frases que comezan cun cifrão,
 e cando estes non son variables, eles prestado o uso do signo de dólar
 para indicar a expresión de calquera tipo.
 Isto pode estar entre parénteses ou corchetes ou parénteses dobres,
 que ten unha finalidade diferente.
 Solteiro parénteses aquí son unha substitución de comandos, así como os crase.
 Parénteses Casal é realmente unha operación aritmética.
 Hai outras sintaxe, outras operacións.
 Sintaxe crase está dispoñible en Bash.
 Con todo, esta é preferible. É moito máis fácil de ler e permite o asentamento.
 Pode que dentro $ (comandos) outro mando,
 algo así como -
 Recibe unha lista alí.
 Iso funcionaría se eu tivese a crase tamén.
 E se eu queira facer algo parecido -
 Probablemente non vai realmente usar esta orde,
 pero esta substitución mando interior ecoa os nomes de todos os ficheiros comezando cun,
 entón que é executado ls-l neses arquivos,
 e logo, este só ecoa a saída.
 Probablemente non vai facelo, tiña acaba de facer o eco ou ls,
 pero iso mostra como a nidificación de comandos funciona.
 Entón, só outra característica aquí.
  Eu mencionar que antes, que cando ten onde o C-shell,
 escriba obras nas cunchas Bourne do tipo para atopar comandos.
 Ordes internos, o que eu estaba dicindo alí.
 As ordes son parte do shell, como onde.
 Cando o shell executa unha orde como ls, el localiza-lo a través do camiño,
 atopa-lo nalgún directorio nalgún lugar,
 le-se que a memoria, crea un novo shell,
 le o comando ls ou o que quere para o shell
 onde as variables de entorno xa están localizados,
 e logo, trasládase a execución a el.
 Built-in de comandos, o código para que a orde está dentro da casca,
 para que o shell só comeza a realizar parte do seu propio código.
 onde está o tal comando. El realmente está máis rápido.
 Non ten que ler algo na memoria, que xa está na memoria.
 Ordes internos sempre teñen preferencia sobre as ordes do mesmo nome.
 As ordes que están en directorios no camiño pode ter o mesmo nome,
 ordes en distintos directorios, arquivos en directorios diferentes.
 O que ocorre no inicio do camiño é o que vai conseguir.
 Se non o houbera un comando embutido, sempre busca-la.
 Non hai xeito de darlle unha prioridade menor que unha orde no camiño.
 Se desexa obter este comando camiño, podes escribir a ruta completa.
 Se houbese unha orde, onde a ruta algures,
 podes escribir / bin / onde e que obtelo.
 Se non queres escribir todo o camiño, pode definir un alias.
 En realidade, se deu o alias do mesmo nome que a orde incorporado, iria traballar
 porque a definición do alias é valorada
 antes do shell determina que é un comando embutido, que debe ser executado.
 Entón iso está un pouco máis complicado, con algúns comandos aquí.
 O caso de algúns comandos son realmente comandos embutidos no e no camiño.
 Un deles é o eco, a orde usei só un pouco detrás destes exemplos.
 Eco é un comando no camiño e é en cada cuncha.
 Non necesariamente todos se comportan do mesmo xeito.
 Foi orixinalmente un comando único no camiño.
 Foi construído para as cunchas máis tarde.
 Porque hai opcións que dependen do medio
 e as opcións de liña de comandos, as ordes internos
 foron escritos para funcionar o mesmo que a orde que estaba no camiño,
 é improbable que sería escrito desa forma
 se a orde xa non fora escrito para o camiño.
 Entón, iso ten efectos secundarios. A súa historia ten efectos aquí.
 Hai opcións alí.
 Hai tamén unha opción definida por unha variable no tcsh chamado echo_style.
 Esta é unha desas variables que poden cambiar a forma que ecoam obras.
 Hai outros casos en que pode asignar unha variable
 que cambia o xeito no que a operación de shell, incluíndo unha orde integrado, funciona.
 Non afectará calquera outra cousa
 xa que outros comandos non teñen acceso ás variables shell,
 só as variables de ambiente. Pero as operacións de shell pode ler as variables de shell.
 Iso non vai funcionar para csh. Isto é só tcsh. Esa é unha das melloras.
 Análise de secuencias ten cando se avalía metacaracteres
 cando se avalía as variables, alias, referencias de historia.
 Hai unha secuencia específica para estas cousas.
 Se fai as cousas dunha determinada secuencia
 e chega a algo que é unha expresión dunha especie
 que xa ten valorado, non pode avaliar-lo novo.
 Se recibe-lo, el só vai pasar os personaxes.
 Entón, se a avaliación dalgunhas expresións, como substitución de comandos
 ou variable ou o que dá orixe a unha expresión
 que quere ser avaliado,
 que só funcionará se que a avaliación ten lugar máis tarde na secuencia.
 Espero que eu estou sendo claro alí.
 Esta secuencia de análise, unha operación no C-shell,
 non é o mesmo para os comandos internos como para os non incorporados comandos.
 Eu non estou seguro sobre Bash alí.
 Por exemplo, se unha variable shell produciu unha referencia historia,
 probablemente non estaba a volver na historia.
 Sería só obter o signo de admiración.
 De feito, podemos só tentar iso agora.
 definir a = e nós imos ter que poñer iso aí.
 Oh, espera. Sentímolo. Eu fixen iso no Bash. Quería facelo aquí.
 Véxase, por iso, non valorou que a referencia historia
 porque xa pasara o punto de avaliar expresións de historia
 cando se valorou a variable.
 Entón, iso é un efecto de análise.
 E, de novo, comandos internos non están feitas da mesma forma.
 Todo ben. Imos ao seguinte aquí.
 Este destino se a ser unha liña, pero está facendo-se máis fácil de ler.
 O que isto fai?
 Debe lembrar de que podemos avaliar asteriscos como curinga filename,
 e hai outros comodíns de nomes de ficheiros como o punto de interrogación e expresións de corchetes.
 Este tipo de avaliación se chama englobamento.
 definir noglob a comezos deste comando di para non facelo.
 noglob unset di volver facelo.
 Nótese que conxunto globo non tería ese efecto.
 En linguaxe común, establecer globo ou noglob unset semella equivalente,
 pero aquí non é. É noglob desactivado.
 Agora TSET. tset representaba conxunto terminal.
 Non se usa, que moitas veces agora, pero antes de que os sistemas de fiestras tornouse dispoñible
 e tiña un único terminal, pode ter que determinar o tipo.
 E se algo estaba vindo dunha rede Ethernet ou da rede,
 pode querer dicir que é un VT100.
 VT100 é unha especie de patrón na empresa terminal. Vén da terminal DEC.
 Se acaba de facer disco - entender iso? Isto remóntase un longo camiño, non é?
 Entón, se nós simplemente TSET aquí,
 se eu só fago tset, está redefinindo o meu terminal, pero non viu nada.
 El realmente non cambia nada.
 -S
 Okay.
 PRAZO setenv xterm-color.
 Xa sabemos que o termo foi creado desta maneira, de xeito que non se alterou.
 Esa é a forma que quere facelo.
 Pero teña en conta que esta orde, tset-s, só saída destes comandos. Non executa-los.
 Non executa estes comandos, pero a saída deles.
 Polo tanto, este se destina a producir comandos que se levará a cabo.
 Vostede recorda da orde nese arquivo que acaba de demostrar que tiña un Q nel.
 Entón, imos facelo.
 O Q suprime algunha saída, pero iso non importa aquí, como se pode ver.
 Eu só estou facendo isto para demostrar que iso non importaba.
 Isto está en sintaxe crase.
 Nótese a crase aquí, crase aquí.
 Estou omitindo isto aquí.
 Estes son casos de dicir o que facer
 no caso de certos tipos de terminais -
 Ethernet, rede dial-up, o que ten.
 Non importa aquí, porque non estamos realmente facendo calquera destas cousas.
 Eu só estou ilustrando o comando.
 Se eu fai iso coa crase, que é o que eu vou conseguir?
 Ademais, teña en conta aquí que este incluíu a noglob conxunto ea noglob desactivado,
 Polo tanto, estas son agora redundantes na definición.
 Isto non sempre é certo, pero agora están incluídas neste comando.
 Pero imos ver o que acontece se eu fai iso
 e vai para o inicio da liña co control A e fago iso.
 Ok, establecer: Comando non atopado. Iso é medio raro, non é?
 conxunto é un comando coñecido. É parte da casca.
 definir: Command not found? Por que isto?
 Hmm Ben, imos pensar sobre iso.
 Funciona unha substitución de comandos crase,
 e que ocorre con certa parte da secuencia de analizar o comando.
 conxunto é un comando embutido.
 Entón, no momento en que el fai iso substitución de mando,
 el xa conseguiu pasar o punto de identificación de comandos internos.
 Por iso, trátase definido como se fose un mando no camiño.
 Nin que dicir ten que non atopalo, e obter un erro.
 Well. Hai un exemplo de secuencia de análise.
 E o que imos facer sobre iso?
 Teña en conta esta orde moi interesante aquí, eval.
 Eu me pregunta o que fai.
 Se ollar para a guía - e imos facelo
 para mostrar o quão confuso estes manuais son -
 home tcsh, manual confuso, atopar as cousas por aquí non é fácil.
 Aquí imos nós, eval arg, para que poidamos ter un ou máis argumentos
 e hai unha lista de cousas alí. Trátase os argumentos como entradas para o shell
 e executa as ordes resultantes no contexto do depósito actual.
 Isto xeralmente se usa para executar comandos xerados como resultado do comando
 ou substitución de variables de análise, xa que se produce antes estas substitucións.
 Moi bo.
 E aquí aínda se refiren ao mando tset para un uso mostra
 como a que eu acabo de amosar.
 Agora eu teño que conseguir o diálogo de volta a un lugar útil.
 Imos comezar por aquí e imos ver o que eval se usa algo antes diso.
 Entón, imos ver o que pasa se colocarmos - aquí imos nós coas frechas para que a orde
 e controlar un ao principio, eval.
 Ok, entón funciona.
 Cando fai eval, leva o que vén despois e fai unha orde.
 Isto permite que analiza-lo esencialmente dúas veces.
 A sección aquí executa este comando dentro do crase,
 recibe a saída.
 A saída se quere para ser executado como os comandos aquí como estes
 a este e este.
 Así, os comandos son agora aquí nesta secuencia,
 pero estes son comandos embutidos no e non se atope los de inmediato.
 Entón imos para eval, eval colle aquilo, a cousa toda comeza todo de novo, e funciona.
 Un exemplo tanto de backquoting, eval, análise, consecuencias de análise,
 e unha orde que pode ser de moi pouca utilidade para vostede hoxe en día.
 Okay. Todo ben, umask.
 Vexamos esta orde aquí, umask 022. Eu me pregunta o que fai.
 Nós só escriba umask con nada despois. 22. Okay.
 022 e facelo de novo.
 Como ten que ter difícil de adiviñar, umask sen argumentos dille a máscara actual;
 umask con argumentos que o fai, pero iso era o que eu xa tiña.
 Que 022 significa?
 Estes son aquí as proteccións para un arquivo.
 Eles determinan quen ten permiso para ler, escribir ou realizar o arquivo.
 Proteccións son tamén chamados de permisos.
 O r significa lectura, o w para gravar,
 e x, que non está presente alí, está a ser executado.
 Existen 3 categorías de alí.
 Os últimos tres elementos están na categoría de usuario. Aqueles aplica a min, o usuario.
 Estes tres aquí se aplican ao grupo.
 O arquivo pertence a un grupo, o usuario pode pertencer a varios grupos,
 pero se o usuario está no grupo ao que esta imaxe pertence,
 logo esas proteccións aplicaranse a el, se non é o usuario.
 E esta é toda a xente.
 Estas categorías son mutuamente exclusivas.
 As proteccións usuario se aplica a el,
 as proteccións de grupo é aplicable aos membros do grupo que non o usuario,
 e as outras proteccións só é aplicable a outros que non o usuario e os membros do grupo de persoas.
 Se hai un r ou aw ou un x, isto significa que a protección se concede.
 Se hai un guión, isto significa que non é.
 Hai, de feito, son outras cousas que poden ser feitas aquí para alén destes,
 que eu non vou entrar agora.
 A umask define un estándar para os arquivos que crear.
 E, como unha máscara, basicamente di que os bits que non definir.
 Como é que isto se fai anacos?
 Se pensar en cada un deles como un número octal,
 este é o bit de 1s, este é o 2s, este é o 4s.
 Entón, de 0 a 7
 pode describir o que combinación de r de, w do e X do que ten para estes 3
 e logo, un número similar a estas e, a continuación, para estes.
 Entón, 022 significa 0 para a outra, para o grupo 2, 2 para o usuario.
 Pero esta é unha máscara. A máscara é o que non ten.
 Sinto moito. Eu só dei-lle cousas na orde errada.
 É a primeira 3. Estes son tres o usuario, estes tres son o grupo, estas tres son o outro.
 Sentímolo eu che dei estes na orde errada.
 O 0, que é o primeiro destes, non amosa o valor,
 pero se un número non é alí, é un 0.
 Isto significa que todos os 3 destes sería permitido.
 Teña en conta que nese particular o x non se admite.
 A razón é que o depósito é capaz de determinar
 se un ficheiro debe ser executado ou non.
 Xa que este non é un arquivo executábel, non definiu o x.
 Os dous medios que escribir permiso, a segunda categoría aquí,
 a do medio, é negado.
 Entón, de novo, estas son as cousas que el negouse.
 Ben, x se permite, pero non é aquí, porque non é executable
 e do mesmo xeito para os outros.
 Entón iso é un umask común.
 Outro común é de 700 - dar-se todo e ninguén máis.
 E hai outras posibilidades.
 Eu vou volver a iso. Usando a historia podo procurar cara atrás, para iso, LWH de alí.
 Okay. Entón, aquí, estas son as cunchas.
 Bash, o propietario que se conta do sistema, pode facer todo.
 Grupo e os outros poden facer ler ou executar, pero non escribir.
 Este nin sequera permiten que o propietario de escribir para el.
 O propietario quería escribir para el, a conta do sistema,
 tería que cambiar a protección primeiro.
 Pero, de novo, o umask define o patrón, enmascarado-o,
 indicando os bits que non serán creados.
 Isto é tipicamente nun dos seus arquivos de inicio, que é o. Cshrc ao C-shell
 ou o perfil. por as cunchas Bourne tipo.
 Pode ser tamén noutros lugares, se existen outros arquivos de inicio do sistema.
 En calquera caso, iso é umask. Hai algo medio raro aquí,
 e que é, por que hai un único mando para iso?
 Se eu estivese escribindo isto, eu faría unha variable, umask = algún valor.
 ¿Por que hai unha orde enteiro só para esta finalidade?
 A razón é esta só vai volver ás orixes do Unix.
 Unix era só un proxecto de programación na Bell Labs a principios de 1970.
 A xente simplemente se reuniron para programa.
 Nunca pretenderon que se fai un sistema operativo de todo o mundo.
 Diferentes persoas escribiron distintas partes sen pensar moito
 de como eles estaban indo para ser usado - no canto esbozado.
 E veu xunto así, e aínda é así nalgúns aspectos.
 Entón, que reflicte a historia, e aínda existen estas inconsistencias e elementos impares do mesmo.
 Okay. Next one aquí.
 Como escribín anteriormente, o C-shell non é realmente moi usado para programación,
 aínda que pode ser.
 El executa máis lentamente, unha vez máis o trade-off entre o uso interactivo,
 que ten máis que a velocidade de procesamento implicado,
 que pode facer sen o procesamento.
 Os recursos extra engadidos ao shell Bourne polo Korn e Bourne-again cunchas
 parecen non demora-los, e eu non sei por que isto ocorre.
 Podería ser só unha mellor programación, pero eu non estou en posición de saber.
 Acelerar aquí, en realidade, non é un negocio tan grande, aínda que sexa mencionada.
 A razón é que os scripts shell realmente estar moi rápido.
 Se hai unha morea de comandos como nun programa de calculacional,
 probablemente non estaba a facelo en un script shell.
 As operacións que son moi sinxelo e directo.
 Os que eu probei que son demasiado lentos
 envolven aplicacións repetidas de comandos lentos.
 Mencionen o editor de fluxo sed. Este comando é lento.
 Se executar varias veces sed, vai ter un guión lento, pero non é o shell que é lento.
 Executa-lo no shell Bourne non será moito máis rápido do que executa-lo no C-shell,
 aínda que quizais algunhas vantaxes alí.
 As capacidades de programación adicional, por outra banda,
 son razóns significativas por que ía usar as cunchas do tipo Bourne.
 C-shell ten características impares para iso -
 o feito de que non sabe se unha variable é unha variable shell ou unha variable de ambiente.
 Pode ser moi confuso.
 Non é tan fácil de escribir
 só con base na súa experiencia de programación en outras linguas.
 Coido que pode atopar as cunchas Bourne tipo máis consistente coa súa experiencia.
 Algúns scripts, con todo, pode haber miles de liñas de longo.
 Os que vin son usados ​​para remendar sistemas operativos.
 Aqueles poden executar moi lentamente, pero non executar aqueles con moita frecuencia.
 É só cando está facendo correccións,
 e é só o xestor do sistema que fai estas cousas,
 por iso non é realmente un gran problema.
 Aqueles que son centos de liñas de longo realmente executar rapidamente.
 Mencionando iso aquí, cales son estas melloras?
 Eu xa mencionei algúns deles - arrays, cálculos,
 os $ () de expresión para cálculos no shell bash,
 o outro tipo de substitución de comandos.
 Existen diferentes tipos de ordes de proba
 polo que se pode facer probas condicionais sobre a existencia dun ficheiro ou outras cousas.
 Última visita, esta orde aquí.
 O que isto fai, e por que alguén vai usalo?
 variablename printenv.
 Sabemos o que printenv fai. Dinos o valor dunha variable.
 E variablename printenv non nos din moito, porque non hai tal variable.
 En branco.
 Pero imos darlle algo significativo.
 Isto non é alí tamén. Okay. Creo que nunca marcou que.
 Imos comprobar o meu ambiente.
 Este é outro mando polo que pode inspeccionar seu contorno.
 Hai boas editor de idade, o que vimos antes.
 O que isto fai?
 Aquí temos unha expresión de crase.
 Teña en conta que esta é a C-shell.
 Entón EDITOR printenv daranos un valor de editor. É vin.
 E, a continuación, ha establecer o valor para a variable a, a orde set.
 Polo tanto, agora que fago echo $ a, eu recibín vin.
 Isto non parece moi útil.
 Con todo, realmente ten un propósito.
 Dende que nós non sabemos se a variable é unha variable shell ou unha variábel de entorno
 empregando a sintaxe avaliación cifrão, podemos utilizar printenv
 para asegurarse de que é unha variable de ambiente.
 Entón, se houbese un editor variable shell, iso non tería conseguido.
 Isto funciona só coa variable de ambiente.
 Se houbese unha variable shell e eu quería que o seu valor,
 Eu tería que atopar outra forma de facelo.
 Unha forma de facelo sería facer conxunto e tubaxes.
 Este é un dos metacaracteres, caracteres especiais.
 El envía a saída do conxunto para outra cousa.
 Imos ver o que podemos atopar alí.
 Nada. Okay. Imos ver o que está aí todos xuntos.
 Foi echo_style, aquel que eu mencionen antes. Ok, imos facelo.
 Lembre que eu mencionen antes, echo_style
 determina a forma como o comando `echo 'será executado.
 BSD significa Distribución Berkeley estándar.
 Este é o Berkeley Unix a partir dos anos 1970. Esa é unha das formas que ecoam pode ser executado.
 Establecer echo_style a ese valor no TC-shell fará eco a comportarse dese xeito.
 Polo tanto, establecer fai iso, pero só recibe definir variables shell.
 Non ía atopar editor, que non é unha variable shell.
 Nada.
 Así que esta é unha forma de distinguilo los.
 Pero o feito de que ten que pasar por algún comando raro así
 distinguir entre variables shell ou variables ambientais
 amosa o tipo de natureza implacable do C-shell para algunhas finalidades.
 E agora, para rematar e quizais menos, iso é as páxinas do manual.
 Aqueles de quen ten que saber, o home é o curto comandos para manual.
 As páxinas de manual para as cunchas son difíciles de ler. Son moi longos.
 Están organizados dunha forma que pode facer difícil para atopar o que está a procurar.
 Entón, se está a buscar algo con un propósito,
 non pode saber se o efecto é unha variable shell ou outra cousa,
 así que pode non saber onde mirar para el.
 Podes ollar para varias cordas, pero as cordas son moitas veces repetida.
 Por iso, é xeralmente difícil de ler.
 Nós só ollou para a páxina man TC-shell un pouco antes de atopar a orde eval.
 Algunhas cousas andan máis rápido.
 Unha visión é a busca dunha cadea.
 Pode utilizar o pager.
 Pager ten a barra para buscar unha orde ou unha secuencia dentro dunha operación de pager.
 Home por defecto usará pagers, ou ser máis ou menos.
 Non sei se está familiarizado con estes, pero estes poden amosar arquivos aos poucos.
 Eu teño usado a menos para amosar eses arquivos particulares que temos aquí.
 Pode procurar alí dentro.
 Podes probar a usar distintas secuencias de busca.
 Tamén páxinas de manual en diferentes sistemas operativos poden non ser os mesmos.
 Poden ser páxinas separadas para csh e tcsh.
 Eles non están en Mac, pero eles poderían ser se eses son os comandos separados.
 Se sh realmente non chamar Bash, probablemente habería unha páxina home separado.
 Algúns sistemas posúen páxinas de manual por separado só para o C-shell comandos internos.
 Ás veces, se quere ler a descrición dun comando embutido
 que tamén é o camiño, como eco, ten que ler a páxina de manual na que mando o eco
 para determinar como vai funcionar como un comando embutido
 mesmo se non está chamado a orde embutido.
 Isto é unha desvantaxe do sistema operativo, en xeral, non só para os encoros,
 aínda que para as cunchas, en particular as páxinas do manual son bastante longo,
 en parte porque engadiron características útiles para eles, o que pode ser un positivo.
 Okay. Algunha pregunta? Calquera temas que pretende traer?
 Calquera cousa relevante aquí?
 Ben, foi moi bo falar contigo todos.
 Espero que teña algo fóra deste seminario
 que serán útiles para ti nos seus futuros proxectos.
 [CS50.TV]