[Séminaire - shells Unix, les environnements]
 [Douglas Kline - Harvard University]
 [C'est CS50. - CS50.TV]
 

Le sujet d'aujourd'hui est le shell Unix.
 Je suis Douglas Kline, expert, ou au moins raisonnablement utilisateur compétente, de la coque.
 Une coque est l'interface pour l'utilisateur de système d'exploitation de l'ordinateur.
 Le nom est trompeur car, contrairement à la coque d'un animal,
 ce qui est difficile et de protection, l'enveloppe de l'ordinateur permet la communication.
 Donc membrane poreuse serait probablement une meilleure métaphore.
 

La coque d'origine pour Unix est le shell Bourne.
 Bourne est orthographié B-O-U-R-N-E.
 Bourne était l'un des auteurs originaux de Unix,
 et si la coquille est nommé d'après lui.
 Le nom de cette coquille comme une commande est tout simplement sh.
 C'est la commande que vous pouvez exécuter.
 La coque commence à la connexion.
 Lorsque vous vous connectez à l'ordinateur, la coquille commence juste courir pour vous,
 et c'est ce que prend vos commandes.
 Il peut commencer à d'autres moments également.
 Si vous apportez une fenêtre sans autre indication, il va commencer une coquille pour vous.
 C'est comme ça, c'est que vous pouvez aller à une fenêtre et commencer à taper des commandes
 et ainsi de suite là, même si vous n'avez pas connectez à cette fenêtre.
 En outre, si vous faites une connexion à distance,
 alors il va lancer un shell sur l'ordinateur distant.
 Et il est possible d'exécuter des commandes sans un shell interactif.
 Cela peut signifier au sein de votre opération en cours,
 et il peut aussi signifier une opération à distance.
 Vous pouvez envoyer une commande à un autre ordinateur,
 qui comprend le démarrage d'un interpréteur de commandes.
 En effet, elle doit comporter le démarrage d'une coquille y
 même si ce n'est pas votre but final.
 Quand quelque chose commence comme ça, il ne démarre pas nécessairement un nouveau shell.
 Si vous apportez une nouvelle fenêtre, il est possible de dire pour faire apparaître un éditeur
 ou une autre commande.
 Dans ce cas, l'éditeur va commencer à partir de zéro.
 Lorsque l'éditeur se termine, la fenêtre se termine.
 C'est un peu inhabituel, mais il peut être fait.
 Dans ces cas, il ne sera pas une coque.
 Donc ce n'est pas nécessairement le cas que d'une fenêtre ou d'une telle demande seront ouvrir un shell.
 

Shell analyse les commandes.
 Analyse des moyens d'identifier les différents éléments et de les classer.
 Dans une commande, la chaîne complète que vous tapez,
 il y aura une ou plusieurs commandes simples à exécuter.
 D'autres éléments peuvent être des arguments.
 Il peut aussi y avoir des caractères spéciaux qui affectent l'exécution d'une commande.
 Ils peuvent envoyer la sortie ailleurs que l'écran
 si la commande devrait normalement envoyer à l'écran.
 Il peut rediriger l'entrée, il peut faire d'autres choses aussi.
 Il existe divers autres symboles, caractères, etc.
 Analyse consiste à détecter et interpréter les choses.
 

Maintenant, si il n'y a plus de questions, ce qui est assez probable car il n'y a pas plus de gens,
 nous allons passer à ma page suivante ici.
 

J'ai déjà dit que le shell Bourne est l'enveloppe initiale.
 Il existe d'autres.
 L'un est le C-shell. La commande est csh.
 Le nom C-shell est juste un jeu de mots.
 Cette coquille a été introduit avec l'Unix de Berkeley dans les années 1970.
 Unix de Berkeley était un événement majeur dans le développement d'Unix.
 Ce fut une révolution énorme et comprenait l'introduction de cette coquille.
 La raison pour que le jeu de mots, C-shell,
 est que le C-shell a quelques caractéristiques en ce qui ressemblent le langage C,
 qui le shell Bourne n'a pas -
 ou il n'a pas eu à ce moment-là.
 Il ya aussi le TC-shell.
 Il s'agit d'un sur-ensemble du C-shell.
 Il a des caractéristiques additionnelles, dont beaucoup sont utiles pour un usage interactif,
 telles que les commandes en rappelant le mécanisme d'historique,
 que je vais vous décrire un peu plus tard -
 d'une manière simple, sur le modèle d'un éditeur.
 Il a également des liaisons qui permettent de lier une chaîne de clé court pour une commande plus.
 Nous n'allons pas être d'entrer dans qu'aujourd'hui.
 Il a quelques fonctionnalités qui sont utiles pour la programmation.
 Cependant, le C-shell n'est pas souvent utilisé pour la programmation shell.
 Programmes Shell, si vous ne le saviez pas déjà,
 sont des programmes qui consistent en des caractéristiques de la coquille.
 Vous pouvez exécuter ces programmes comme.
 Vous écrivez un tas de commandes shell dans un fichier et d'exécuter le fichier.
 Vous n'avez pas besoin de le compiler. C'est un langage interprété.
 L'expression C-shell est maintenant ambigu, car il pourrait se référer uniquement à la C-shell original, csh,
 ou à tous les C-coquilles, y compris tcsh. C'est un peu ambigu.
 

Une coquille plus tard est le shell Korn, ksh, nommé d'après le programmeur, Korn.
 Cette coquille a tenté d'incorporer dans une enveloppe
 les avantages de l'extrémité C-coquille pour une utilisation interactive
 et le shell Bourne pour la programmation.
 Il a été utilisé comme un shell interactif par certaines personnes - une minorité.
 Plus tard, cependant, il y avait une autre introduction, le shell Bash, BASH,
 encore un jeu de mots, shell Bourne-Again.
 C'est une extension de la Bourne shell. Korn est également. Deux d'entre eux.
 Il a les mêmes objectifs de Korn shell de la fusion de la C-shell
 et avantages Bourne shell dans une enveloppe.
 Beaucoup des améliorations de Korn sont également inclus dans Bash. Bash, cependant, a plus et il est donc préférable.
 Le shell Bourne-Again et le shell Korn sont appelés coquilles Bourne type
 parce qu'ils comprennent des caractéristiques de la Bourne shell,
 qui sont incompatibles à certains égards, avec C-coquilles.
 Il existe d'autres coquilles en plus de ceux, certains destinés à un usage restreint,
 peut-être limité à certaines commandes, peut-être des fins spécialisées, pas souvent utilisés.
 

Okay. Article suivant ici.
 Le shell Bash est devenu associé à diverses formes de Linux.
 Je ne sais pas si c'est vrai de toutes les formes.
 Il existe de nombreuses formes là-bas et je ne les ai pas tous utilisés,
 mais dans ceux que j'ai utilisé il est devenu associé avec elle.
 Autant que je sache, il n'y a rien Bash
 ce qui le rend plus compatible avec Linux
 que toute autre combinaison de coquille et un système d'exploitation.
 Je pense que cela reflète probablement les inclinaisons des programmeurs.
 Qu'il est devenu associé avec Linux est une autre raison de préférer Bash ksh
 puisque les choses sont susceptibles d'être écrite en elle et c'est susceptible de se propager.
 Je vais vous donner d'autres raisons pour que plus tard.
 Scripts shell Bourne doivent s'exécuter sous le shell Korn ou bash.
 Si vous écrivez quelque chose pour le shell Bourne,
 vous pouvez probablement l'exécuter sous ksh ou bash.
 Korn scripts shell sera probablement fonctionner sous Bash, mais je ne peux pas le garantir.
 Plus tard ici, son C-shell doivent s'exécuter sous le TC-shell.
 Le C-shell a été fait jamais beaucoup utilisé pour les scripts
 depuis le shell Bourne et plus tard, les coquilles de type Bourne était préférable à cet effet.
 Donc, ce n'est pas vraiment tout ce qui importe.
 Il ya beaucoup de scripts shell Bourne qui ont été écrites il ya longtemps,
 avant que le shell Korn ou Bourne Again Shell ont été introduites.
 Ce sont encore en usage, une partie des systèmes d'exploitation,
 et vous les trouverez si vous regardez dans le système d'exploitation
 ou certains anciens paquets de programmation.
 

Bash est dans une certaine mesure de devenir une sorte de lingua franca pour les systèmes d'exploitation.
 Il a déjà été étendu à Windows et VMS.
 VMS, au cas où vous ne savez pas, est un système d'exploitation propriétaire
 de Digital Equipment Corporation, qui est encore en usage, en grande partie dans les coulisses.
 Et si ça va être exécuté sur plusieurs systèmes d'exploitation différents,
 probable que les gens ont tendance à passer pour elle.
 Mais cette évolution est relativement récente.
 Il ne fait que commencer, donc je ne peux pas prédire si ce sera s'avérer vraiment ce genre de lingua franca.
 Aussi, parce que les chemins d'accès de fichiers et les bibliothèques diffèrent
 entre ces différents systèmes d'exploitation,
 vous pourriez ne pas être capable d'écrire un script Bash sur un système d'exploitation
 et ensuite l'exécuter sur un autre.
 Vous devriez être capable de le déplacer entre les différents Unix, Linux
 Les systèmes d'exploitation Mac OS, mais pas nécessairement pour Windows ou VMS.
 Vous pourriez avoir à modifier les descriptions fichier de chemin d'accès,
 et certaines bibliothèques peuvent être différents,
 ce qui peut affecter la façon dont certaines des commandes fonctionnent
 ou comment ils traitent les arguments, etc.
 En plus de cela, une autre mise en garde ici est qu'il n'y a aucune garantie
 que toutes les différentes coquilles que j'ai mentionnés - Bourne shell, C-shell,
 TC-shell, Korn shell, Bourne Again Shell - sera disponible sous tous les Unix
 ou Linux ou Mac OS.
 Ils pourraient tout simplement pas être là.
 C'est l'une des mises en garde ici.
 Il s'agit d'une limitation regrettable ici puisque vous voulez que les choses fonctionnent partout,
 mais malheureusement, vous ne pouvez pas compter sur cela.
 

Okay. Suivant un ici.
 Disons que vous voulez écrire un script shell,
 un programme composé de commandes shell.
 Vous écrivez vos commandes, de les mettre dans un fichier, et exécutez le fichier.
 Que faire si vous voulez inclure des arguments?
 Dans le cas des opérations de coquille, les arguments sont les paramètres ou les paramètres positionnels
 et ils vont être appelés par un signe de dollar et un chiffre, de 1 $, 2 $.
 Donc, si le script a ce nom, mon premier argument pourrait être l'argument 1
 et mon second pourrait être l'argument 2,
 et à l'intérieur de mon script si je veux faire référence à ces choses -
 nous allons effacer ce que je ne vais pas vraiment pour l'exécuter -
 dans mon script, je pourrais avoir 1 $ à se référer à arg1,
 2 $, qui sortira de cette façon, arg2.
 Donc, ces symboles sont disponibles pour se référer à des arguments,
 et ceux qui s'appliquent à l'ensemble des coquilles.
 En outre, il existe d'autres caractères.
 $ * Se réfère à la liste des arguments ensemble, chacun d'eux.
 $ # Désigne le nombre d'arguments.
 Encore une fois, cela s'applique à toutes les coquilles.
 Ces symboles, * et #, peuvent être utilisés avec les significations dans d'autres endroits également.
 Nous n'aurons pas à cela.
 

Shell ligne de prescripteur. Qu'est-ce que c'est ça?
 Disons que vous avez écrit un script et c'est un shell particulier et que vous voulez exécuter.
 Comment savez-vous ce que la coquille de votre système d'exploitation utilisera pour exécuter le script?
 A un moment, vous pourriez penser que ce serait aller dans le shell Bourne
 si vous n'avez pas dit autrement,
 mais les gens ne sont pas en train d'écrire des scripts dans le shell Bourne que beaucoup plus
 et vous ne pouvez même plus compter sur cela.
 Nous avons donc ici une ligne de spécification de la coquille ici. Qui spécifie Bash.
 Notez qu'il précise dans le chemin, / bin / bash.
 Si un ordinateur a le shell Bash, mais pas dans le répertoire bin, / bin, cela ne fonctionnera pas.
 C'est un autre qualificatif, un autre prudence ici.
 Le signe dièse est le caractère commentaire en ligne.
 Cela vaut pour tous les shells.
 Le cas particulier ici, #! au début d'un scénario, est un cas particulier.
 Qui spécifie la coquille dans laquelle pour exécuter le script.
 Comme je le disais, il pourrait ne pas être au même endroit / bin.
 En outre, il ya autre chose ici.
 Si vous venez d'utiliser le signe dièse sans point d'exclamation et le chemin,
 qui devrait indiquer un C-shell.
 Cependant, je ne recommande pas le faire parce que je ne suis pas en mesure de garantir
 que cela fonctionnera toujours.
 Si vous voulez un C-shell, il serait préférable de le dire.
 Ensuite, il ya quelque chose d'assez déroutant ici.
 Si vous utilisez une ligne enveloppe de spécification tels que / bin / bash
 et que la coquille n'est pas disponible là-bas,
 il n'y a pas une telle chose comme / bin / bash sur cet ordinateur particulier,
 soit parce qu'il n'a pas encore Bash ou parce que c'est dans un endroit différent,
 vous obtiendrez une erreur indiquant qu'il n'existe pas le script exécuté.
 Et bien sûr, votre script existe, de sorte que le message d'erreur est source de confusion.
 La raison pour laquelle le système d'exploitation qui vous donne cette erreur
 ou, plus précisément, que votre shell interactif dans lequel vous exécutez ce qui donne cette erreur,
 est qu'il indique la commande que vous avez utilisé, qui est le nom du script.
 Cette commande effectivement appelé la coquille par le nom du script.
 C'est là que vous obtenez ce message d'erreur à confusion.
 Une autre façon d'appeler script shell
 est en spécifiant la coque sur la ligne de commande, comme ici.
 Il s'agit d'une commande. Cela en dit courir Bash puis exécutez mon script Bash.
 Qui aura préséance sur une ligne de prescripteur,
 ce qui a pour fonction de vous permettre de fournir des chemins d'accès différents.
 Si vous venez de donner une commande, le système d'exploitation va chercher cette commande
 en divers endroits.
 S'il est disponible, il devrait le trouver.
 L'ordinateur va trouver Bash où il se trouve et de l'exécuter,
 vous n'avez donc pas besoin alors d'être préoccupé par où il le trouve.
 Il ya potentiellement d'autres préoccupations ici,
 comme s'il n'y avait plus de 1 version de Bash, ce qui est possible bien que peu probable.
 C'est donc une autre façon de traiter avec ces choses.
 lignes de Prescription peuvent appeler n'importe quel shell.
 Ils peuvent également appeler les choses autres que des coquilles.
 Exemples j'ai ici sont SED, qui est l'éditeur de flux;
 awk, qui est un langage de traitement de motifs;
 et perl, un langage de script très développé.
 Si vous mettez une ligne de spécification indiquant un de ces programmes au début,
 il ira directement à ce programme plutôt que de partir d'un shell.
 Ces programmes ont des limites à leurs capacités.
 Perl est très capable. Sed est un éditeur. Il peut faire des choses au-delà de l'édition simple.
 Mais il peut être difficile de programmer que.
 En outre, le passage d'arguments et d'autres choses à script est soit impossible, soit source de confusion.
 Donc, dans ces cas, avec awk ou sed, c'est, au moins dans mon expérience,
 préférable d'écrire un script et appel awk shell ou sed du script shell
 plutôt que d'appeler awk ou sed comme la ligne de script de spécification.
 Perl est un langage très diversifié, comme je le disais.
 Vous ne pouvez pas exécuter des commandes interactives en perl,
 ce qui signifie que vous ne pouvez pas tester les pièces de son exécution que vous êtes en développement
 en les exécutant de manière interactive.
 Cependant, il est un langage extrêmement capable
 et a développé un outil très largement utilisé.
 C'est juste un peu d'une parenthèse sur les lignes de spécification.
 

Dans tous ou la plupart des formes de Linux - encore une fois, je ne peux pas être certain que c'est tout -
 et dans Mac OS, si vous tapez csh vous obtenez tcsh,
 et si vous tapez sh vous obtenez bash.
 Ils y ont essayé de vous donner les versions plus avancées de ces coquilles,
 mais cela peut être déroutant.
 Si vous écrivez un script utilisant tcsh ou Bash fonctionnalités tout en appelant csh ou sh
 et puis essayez d'exécuter sur un ordinateur qui n'a pas tcsh ou Bash,
 vous pourriez avoir quelques erreurs si il existe des commandes là
 ces obus qui ne reconnaissent pas.
 En outre, vous avez appelé votre shell sur votre ordinateur local
 appelant comme sh ou csh et puis obtenir les coquilles les plus avancés.
 Vous pouvez même pas penser du fait que vous utilisez le shell plus avancé.
 Donc, c'est un piège potentiel.
 Comment est-il établi que si vous tapez sh vous obtenez Bash,
 si vous tapez csh vous obtenez tsch?
 Il ya des choses dans ces ordinateurs appelés liens
 qui peut se connecter aux noms de fichier pour désigner la même chose.
 Il peut être soit 2 noms pour le même fichier ou dans un fichier dont le but est de se référer à un autre fichier.
 Ils sont appelés liens durs et symboliques. Nous n'irons pas dans cette plus aujourd'hui.
 Il peut aussi y avoir des fichiers séparés - 1 fichier sh, 1 fichier Bash -
 mais ils courent tous les deux Bash.
 Puis il ya un autre qualificatif ici.
 Si vous appelez un de ces obus par un nom,
 vous pensez que vous obtiendrez les mêmes fonctionnalités que l'appelant par un autre nom. Eh bien, c'est en fait pas nécessairement vrai.
 Ces commandes peuvent examiner le nom par lequel ils ont été appelés
 et ils peuvent, sur la base de ce nom, se comporter différemment.
 Il peut y avoir des problèmes d'essayer de se conformer à une norme.
 Certains d'entre vous ont peut-être entendu parler de la norme POSIX ou d'une autre,
 peut-être d'autres caractéristiques.
 Cela peut être sélectionné parfois par des arguments de ligne de commande
 ou en définissant des variables shell.
 Appel comme sh ou bash peut effectivement conduire à une exécution différente
 même si c'est le même fichier que vous exécuter.
 Une autre chose à considérer est que, même si un autre ordinateur a tcsh ou Bash,
 si elles ne sont pas liées car ils se trouvent sur votre ordinateur local
 si vous avez un ordinateur local Linux ou Mac OS,
 là encore, vous aurez l'enveloppe que vous appelez sh ou csh, pas celui que vous préférez peut-être.
 Le shell Bourne actuelle comporte des améliorations moindre que ceux de Bash
 mais passé ceux du shell Bourne originale.
 En conséquence de cela, même l'enveloppe actuelle Bourne, sh,
 même quand il n'est pas Bash, ressemble à la langue C de plus que le C-shell fait.
 Ce n'était pas vrai lorsque le C-shell a été créé, mais il a développé de cette façon.
 Vous remarquerez peut-être ici que tous ces noms de coquille, sauf pour le shell Bourne
 avoir quelque chose à indiquer qui enveloppe qu'ils sont - csh, bash -
 mais le shell Bourne est juste sh.
 Pourquoi? C'était la coque d'origine.
 C'était la coque alors, pas une coquille,
 et comme c'était la coque, il n'y avait aucune raison de le distinguer d'un autre shell.
 Donc, c'est pourquoi il a ce nom et le fait encore.
 

Ce haut ici est une ligne d'une base de données de mot de passe pour un compte J'ai là
 sur un autre ordinateur.
 Je vais essayer d'obtenir ce nom de sorte que vous pouvez voir la partie à la fin, la coquille.
 La base de données de mots de passe contient les caractéristiques de connexion pour tous les utilisateurs.
 Au début est le nom d'utilisateur, qui vous pouvez voir les deux dernières lettres de moi maintenant.
 Les champs ici sont séparées par des virgules.
 Le dernier champ, comme vous pouvez le voir, est bin / tcsh, l'interpréteur.
 C'est l'indicateur de coquille.
 Il ya quelque chose d'intéressant ici.
 Lorsque Unix a été développé, il y avait seulement une coquille,
 donc il n'y avait pas le choix il.
 Alors pourquoi ont-ils permis un champ dans la base de données de mots de passe pour spécifier une coquille?
 Je ne sais pas, mais c'est la chance qu'ils ont.
 Il est assez difficile de faire des changements dans le format de base de données de mots de passe
 car de nombreux programmes se rapportent à son format
 et devraient être réécrit.
 C'est un développement heureux ou fortuit qu'ils comprenaient ce domaine.
 Ce genre de ligne du fichier de mot de passe est utilisé sur tous les ordinateurs Unix et Linux pour autant que je sais.
 Le Mac a son propre système.
 Il a fait un fichier de mot de passe avec les lignes dans ce format,
 mais ce n'est pas là les caractéristiques de l'utilisateur sont définies.
 Une autre remarque entre parenthèses il.
 

Si vous appelez un shell, vous pouvez l'appeler comme une sous-couche de vos coquilles existants.
 Donc, si je vais ici, Débarrassons-nous de ces choses.
 Ici, je suis dans le C-shell.
 Cette variable, qui identifie avec précision ma coquille,
 est en fait pas toujours un moyen fiable de déterminer ce shell que vous utilisez,
 mais dans ce cas il est.
 Que faire si je tape juste -
 Maintenant, je suis dans Bash.
 Certaines choses vont être la même. ls me dit mes commandes.
 Si je ne suspends un retour à mon C-shell, ls, même. Droite?
 fg, au premier plan, de retour à mon shell Bash.
 pwd, répertoire courant, vers le C-shell.
 pwd, répertoire différent - en fait pas un répertoire différent dans ce cas.
 C'est le même répertoire.
 Disons que je veux appeler une commande ici: où ls.
 Qu'est-ce que faire?
 Il me dit où la commande ls,
 celui qui me donne une liste de répertoire, est situé dans ls.
 Revenons à Bash. Essayons la même chose.
 Hmm, intéressant là-bas, où: command not found.
 Pourquoi est-ce?
 La où commande est intégré à la C-shell.
 Ce n'est pas une commande qui doit être lu dans la mémoire de quelque part d'autre et exécuté.
 Le C-shell fonctionne en transférant exécution une partie de son propre code
 et ce n'est pas dans le shell Bash.
 Donc, Bash, ne pas avoir une telle commande intégrée, le cherche, ne trouve pas,
 et nous obtenons une erreur.
 Donc, nous avons là un shell Bash fonctionnant sous un C-shell, et nous appelons cela un sous-shell.
 Et juste au cas où vous êtes curieux, Bash a sa propre façon de commandes localisation.
 hachée fait référence au fait qu'il ne peut être exécutée plus rapidement,
 être trouvé plus rapidement.
 C'est l'une des améliorations intégrées à certaines de ces coquilles.
 

Shells de type Bourne type sont préférés pour la programmation.
 Ils ont des structures de contrôle comme des boucles, des instructions conditionnelles,
 le genre de commandes que vous pouvez utiliser dans les langages de programmation comme C
 ou quelle que soit la langue. Peut-être que vous programmez en Java ou autre.
 Coquilles ont ceux qui sont trop.
 Les coquilles de type Bourne, en particulier Bash, ont plus
 et ils sont conçus avec une plus grande flexibilité.
 Le shell Bash a tableaux. The Bourne shell d'origine ne fonctionne pas.
 Cela peut donc être considérablement avantageuse pour la programmation.
 Le C-shell fait réellement avoir des tableaux, mais n'a pas beaucoup de ces autres caractéristiques. Les coquilles Bourne type s'exécute plus rapidement
 si elles ne présentent pas les caractéristiques destinées à être utilisées interactive.
 Vous chargez les choses dans un seul but, ce qui leur charge pour un autre but.
 Il ya ce compromis là.
 Ces dispositifs qui sont destinés à un usage interactif
 sont vraiment de peu ou pas de script.
 Il est possible d'utiliser un sous-shell interactif comme celui que j'ai commencé il
 de tester les commandes que vous souhaitez utiliser dans un script.
 C'est ce que vous ne pouvez pas faire avec perl. Vous pouvez le faire avec les coquilles.
 Même les structures comme pour les boucles et ainsi de suite peuvent être exécutés de manière interactive.
 Ils sont parfois utiles pour exécuter de manière interactive,
 mais plus vous les utilisez pour développer un script.
 

Alias.
 Cela va être sur le C-shell.
 mécanisme d'histoire où vous revenez aux commandes antérieures
 ou des parties de celles que vous avez déjà exécuté.
 Encore une fois, sur le C-shell, Bourne shell et Korn shell ont ces choses,
 mais je ne vais pas entrer dans les.
 Alors, voici quelques alias utiles que j'ai.
 Au lieu de taper ls - c'est un commandement commun -
 il suffit de taper l et vous épargner 1 caractère.
 ls avec diverses options, tous ceux qui travaillent.
 Notez que ces définitions ont citations autour d'eux.
 Dans ces cas, les citations ne sont pas nécessaires.
 Si vous pouvez définir ces alias sans les guillemets, il fonctionne encore.
 Ils sont recommandés.
 Il ya des situations où vous ne pouvez pas utiliser la citation
 parce que vous voulez quelque chose se passe qui empêcherait la citation.
 Parfois, vous pouvez citer une partie de la définition, mais pas la totalité.
 Il est également généralement recommandé d'utiliser des guillemets simples au lieu de guillemets doubles.
 Les guillemets doubles ont des effets sur les définitions de variables,
 en particulier les amenant à être évalués au lieu de l'arrêter.
 Pourquoi voudrions-nous d'arrêter l'évaluation?
 Et comment ne citations font que pour nous?
 

Voici une commande que vous pourriez trouver intéressant.
 'Ls g *'
 g *, comme vous le savez sans doute, est une expression générique
 pour tous les noms de fichiers commençant par g.
 Si je viens d'écrire dans une commande ls g *, je vais avoir une liste de tous les noms dans mon répertoire courant.
 Si je définis cet alias comme ici avec les guillemets,
 elle se déroulera cette commande dans le répertoire courant où vous exécuter.
 Mais si vous avez la définition d'alias sans les guillemets,
 il évaluera le caractère générique * g quand il lance cette commande définir.
 Ainsi, la définition de l'alias sera ls suivie par la liste des fichiers dans le répertoire
 dans lequel la commande alias est exécuté,
 indépendamment du lieu où vous avez réellement l'intention d'exécuter la commande.
 Ce n'est pas d'une grande utilité, et les guillemets simples empêcher l'évaluation de l'astérisque.
 Alors que vous venez d'obtenir la définition être ls g *.
 Ensuite, lorsque vous exécutez l'alias, LGS, il met alors cela.
 Maintenant, il n'y a pas de citations, et évalueront l'astérisque lorsque vous exécutez la commande alias.
 Donc, c'est une chose.
 Guillemets auraient même effet ici,
 mais il ya d'autres cas dans lesquels des guillemets ne fonctionnerait pas si bien.
 

En voici une autre.
 Vous savez peut-être la commande grep.
 La commande grep peut être utilisé pour scanner un fichier pour les lignes qui ont certaines chaînes.
 Allons donc ici et je vais quitter depuis mon shell Bourne.
 Très bien. Voici un fichier.
 Disons que c'est grep chaînes d'ABC. Il est là.
 Si je fais zddd grep, je ne reçois rien. Très bien.
 Donc, il trouve une chaîne, il rend compte, il ne trouve pas, il ne se présente pas.
 Il produit une ligne qui a cette chaîne sur elle.
 Il ya toutes sortes d'options ici que vous pouvez trouver dans la documentation.
 Voici une façon de le faire.
 Qu'en est-il celui-ci, alias grabc grep abc '?
 Cela va inclure une argumentation lorsque l'alias est défini.
 Donc, si je fais ça ici, maintenant, si je fais grabc,
 maintenant l'alias comprend plus que la simple commande. Il a également l'argument.
 Jusqu'à présent, cela fonctionne.
 J'ai une autre commande ici, celui-ci, ce sont donc les différentes chaînes en y
 et montrer que ce ne trouve rien là car il ne correspond pas.
 

Que faire si je veux inclure dans la définition d'alias le fichier que je vais chercher
 et je veux donner comme argument à l'alias de la chaîne que je cherche?
 Je pourrais vouloir dire abc comme argument de mon alias,
 mais l'alias déjà déterminé le fichier.
 Et c'est là que cette expression entre en jeu.
 Nous avons ici grep comme avant.
 Nous avons le fichier ici, cordes.
 \! ^, Type d'une expression étrange, je suppose, si vous n'avez pas vu cela avant.
 Point d'exclamation fait partie du mécanisme de l'histoire C-shell.
 Il peut rappeler des commandes précédentes, on peut rappeler les arguments de ces commandes et ainsi de suite.
 Le mécanisme d'historique est utilisé comme partie de repliement du spectre.
 Si vous spécifiez une ligne après le point d'exclamation, il fera référence à cette ligne dans la liste de l'historique,
 que nous n'obtiendrons pas en maintenant puisque c'est un tout autre sujet.
 Il est possible de saisir une partie d'une ligne.
 Alors! 03:02 serait le deuxième argument de la commande numéro 3.
 L'accent circonflexe dans cette expression désigne le premier argument. Si vous ne lui donnez pas une indication de la commande que vous parlez,
 elle se réfère à la commande immédiatement précédente,
 et le curseur est un symbole pour le premier argument.
 Parce que c'est le signe d'insertion et pas le numéro, vous n'avez pas besoin d'utiliser le côlon,
 si! ^ signifie que le premier argument de la commande précédente.
 Un peu mêlé ici.
 Dans ce cas, lorsque vous utilisez cela comme une définition de l'alias,
 la référence de l'histoire renvoie à des commandes dont l'alias est utilisé.
 Donc, cela va revenir une commande comme une opération de l'histoire,
 mais comme une opération d'alias, il se réfère à la commande dans laquelle vous souhaitez taper,
 dire, grstrings_file.
 Nous avons les citations ici en elle. Quelle est la barre oblique inverse pour?
 Dans ce cas, comme ailleurs, nous ne voulons pas d'exécuter le mécanisme d'historique
 tout en définissant l'alias.
 Si nous n'avions pas la barre oblique inverse là, le shell tirer dans le premier argument
 de la commande juste avant il a couru cette commande alias, que nous ne voulons pas.
 Nous voulons que cela soit intégré à la commande alias de faire appel à un argument plus tard.
 Les guillemets simples n'échappent pas à un point d'exclamation, la référence de l'histoire.
 Peut-être que vous connaissez l'évasion d'expression signifie de changer le sens de quelque chose.
 Dans ce cas, cela signifie d'arrêter quelque chose d'avoir une signification particulière.
 Signification spéciale de points d'exclamation à l'histoire.
 Échapper et il n'a pas ce sens.
 Citations ne font pas cela; barre oblique inverse fait.
 Donc, nous sommes en fait en utilisant deux niveaux d'échapper ici.
 Je vais passer cette commande dans l'autre fenêtre sans taper
 par l'utilisation de ces opérations d'édition, qui pourraient vous être utiles.
 Quelque chose d'autre ici, je vais vous montrer.
 Si vous tapez simplement alias sans arguments, il vous indique tous vos arguments.
 Il s'agit d'un groupe d'alias j'avais déjà ici
 en plus de ceux que j'ai utilisé ici aujourd'hui.
 Mais si je viens de taper le nom d'un alias, il me dit ce que cela signifie.
 Notez que les citations sont partis et la barre oblique inverse est parti.
 Cette chaîne ici est le résultat de cette définition de l'alias,
 et maintenant il vient! ^ en elle.
 Cela va chercher dans les chaînes de fichiers pour rien.
 Donc, si je fais chaînes grstrings_file, je ne lui donne pas quelque chose à chercher là-bas,
 mais il est à la recherche dans les chaînes.
 Il n'a pas trouvé les chaînes de mots dans les fichiers des chaînes, mais il ne trouve abc.
 Et il ne trouve pas.
 Donc, ici, nous donnons un argument qui frappe dans la définition de l'alias,
 qui est insérée dedans.
 C'est là que cette expression vient.
 Vous pouvez utiliser plus de 1.
 Le curseur est un symbole pour le premier argument.
 Si vous souhaitez utiliser un deuxième argument, il vous faudra alors dire: 2.
 Il n'y a pas symbole spécial pour le second argument.
 Et parce que vous utilisez un chiffre, vous devez utiliser le côlon.
 Il ya, cependant, un autre choix ici.
 Le symbole du dollar représente le dernier argument.
 Et parce que c'est un symbole, vous pouvez omettre le côlon.
 Donc, il serait le dernier argument dans la liste.
 Et il ya aussi celui-là.
 Asterisk signifie que tous, c'est donc la liste complète des arguments,
 et encore, vous pouvez omettre le côlon car ce n'est pas un chiffre.
 J'espère que vous êtes tous en observant tout cela.
 

Le mécanisme de l'histoire ne peut revenir aux lignes précédentes dans la liste de l'histoire.
 Vous pouvez le faire dans une définition d'alias.
 Je n'ai jamais vu cela.
 Il aurait pour effet de tirer des commandes antérieures de la liste de l'histoire
 lorsque vous exécutez l'alias, qui pourraient être différentes commandes
 selon le moment et l'endroit où vous l'exécutez.
 Il est concevable que vous pouvez sortir d'une telle référence
 juste pour savoir ce qu'est une commande antérieure était.
 Je n'ai jamais vu cela se produire.
 Je suppose que quelqu'un pourrait vouloir, mais c'est très peu probable.
 Il ya autre chose ici.
 Si vous utilisez cette référence de type d'histoire,
 seuls les arguments pour lesquels il existe une telle référence sont utilisés.
 Si vous avez une définition de l'alias qui n'utilise pas une référence de type d'histoire,
 si elle devient tout simplement le début de la commande
 et vous avez d'autres arguments, alors tout ce que vous tapez après que
 sera ajouté à la commande.
 Dans ce cas, l'exemple que je viens de donner là-bas, nous avons utilisé le premier argument;
 nous n'avons pas utilisé les autres.
 Si d'autres arguments ont été donnés sur la ligne de commande, ils ne seraient pas utilisés.
 Donc, si vous utilisez la référence de l'histoire du tout, alors vous devez l'utiliser pour obtenir un argument.
 

Il ya autre chose ici, je veux juste mentionner, en partie, entre parenthèses,
 à savoir que ce mécanisme d'historique avec le point d'exclamation
 remonte à la C-shell d'origine.
 Le tcsh introduit opérations d'histoire
 qui utilisent les sortes de commandes et les chaînes des éditeurs,
 soit Emacs ou vi.
 Mon opinion personnelle est Emacs est beaucoup plus facile à utiliser à cette fin
 même si vous utilisez vi pour votre édition régulière.
 Il existe différentes commandes Emacs qui sont maintenant adaptés pour l'histoire.
 Contrôle P obtient la ligne précédente dans la liste d'historique.
 Un autre contrôle P vous permet d'obtenir celle d'avant.
 La flèche vers le haut fait la même chose.
 Contrôle N reçoit la commande suivante si vous avez déjà défilé en retour certains égards. Flèche vers le bas fait que trop.
 Vous pouvez déplacer de gauche à droite avec les flèches et diverses autres choses.
 Cela peut rendre l'utilisation du mécanisme d'histoire
 beaucoup plus facile que d'utiliser la syntaxe de point d'exclamation,
 mais vous ne voudriez pas utiliser que dans une définition d'alias.
 Nous allons passer en revue une autre fois.
 

Variables.
 Vous savez ce que sont les variables dans les langages de programmation.
 Les obus ont eux aussi.
 Le C-shell utilise la commande set pour assigner les variables
 de sorte que la variable définit un à la valeur de b -
 comme je l'ai dit, une définition inutile, mais une illustration de la façon dont il est utilisé.
 La commande set va créer une variable si elle n'existe pas déjà.
 Les paramètres positionnels pour les scripts shell peuvent être considérés comme des variables,
 mais l'utilisation de ces derniers et les règles pour eux sont quelque peu différents.
 Vous ne pouvez pas attribuer une valeur à 1 $ dans le cadre d'un script.
 Vous n'avez pas à définir une nouvelle variable à cet effet si certains d'entre vous voulaient.
 Tapez set sans arguments et vous obtenez une liste de toutes les variables actuellement définies.
 Et passons à mon autre coquille ici et voir ce que nous obtenons si nous faisons cela.
 Une liste assez longue, non?
 Faites défiler jusqu'à un peu. Regardez tout cela.
 Certaines de ces choses sont définies automatiquement par le shell.
 La coquille crée la variable et qu'il donne une valeur.
 Certains d'entre eux sont définis par la coque mais redéfinies par l'utilisateur
 en fonction de ses préférences.
 Et certains d'entre eux sont créés par l'utilisateur en fonction de ce qu'il fait ce jour-là.
 C'est juste réglé sans arguments.
 Il ya une caractéristique étrange ici de cette chose.
 Il doit y avoir soit pas d'espace entre le signe égal et le nom de la variable
 et la valeur ou les espaces des deux côtés du signe égal,
 comme dans celui-ci.
 Cela ne fonctionnera pas, et c'est en fait une commande valide
 mais il ne fera pas ce que vous souhaitez.
 Cette commande ne fonctionne parce que si vous dites juste de définir et un nom de variable
 sans signe égal ou fixés et un nom de variable avec un signe égal et sans valeur,
 il sera la variable à une valeur nulle.
 Donc mettre un = est une commande valide.
 La commande de réglage peut définir plus d'une variable sur la même ligne.
 Donc, cette commande ici a pour effet de définir à la fois a et b pour les valeurs NULL.
 Probablement pas ce que vous voulez.
 Celui-là, mentionné plus haut, va conduire à une erreur
 car = b n'est pas une expression valide.
 Un nom de variable ne peut pas commencer par le signe égal.
 Et il ya ces autres choses ici.
 Les deux points ont été utilisés pour sélectionner les arguments des lignes de l'histoire,
 et ils peuvent être utilisés - et je ne suis pas en avant - de modifier les choses.
 Ils peuvent également être utilisés pour modifier les variables du shell.
 Celui-ci ici, $ a, a une valeur.
 : R va décoller une extension.
 Une extension sera tout suivant un point,
 un point et tout ce qui suit à la fin d'un fichier,
 qu'à la fin de la liste après la dernière barre oblique.
 Donc, je l'ai ici.
 a est que. Il fera tomber la. O.
 S'il n'y a pas l'extension, que les chemins d'accès après le dernier slash, il n'aura aucun effet.
 a: h, que l'expression variable va décoller le dernier élément d'une liste de répertoire,
 encore une fois, seulement après le dernier slash.
 Donc, / a / b / c devient / a / b,
 mais celui-ci est modifié parce que l'élément après la liste est nulle.
 Ici, il ya quelque chose que je tiens également à souligner.
 Ces qualificatifs ne recherchent pas l'existence de ces fichiers.
 Ils regardent juste pour cordes.
 Elles sont destinées à manipuler les noms de fichiers, les chemins,
 mais ils peuvent être utilisés sur n'importe quelle chaîne, même si ce n'est pas un nom de fichier.
 Et ils ne regardent pas l'existence,
 si il n'y a pas un tel fichier, / a / b / c, cela ne fonctionnera encore.
 Que ce soit de toute utilisation est une autre question, mais il faudra encore travailler.
 Les variables sont différentes dans les interpréteurs de commandes Bourne. Nous y reviendrons plus tard.
 Signe du dollar peut être échappé, tout comme le point d'exclamation et l'astérisque.
 Signe du dollar peut être une barre oblique inverse ou les guillemets simples.
 Les guillemets ont pour effet bizarre dans tous les shells
 de forcer l'évaluation d'un signe dollar expression variable.
 Donc, si c'est d'être échappé d'une manière, les guillemets peuvent avoir l'effet
 de le soumettre à l'évaluation de toute façon.
 C'est un peu déroutant.
 S'il existe plusieurs niveaux d'échapper, comme les apostrophes à l'intérieur des guillemets
 ou des guillemets à l'intérieur des guillemets simples, vous devriez tester pour voir ce qui va arriver
 à une variable si vous utilisez un.
 Ces deux situations - deux à l'intérieur du seul, à l'intérieur même de la double -
 ne vous donnent pas nécessairement le même résultat.
 Les variables d'environnement, les variables C-shell liés.
 Les variables d'environnement sont également variables dans le C-shell,
 et ils sont également des variables dans d'autres shells.
 Dans le C-shell, ils sont ensembles distincts.
 Les choses que je disais avant sont sur les variables du shell.
 Les variables d'environnement sont un ensemble distinct de variables
 à l'exception de plusieurs variables que nous appelons variables liées,
 qui sont très importants et nous allons entrer dans les plus tard.
 Les variables d'environnement sont automatiquement répercutés sur
 à coques ou des commandes qui sont exécutées depuis le shell. Les autres choses ne sont pas. Les variables shell, les alias ne sont pas. Les variables d'environnement sont.
 C'est pourquoi nous les appelons des variables d'environnement,
 l'idée étant que l'environnement s'étend au-delà simplement votre shell courant.
 Ils peuvent être utilisés pour définir les choses pour les commandes.
 Voici un exemple. IMPRIMANTE, LPDEST.
 Ces deux variables peuvent définir une imprimante une commande utiliser pour imprimer des choses.
 Si vous avez plusieurs imprimantes autour, vous voudrez peut-être mettre celui que vous aimez.
 La raison pour laquelle nous avons deux variables est que les différents ensembles de commandes ont été écrites
 l'utilisation de ces différentes variables.
 Vous pourriez leur donner des valeurs différentes.
 Très probablement, vous allez leur donner à la fois la même valeur.
 Ces choses fonctionnent parce que les commandes qui font impression
 ont été programmés pour examiner les valeurs de ces variables.
 Si un programme n'a pas été écrit de cette façon, si elle avait été écrite pour faire autre chose,
 la variable ne serait pas pertinente.
 Ainsi, le système d'exploitation n'est pas à la recherche de ces variables
 chaque fois que vous parlez d'une imprimante.
 Une commande qui fait impression est à la recherche de ces variables si elle est programmée de cette façon.
 Ces variables sont souvent définis dans vos fichiers d'initialisation
 mais pas nécessairement.
 Vous pouvez les définir sur la ligne de commande.
 Ils peuvent être définis dans une commande.
 Une commande qui fonctionne quelque chose pourrait avoir sa propre sélection de variables -
 variables qui sont propres à un logiciel particulier, par exemple.
 Ils seront définis lorsque vous exécutez ce package.
 Comment sont ces variables transmises à un sous-shell?
 Quand un sous-shell est écrit, il n'écrit pas dans ce domaine.
 Le domaine de la sous-couche qui est consacré à des variables d'environnement
 n'est pas rédigé par la sous-couche, il est écrit par la copie.
 Lorsque vous exécutez une commande ordinaire, comme ces commandes à imprimer ou que ce soit,
 ils commencent par créer un nouveau shell.
 Le shell crée une coquille, puis écrase une partie de celui-ci
 avec la commande que vous utilisez, ce qui est un peu déroutant,
 mais c'est la façon dont ces commandes obtiennent les variables d'environnement
 alors qu'ils se réfèrent à la suite.
 La commande ici pour définir la setenv variable.
 C'est ainsi que vous définissez. C'est trois éléments: setenv, variable, valeur.
 Si vous n'avez tout simplement setEnv sans arguments, ce que vous obtenez?
 Une liste de toutes les variables.
 Encore une fois, c'est une belle longue liste et dans ce cas, comme dans les autres,
 ces variables sont définies en grande partie par mon opération de connexion par la coque elle-même
 plutôt que par tout ce que j'ai fait.
 Il ya une autre commande ici, printenv.
 Qui imprime également l'environnement.
 Notez cette dernière chose ici, EDITOR = vi.
 Qui dit que si je suis en utilisant quelque chose qui appelle un éditeur
 et je ne spécifie pas un éditeur et il me permet le choix, il peut me donner vi.
 Que faire si je fais EDITOR printenv? Il me dit ce qu'il est.
 Juste avant cela, il y avait une variable, MOINS.
 Ce sont vos options par défaut lorsque je lance la commande MOINS,
 qui affiche les fichiers.
 Donc, si je fais ça, printenv peut prendre une argumentation ou 0 arguments,
 pas plus de 1.
 Il existe d'autres commandes aussi, mais nous n'allons pas entrer dans tous aujourd'hui.
 Rappelez-vous, il y avait les modificateurs pour les variables shell comme: h,
 qui passera le dernier élément d'un chemin,
 ou: r, qui passera une extension.
 Ceux s'appliquent maintenant aux variables d'environnement aussi. Ils n'ont pas l'habitude.
 Il sert à être ils ne pouvaient pas être modifiées. Maintenant, ils peuvent être.
 C'est l'une des avancées avec les développements des coquilles au fil des ans.
 Je disais que les coquilles dans le cadre de l'environnement
 et variables shell dans le C-shell sont, à quelques exceptions près, ensembles distincts.
 Vous pouvez établir une variable d'environnement et une variable de shell avec le même nom.
 Ils seront différentes variables, ils peuvent avoir des valeurs différentes.
 Modification de la valeur de l'un ne va pas changer la valeur de l'autre.
 Ces variables sont toutes évaluées avec le signe du dollar - $ a, $ que ce soit.
 Alors que faire si vous avez ce? Savez-vous que l'on vous obtenez?
 Dans mes tests, je suis la variable shell,
 mais ce n'est pas documenté et vous ne pouvez pas compter sur cela.
 Je vous demande donc, est de créer les variables shell et de l'environnement
 avec les mêmes noms une bonne idée? No. accord.
 Quelles sont les principales exceptions dans lesquelles les variables d'environnement et de coquillages
 sont reliés les uns aux autres?
 Il ya ces 4.
 Capital lettre variable d'environnement TERM,
 débourser terme variable dans les petites lettres, type d'émulation de terminal.
 Je vais juste aller ici et je vais faire écho, une commande très utile ici,
 $ Terme TERME $. Et là-bas.
 xterm est un type de terminal pour les fenêtres affichées dans le système X Window.
 xterm-couleur est une variante de celui qui permet à des couleurs différentes.
 Pourquoi avons-nous définissons que c'est? Quel est ce bon?
 Commandes qui réorganisent l'écran comme l'éditeur
 envoyer des séquences particulières, appelées séquences d'échappement,
 à un terminal ou d'une fenêtre à réarranger et ainsi de suite.
 Ces séquences sont différentes pour les différents types de terminaux.
 Ceci dit il quels sont ceux à utiliser.
 Parfois, il ya des problèmes là-bas. Vous voudrez peut-être changer cela.
 Si les choses ne fonctionnent pas, parfois le type de terminal est mal réglé,
 vous pourriez être en mesure de résoudre le problème en redéfinissant la variable à long terme.
 Dans ces cas, la modification d'une variable, la variable d'environnement ou la variable de shell,
 devrait changer l'autre.
 J'ai découvert grâce à l'expérience que le changement TERME en lettres capitales
 toujours ne change pas coque terme variable dans les petites lettres.
 C'est un bug.
 Je ne sais pas si c'est toujours vrai. La plupart du temps il n'est pas vrai, mais il peut être.
 Donc, si vous faites un changement, juste vérifier.
 Ce n'est pas souvent que vous avez besoin de changer cette valeur, mais de temps en temps vous faites.
 Environnement variable USER.
 Encore une fois, la variable d'environnement en majuscules, variable shell en petites lettres.
 Il s'agit de votre nom d'utilisateur.
 C'est seulement dans des circonstances très exceptionnelles
 que vous voulez changer.
 Si votre nom d'utilisateur est quelqu'un d'autre, il peut jeter toutes sortes de choses hors tension.
 répertoire d'accueil, le répertoire personnel de l'utilisateur.
 Encore une fois, vous ne voulez pas changer cela.
 Remarquez dans tous ces cas et celui que nous sommes sur le point de couvrir, la variable de chemin,
 variable d'environnement est en majuscules et la variable shell consolidé est en minuscules.
 Si vous modifiez un, vous devriez changer l'autre.
 Ce type de liaison ne peut être établie que vous ne pouvez pas lier 2 variables,
 autre que ceux-ci 4, et la liaison de ces variables ne peuvent pas être annulée,
 vous ne pouvez pas les séparer.
 Ainsi, ces quatre paires de variables sont liées.
 Ils seront toujours. Aucun autres seront.
 En outre, il serait possible de créer des variables avec les mêmes noms
 des types opposés.
 Vous pourriez faire une durée variable en coque en petites lettres
 ou une variable d'environnement TERM en lettres majuscules.
 Ces variables seraient indépendantes de ces variables appariées
 et ils seraient indépendantes les unes des autres.
 Je ne peux pas imaginer pourquoi vous feriez si vous voulez confondre les gens.
 Celui-ci ici, variable de chemin, c'est un vraiment importante.
 Une autre chose est qu'il ne peut y avoir des cas
 de variables avec des noms similaires appariés qui ne sont pas liés les uns aux autres.
 Il peut y avoir des variables shell et, en lettres majuscules et minuscules.
 Sur la base de ce nom, vous ne savez pas si cette variable est une variable de shell
 ou une variable d'environnement, et ils ne sont pas liés les uns aux autres.
 Donc, ce genre de noms couplés ne signifie pas variables liées.
 La variable de chemin, que je montrais avant,
 est une liste de noms de fichiers dans lequel la coque recherche les commandes.
 Passons sur cette fenêtre ici et nous allons faire echo $ PATH, majuscules -
 variable d'environnement - echo $ PATH, petites lettres - shell variable.
 Notez que la liste des répertoires est la même. Ceux-ci sont liés.
 Changer, vous changez l'autre.
 Dans la variable d'environnement les éléments sont séparés par des virgules. Notez que.
 Les variables shell sont séparés par des espaces.
 Cette variable d'environnement est une chaîne unique.
 La variable shell est un tableau.
 Le shell Bourne n'a pas encore tableaux.
 Bash, mais c'est déjà une partie fixe de la coque.
 Il s'agit d'une chaîne unique et non un tableau.
 Le C-shell toujours eu des tableaux.
 Les tableaux sont beaucoup plus faciles à travailler.
 Vous pouvez vous référer à des parties de celui-ci.
 $ Path donc écho [1] et je reçois / usr / bin, le premier élément.
 Encore une fois, n'oubliez pas de signe dollar représente le dernier élément de la liste de l'historique.
 Qu'arrive-t-il? Il a essayé de trouver le signe du dollar comme un symbole de variable.
 Je lui échapper. Oups. Il ne faudrait pas que ce soit.
 Certaines de ces choses ne fonctionnent pas aussi bien.
 Peut-être que nous allons laisser cela.
 Asterisk se réfère à la chose, mais c'est ce que vous obtenez si vous ne spécifiez pas un élément.
 Une autre façon que les variables de tableau peuvent être manipulés,
 nombre d'éléments là-bas, 7 éléments.
 Ici, nous mettons le signe dièse devant le nom de la variable.
 En voici un autre. Mettez un point d'interrogation là-bas.
 C'est une valeur logique. Cela indique que la variable existe.
 C'est une autre façon de travailler avec des variables.
 Que, par ailleurs, n'a pas à être une variable de tableau.
 Cela pourrait être n'importe quelle variable.
 Et si je le fais, il n'y a pas de variable et je reçois un 0.
 Une autre petite chose là-bas sur des évaluations variables.
 Retour à celui-là, si pour quelque raison vous vouliez travailler avec cette
 plutôt que de travailler avec le tableau, la variable de shell,
 il existe des commandes qui permettent de séparer ces choses basé sur le côlon.
 En fait, si vous allez faire ça dans le shell Bash, éventuellement,
 une sorte de scénario, ce serait probablement la façon dont vous le feriez.
 Mais dans le C-shell, il est beaucoup plus facile d'utiliser le tableau.
 Dans le shell Bourne, les variables sont attribués par une seule expression de ce genre,
 comme la façon dont vous pouvez affecter une variable dans un langage de programmation,
 et ici il doit y avoir aucun espace.
 Il faut que ce soit juste une chaîne.
 Dans les shells de type Bourne type, toutes les variables sont des variables de shell.
 Les variables d'environnement sont un sous-ensemble des variables shell.
 Ils se distinguent des variables non-environnement par l'exportation. La commande de le faire est d'exportation, comme export PRINTER.
 Si nous devions définir une telle variable,
 si nous voulions une commande d'impression à trouver, il devrait être une variable d'environnement,
 et c'est ainsi que nous nous faisons un.
 Ici, il ya quelque chose sorte de confusion.
 Cette expression, l'exportation de l'environnement, découle de ce concept de shell Bourne,
 et encore cette expression est utilisée dans les descriptions de la C-shell,
 où il n'y a pas de commande de l'exportation.
 Si vous venez de dire l'exportation par lui-même, vous obtenez une liste de exportés -
 Donc, si je ne exporter ici, rien de tel.
 Bon, là nous allons.
 Ces choses, d'ailleurs, sont également définies par le shell.
 Je n'ai pas défini l'une de ces par moi-même.
 La coquille fait toutes sortes de choses par lui-même.
 Il faut faire les choses automatiquement.
 Dans Bash ou Korn shell, vous pouvez exécuter la commande suivante,
 qui sera à la fois donner une variable une valeur et l'exporter dans une commande.
 Dans le shell Bourne, ils doivent être séparés des commandes comme une exportation.
 Voici un autre aspect qui est source de confusion.
 La commande set dans le C-shell définit les variables
 et sans arguments vous indique quelles sont les valeurs de variables sont.
 Dans le shell Bash, la commande set sans arguments fait la même chose,
 mais avec des arguments qu'il fait quelque chose de différent.
 Ce sont donc les différents arguments ici.
 Certains d'entre eux sont des variables d'environnement, certains d'entre eux sont des variables shell.
 Tous sont variables shell vraiment. Certains d'entre eux sont des variables d'environnement.
 La commande set avec des arguments peut être utilisée pour faire fonctionner
 sur les paramètres positionnels à un script,
 qui est une façon de les amener tous à la fois.
 Nous ne pouvons pas vraiment aller en parler aujourd'hui.
 Il peut également être utilisé pour modifier le comportement de la coque.
 En particulier dans Bash il ya des variables qui détermineront la façon dont le shell se comporte.
 Puis aussi cette seule commande que vous pouvez voir, cette commande.
 Composer suivie par les variables et les types de variables est utilisé dans les Korn et Bash.
 Ce n'est pas obligatoire, mais il peut être utilisé pour limiter les valeurs des variables,
 qui peut être utile pour éviter les erreurs, et il est assez commun.
 Donc, je vais juste mentionner que dans le cas où vous voyez quelque part.
 La commande où.
 Se souvenir J'ai mentionné plus tôt la commande où dans le C-shell,
 qui peut vous indiquer l'emplacement d'une commande chemin.
 Voici la substitution de commande.
 Vous devriez trouver sur votre clavier dans un endroit un caractère qui ressemble à ceci.
 La localisation sur le clavier va varier.
 Nous l'avons appelé backquote. Il s'agit de la taille d'un devis.
 Il va du coin supérieur gauche au coin inférieur droit.
 Ici sur mon clavier Mac c'est dans le coin supérieur gauche.
 Ce personnage peut être utilisé pour exécuter une commande dans une commande.
 Si vous avez une expression à l'intérieur des apostrophes inverses,
 cette expression est une commande, il est géré.
 La sortie de cette commande
 est alors substitué à l'expression entière backquote
 à l'intérieur de laquelle une commande plus court alors que la sortie avec
 dans le cadre de sa chaîne d'arguments et ainsi de suite.
 Voici une commande qui utilise cela.
 Démontrons l'opération ici.
 Allons ici, sortez les apostrophes inverses.
 Un contrôle me fait au début de la ligne avec la syntaxe d'édition Emacs.
 Jusqu'à présent, le chemins est ce d'où vient,
 mais quand je le fais comme ça, il se branche ensuite dans cette liste de noms de fichiers
 à la place de cette expression et pistes ls-l sur les backquote ensemble.
 Genre de pratique, hein?
 C'est donc une chose intéressante. C'est ainsi que fonctionnent les apostrophes inverses.
 Passons maintenant un peu plus loin.
 Ce sont des alias. En fait, je les utilise.
 Je vais essayer d'obtenir ce avec une opération d'édition.
 Très bien.
 Voyons maintenant comment ces définitions sont sortis.
 alias lwh me dire comment elle est définie.
 Notez que c'est juste, mais les citations extérieures ont été prises hors
 et le point d'exclamation est retiré.
 ! *, La liste complète de tous les arguments.
 Dans une définition de l'alias qu'il appliquera à l'endroit où j'utilise ce.
 lwh ksh bash. Très bien.
 Voir comment ça fonctionne? Il me sauve de la frappe.
 Allons un peu juste pour mentionner quelque chose d'autre ici.
 Remarquez ici ces différentes coquilles. Je l'ai mentionné auparavant.
 Le CSH a 2 ici et il en va de / bin / tcsh.
 Nous pourrions établir par d'autres moyens que ceux qui sont en fait le même fichier.
 Se souvenir que je disais, si vous tapez sh vous obtenez bash.
 Tapez ce que vous obtenez et ce.
 Mais ce ne sont pas liés. Ceux-ci ont les simples là-bas.
 Et ce n'est pas le type de fichier qui peuvent composer l'un l'autre.
 Donc, ce sont des fichiers séparés; ceux C-shell sont le même fichier.
 Retour ici, l'autre là, cet alias,
 noter que c'est l'exécution de cette commande, le fichier.
 Ce alias fonctionne que. Fichier vous indique le type d'un fichier.
 Donc FWH bash ksh. Très bien.
 C'est le résultat de la commande de fichier.
 Je ne sais pas si vous savez ce que cela signifie ici,
 Mach-O binaire universel avec 2 architectures.
 Il ya 2 types de processeurs possibles dans Mac,
 et certains programmes ont été écrits pour être en mesure d'exécuter à la fois,
 et la commande de fichier peut déterminer que, si c'est ce que cela signifie.
 Ces deux fichiers ont été écrites de cette façon. Ainsi, nous voyons comment l'alias fonctionne, nous voyons comment le backquote fonctionne,
 nous voyons comment les ls de fichiers réels ou fichier fonctionne.
 Cela pourrait ne pas fonctionner. Essayez "où où" et "lwh où". Bon, essayons cela.
 où où.
 où est un shell intégré.
 Rappelez-vous plus tôt, nous a montré que Bash n'a pas encore où.
 Si vous tapez où dans le shell Bash, vous obtenez un message d'erreur.
 C'est juste une partie de la coque plutôt que d'être une commande séparée.
 Qu'advient-il si je tape lwh recherche d'où? Voir ce qui se passe là-bas.
 Ran où où, obtenu cette sortie, puis essayé de lancer la commande ls
 comme l endroit où est une coquille intégré.
 où est là, mais les autres n'existent pas.
 Aucune de ces n'existe, en fait.
 Donc, cela ne fonctionne pas toujours, et il illustre également comment certaines choses
 ne faites pas tout à fait ce que vous pourriez avoir pensé.
 Allons un peu plus loin ici.
 Ici, c'est dans Bash. C'est aussi la substitution de commande comme la backquote.
 Mais contrairement backquote, il utilise cette section variable.
 Il ya un certain nombre d'expressions qui commencent par un signe dollar,
 et tandis que ceux-ci ne sont pas des variables, ils ont emprunté l'usage du signe de dollar
 pour indiquer une expression d'une certaine sorte.
 Cela peut être entouré par des parenthèses ou des crochets ou des parenthèses doubles,
 qui a un but différent.
 Parenthèses simples sont ici une substitution de commande, tout comme les apostrophes inverses.
 Les doubles parenthèses est en fait une opération arithmétique.
 Il existe d'autres syntaxes, d'autres opérations.
 Syntaxe backquote est disponible dans Bash.
 Toutefois, celui-ci est préférable. C'est beaucoup plus facile à lire et il permet de nidification.
 Vous pouvez avoir à l'intérieur $ (commande) une autre commande,
 quelque chose comme -
 Je reçois une liste il.
 Cela fonctionne si j'avais le backquote aussi.
 Que faire si je veux faire quelque chose comme -
 Vous n'auriez probablement pas réellement utiliser cette commande,
 mais cette substitution de commande interne reprend les noms de tous les fichiers commençant par un,
 puis celui-ci s'exécute ls-l sur ces fichiers,
 et puis celui-ci fait écho juste la sortie.
 Vous n'auriez probablement pas le faire, vous souhaitez simplement faire l'écho ou ls,
 mais ceci illustre comment l'imbrication de commandes fonctionne.
 Alors juste une autre option ici.
  Je l'ai mentionné plus tôt, que lorsque vous avez où dans le C-shell,
 tapez œuvres dans les coquilles de type Bourne pour les commandes de localisation.
 Les commandes intégrées, tout ce que je faisais là disent.
 Les commandes sont partie de la coque, comme l'endroit où.
 Quand le shell exécute une commande comme ls, il localise à travers le chemin,
 trouve dans un répertoire quelque part,
 lit que dans la mémoire, crée un nouveau shell,
 lit la commande ls ou quoi que dans la coquille
 où les variables d'environnement se trouvent déjà,
 puis il transfère l'exécution à elle.
 Commande intégrée, le code de cette commande est à l'intérieur de la coque,
 si la coquille commence juste exécuter une partie de son propre code.
 où une telle commande. Il se fait plus rapide.
 Il n'a pas besoin de lire quoi que ce soit dans la mémoire, c'est déjà en mémoire.
 Les commandes intégrées ont toujours la priorité sur les commandes avec le même nom.
 Les commandes qui sont dans des répertoires dans le chemin peuvent avoir le même nom,
 commandes dans des répertoires différents, les fichiers dans des répertoires différents.
 Celui qui se produit plus tôt dans le chemin est celui que vous aurez.
 Si il est une commande intégrée, vous obtenez toujours.
 Il n'y a pas moyen de lui donner une priorité inférieure à celle d'une commande dans le chemin.
 Si vous souhaitez obtenir cette commande de chemin, vous pouvez taper le chemin complet.
 S'il y avait une commande où dans le chemin, quelque part,
 vous pouvez taper / bin / où et vous souhaitez obtenir.
 Si vous ne voulez pas taper le chemin d'accès, vous pouvez définir un alias.
 En fait, si vous avez donné l'alias du même nom que la commande intégrée, cela fonctionnerait
 parce que la définition d'alias est évaluée
 avant que le shell détermine qu'il s'agit d'une commande intégrée qui doit être exécuté.
 Ensuite, cela devient un peu plus compliqué avec quelques commandes ici.
 Le cas de certaines commandes sont en fait intégré dans les commandes et dans le chemin.
 L'un d'eux est l'écho, la commande que je viens d'utiliser il ya un peu de tout dans ces exemples.
 Echo est une commande dans le chemin et c'est dans chaque coquille.
 Ils ne comportent pas nécessairement tous de la même façon.
 Il était à l'origine une commande que dans le chemin.
 Il a été construit dans les coquilles plus tard.
 Parce qu'il existe des options qui dépendent de l'environnement
 et les options de ligne de commande, les commandes intégrées
 ont été écrites pour fonctionner même que la commande qui avait été dans le chemin,
 il est peu probable qu'elles aient été écrites de cette façon
 si la commande n'avait pas déjà été écrite pour le chemin.
 Ainsi, cela a des effets secondaires. Son histoire a des effets ici.
 Il ya des options là-bas.
 Il ya aussi une option définie par une variable dans le tcsh appelé echo_style.
 C'est une de ces variables qui peuvent changer la façon dont les œuvres font écho.
 Il existe d'autres cas dans lesquels vous pouvez affecter une variable
 qui change la façon dont l'opération de coque, y compris une commande intégrée, fonctionne.
 Il ne serait pas affecter quoi que ce soit d'autre
 car d'autres commandes n'ont pas accès aux variables shell,
 seules les variables d'environnement. Mais les opérations de coquille peuvent lire les variables shell.
 Cela ne marchera pas pour csh. C'est seulement tcsh. C'est l'une des améliorations.
 Analyse possède des séquences lors de l'évaluation des méta-caractères,
 lors de l'évaluation des variables, des alias, des références historiques.
 Il ya une séquence particulière pour ces choses.
 Si elle fait les choses dans un ordre particulier
 et arrive à quelque chose qui est l'expression d'une sorte
 qui a déjà été évalué, il ne sera pas à nouveau l'évaluer.
 Si elle l'obtient, alors il suffit de passer sur les personnages.
 Donc, si l'évaluation de certaines expressions comme la substitution de commande
 ou variables ou autre chose donne lieu à une expression
 qui vous voulez être évalué,
 qui ne fonctionnera que si cette évaluation a lieu plus tard dans la séquence.
 J'espère que je suis d'être clair là-bas.
 Cette séquence d'analyse, une opération dans le C-coquille,
 n'est pas la même pour les commandes intégrées que pour les non-intégrés dans les commandes.
 Je ne suis pas sûr de Bash il.
 Par exemple, si une variable de shell produit une référence de l'histoire,
 il ne serait probablement pas revenir dans l'histoire.
 Il serait tout simplement obtenir le point d'exclamation.
 En fait, nous pouvons juste essayer cela en ce moment.
 définir un = et nous devrons mettre cela en là.
 Oh, attendez. Désolé. Je l'ai fait dans le coup. Je voulais le faire ici.
 Voir, de sorte qu'il n'a pas évalué que la référence de l'histoire
 car il était déjà passé le point de l'évaluation des expressions d'histoire
 lorsqu'il a évalué la variable.
 C'est donc une effet de l'analyse.
 Et encore une fois, les commandes intégrées ne sont pas faites de la même façon.
 Très bien. Allons à la prochaine ici.
 Ceci est destiné à être une ligne, mais c'est ce qui rend plus facile à lire.
 Qu'est-ce que faire?
 Vous vous souviendrez que nous pouvons évaluer des astérisques comme caractères génériques de noms de fichiers,
 et il ya d'autres caractères génériques de noms de fichiers comme le point d'interrogation et les expressions entre crochets.
 Ce type d'évaluation est appelé globbing.
 mettre noglob au début de cette commande dit de ne pas le faire.
 noglob unset dit retourner à le faire.
 Remarquer que le glob n'aurait pas cet effet.
 Dans le langage ordinaire, mis glob ou noglob unset semblent être équivalent,
 mais ici il n'est pas. C'est noglob arrêt.
 Maintenant tset. tset resta ensemble terminal.
 Il n'est pas utilisé que souvent maintenant, mais avant que les systèmes de fenêtrage sont devenus disponibles
 et vous aviez un seul terminal, vous pourriez avoir à déterminer le type.
 Et si quelque chose venait sur un réseau Ethernet ou à partir du réseau,
 vous pouvez dire que c'est un vt100.
 VT100 est une sorte de norme dans le secteur de la borne. Il provient de la borne DÉC.
 Si vous faites juste commuté - remarquer que? Cela remonte une manières, hein?
 Donc, si nous ne le tSET ici,
 si je fais juste tset, c'est réinitialiser mon terminal, mais vous ne verrez rien.
 Il n'a pas vraiment changé quoi que ce soit.
 -S
 Très bien.
 xterm-color setenv TERM.
 Nous savons déjà que le terme a été mis de cette façon, cela ne change rien.
 C'est la façon dont nous avions envie de faire.
 Mais remarquez que cette commande, tset-s, juste sortie de ces commandes. Il ne les a pas exécuté.
 Il n'a pas couru ces commandes, il les sortir.
 Donc, cela est destiné à produire des commandes qui seront ensuite exécutés.
 Vous vous souvenez de la commande dans ce fichier que je viens de montré que vous aviez un Q en elle.
 Alors faisons-le.
 Le Q supprime certaines sorties, mais qui n'a pas d'importance ici, comme vous pouvez le voir.
 Je fais juste cela pour vous montrer que ce n'était pas grave.
 C'est dans la syntaxe backquote.
 Notez le backquote ici, backquote ici.
 Je suis en omettant ces choses ici.
 Ce sont des cas de dire quoi faire
 dans le cas de certains types de terminaux -
 Ethernet, réseau, accès à distance, ce que vous avez.
 Il n'a pas d'importance ici parce que nous ne sommes pas en train de faire aucune de ces choses.
 Je suis juste illustrant la commande.
 Si je fais cela avec le backquote, que vais-je obtenir?
 Notez également ici que cela comprenait l'ensemble noglob et la noglob détruite,
 si ceux-ci sont désormais superflues dans la définition.
 Ce n'était pas toujours vrai, mais maintenant, ils sont inclus dans cette commande.
 Mais voyons ce qui se passe si je fais ça
 et je vais au début de la ligne avec la commande A et je le fais.
 Bon, set: Command not found. C'est un peu bizarre, n'est-ce pas?
 ensemble est une commande bien connue. Il fait partie de la coque.
 set: Command not found? Pourquoi est-ce?
 Hmm. Eh bien, nous allons réfléchir à ce sujet.
 Il est d'exécuter une commande de substitution backquote,
 et qui est provoquée par une certaine partie de la séquence d'analyse syntaxique de la commande.
 ensemble est une commande intégrée.
 Donc, au moment où il fait que la substitution de commande,
 il a déjà obtenu après le point de l'identification des commandes intégrées.
 Ainsi, il traite définir comme s'il s'agissait d'une commande dans le chemin.
 Inutile de dire, il ne le trouve pas et vous obtenez une erreur.
 Eh bien. Il ya un exemple de séquence d'analyse.
 Et que faisons-nous à ce sujet?
 Notez cette commande très intéressant ici, eval.
 Je me demande ce que cela fait.
 Si vous regardez le manuel - et nous allons juste faire que
 pour montrer comment la confusion de ces manuels sont -
 homme tcsh, manuel confus, trouver des choses ici n'est pas facile non plus.
 On y va, eval arg, afin que nous puissions avoir une ou plusieurs arguments
 et il ya une liste de choses là-bas. Traite les arguments que les entrées à la coque
 et exécute les commandes résultant dans le contexte de la coquille en cours.
 Ceci est habituellement utilisé pour exécuter des commandes générées en tant que résultat de la commande
 ou la substitution de variable parce analyse se produit avant ces substitutions.
 Très bon.
 Et ici, ils se réfèrent encore à la commande tset pour une utilisation de l'échantillon
 comme celui que je viens de vous montrer.
 Maintenant, je dois obtenir la fenêtre arrière à un endroit utile.
 Soyons ici et nous verrons que eval est utilisé juste avant que.
 Voyons donc ce qui se passe si nous mettons - nous voilà avec les flèches de cette commande
 et de contrôle A au début, eval.
 Bon, alors cela fonctionne.
 Quand vous faites eval, il prend ce qui vient après et fait une commande.
 Cela vous permet d'analyser des essentiellement deux fois.
 La section ici exécute cette commande à l'intérieur des apostrophes inverses,
 reçoit la sortie.
 La sortie est censé être géré comme ces commandes ici, comme les
 à celui-ci et à celui-ci.
 Donc, ces commandes sont maintenant ici, dans cette séquence,
 mais ceux-ci sont intégrés dans les commandes et il ne peut pas les obtenir tout de suite.
 Donc, nous allons à eval, eval prend ça, commence le tout une fois de plus, et cela fonctionne.
 Un exemple à la fois de backquoting, eval, l'analyse, les conséquences de l'analyse,
 et une commande qui est probablement de très peu d'utilité pour vous aujourd'hui.
 Très bien. Tout droit, umask.
 Regardons cette commande ici, umask 022. Je me demande ce que cela fait.
 Disons simplement entrez umask avec rien après. 22. Très bien.
 022 et le faire à nouveau.
 Comme vous l'aurez deviné, umask sans arguments vous indique le masque en cours;
 umask avec des arguments fait-il que, mais c'était celui que j'avais déjà.
 Qu'est-ce que 022 signifie?
 Ce sont ici les protections d'un fichier.
 Ils déterminent qui est autorisé à lire ou écrire ou exécuter le fichier.
 Les protections sont également appelés autorisations.
 Le r signifie lecture, w pour écriture,
 et x, qui n'est pas présent, il, est synonyme de s'exécuter.
 Il ya 3 catégories là.
 Les trois derniers éléments se trouvent dans la catégorie de l'utilisateur. Ceux s'appliquent à moi, l'utilisateur.
 Ces 3 ici s'appliquent au groupe.
 Le fichier appartient au groupe 1, l'utilisateur peut appartenir à plusieurs groupes,
 mais si l'utilisateur est dans le groupe auquel appartient ce fichier,
 alors ces protections s'appliqueront à lui s'il n'est pas l'utilisateur.
 Et celui-ci est tout le monde.
 Ces catégories sont mutuellement exclusives.
 Les protections d'utilisation s'appliquent à lui,
 les protections de groupe s'appliquent aux membres du groupe autres que l'utilisateur,
 et les autres mesures de protection s'appliquent uniquement aux personnes autres que l'utilisateur et les membres du groupe.
 S'il ya un r ou w ou x, cela signifie que la protection est accordée.
 S'il ya un trait d'union, cela signifie qu'il n'est pas.
 Il ya effectivement d'autres choses qui peuvent être mises en voici d'ailleurs ceux-ci,
 je ne vais pas entrer dans l'entreprise.
 Ce masque définit une valeur par défaut pour les fichiers que vous créez.
 Et comme un masque, fondamentalement, il dit les bits que vous ne définissez pas.
 Comment est-ce devenu morceaux?
 Si vous pensez que chacun de ces comme un nombre octal,
 il s'agit du bit de 1, c'est 2s, ce sont les 4s.
 Donc, de 0 à 7
 décrira la combinaison de R, w de, et des x que vous avez pour ces 3
 puis un nombre similaire de ceux-ci et ensuite pour ces derniers.
 Donc 022 signifie 0 pour l'autre, pour le groupe 2, 2 pour l'utilisateur.
 Mais c'est un masque. Le masque est ce que vous n'avez pas.
 Je suis désolé. Je vous ai donné les choses dans le mauvais ordre.
 C'est la première 3. Ces 3 sont l'utilisateur, ces 3 sont le groupe, ces 3 sont les autres.
 Désolé je vous ai donné les dans le mauvais ordre.
 Le 0, qui est le premier de ceux-ci, n'affiche pas la valeur,
 mais si un nombre n'est pas là, c'est un 0.
 Cela signifie que tous les trois de ces seraient autorisés.
 Notez que dans ce cas particulier x n'est pas autorisé.
 La raison en est que l'enveloppe est capable de déterminer
 si un fichier doit être exécuté ou non.
 Comme ce n'est pas un fichier exécutable, il n'a pas mis le x.
 Les deux moyens qui écrivent l'autorisation, la deuxième catégorie ici,
 l'un au milieu, est refusé.
 Encore une fois, ce sont les choses qu'il a nié.
 Eh bien, x est autorisé, mais ce n'est pas ici, car ce n'est pas exécutable
 et de même pour les autres.
 C'est donc un umask commun.
 Un autre commune est de 700 - vous donner tout et personne d'autre chose.
 Et il ya d'autres possibilités.
 Je vais revenir. Utilisation de l'histoire, je peux chercher dos pour que, lwh y.
 Très bien. Donc, ici, ce sont les coquilles.
 Bash, le propriétaire qui est le compte système, peut tout faire.
 Groupe et tout le monde peut faire lire ou exécuter mais pas écrire.
 Celui-ci ne permet même pas le propriétaire d'écrire dessus.
 Si le propriétaire a voulu écrire, le compte système,
 il faudrait changer la protection.
 Mais encore une fois, le umask définit la valeur par défaut en le masquant,
 en indiquant les bits qui ne seront pas fixés.
 C'est typiquement dans un de vos fichiers d'initialisation, qui est l'. Cshrc pour le C-shell
 ou le profil pour les shells de type Bourne type..
 Il peut être d'ailleurs également si d'autres fichiers d'initialisation du système.
 Quoi qu'il en soit, c'est umask. Il ya quelque chose un peu bizarre ici,
 et c'est pourquoi il ya une seule commande pour cela?
 Si j'écrivais cela, je voudrais faire une variable, umask = une certaine valeur.
 Pourquoi est-il une commande tout juste à cet effet?
 La raison en est ce va juste retour aux origines de Unix.
 Unix était un certain projet de programmation de Bell Labs dans les années 1970.
 Les gens se sont réunis pour le programme.
 Ils n'ont jamais voulu qu'il devienne un système d'exploitation dans le monde entier.
 Différentes personnes ont écrit les différentes parties sans penser beaucoup
 de la façon dont ils allaient être utilisé - plutôt sommaires.
 Et il est venu ensemble comme ça, et c'est encore comme ça à certains égards.
 Alors que reflète l'histoire, et il ya encore ces incohérences et éléments impairs de lui.
 Très bien. Suivant un ici.
 Comme je l'ai écrit plus haut, le C-shell n'est pas vraiment beaucoup utilisé pour la programmation,
 bien qu'elle puisse être.
 Il exécute plus lentement, encore une fois le compromis entre l'utilisation interactive,
 qui a plus de traitement impliqué que la vitesse,
 qui peut faire sans le traitement.
 Les fonctionnalités supplémentaires ajoutées à la Bourne shell par Korn et Bourne-Again coquilles
 ne semble pas les ralentir, et je ne sais pas pourquoi.
 Il pourrait juste être une meilleure programmation, mais je ne suis pas en mesure de savoir.
 Accélérer ici est en fait pas une grosse affaire, bien qu'il soit mentionné.
 La raison en est que les scripts shell se fait assez rapidement.
 Si il ya beaucoup de commandes comme dans un programme de calcul,
 vous n'auriez probablement pas le faire dans un script shell.
 Les opérations y sont assez simple et directe.
 Ceux que j'ai expérimentés qui sont trop lents
 impliquer des applications répétées de commandes lents.
 J'ai mentionné plus tôt l'éditeur en flux sed. Cette commande est lente.
 Si vous exécutez plusieurs fois sed, vous obtiendrez un script lent, mais ce n'est pas l'enveloppe qui est lent.
 Courir dans le shell Bourne ne sera pas beaucoup plus rapide que de courir dans le C-shell,
 mais il ya peut-être là quelques avantages.
 Les capacités de programmation supplémentaires, d'autre part,
 sont des raisons importantes pour lesquelles vous souhaitez utiliser les shells de type Bourne type.
 C-shell a des caractéristiques étranges pour elle -
 le fait que vous ne savez pas si une variable est une variable de shell ou une variable d'environnement.
 Il peut être très déroutant.
 Ce n'est pas si facile d'écrire
 juste, fondée sur votre expérience de la programmation dans d'autres langues.
 Je pense que vous pouvez trouver les shells de type Bourne type plus conforme à votre expérience.
 Certains scripts, cependant, peut être des milliers de lignes de longueur.
 Ceux que j'ai vu sont utilisés pour boucher les systèmes d'exploitation.
 Ceux-ci peuvent exécuter très lentement, mais vous ne courez pas ceux qui très souvent.
 C'est seulement quand vous faites correctifs,
 et ce n'est que le gestionnaire de système qui fait ces choses,
 il n'est donc pas vraiment beaucoup d'un problème.
 Ceux qui sont des centaines de lignes de long fait exécuter assez rapidement.
 Mentionner cela ici, ce sont les améliorations?
 J'ai déjà mentionné quelques-uns d'entre eux - les tableaux, les calculs,
 les $ () expression pour les calculs dans le shell Bash,
 l'autre type de substitution de commande.
 Il existe différents types de commandes de test
 par lequel vous pouvez faire des tests à l'existence d'un fichier ou d'autres choses.
 Dernière ici, cette commande ici.
 Qu'est-ce que faire, et pourquoi quelqu'un l'utiliser?
 variablename printenv.
 Nous savons ce que printenv fait. Il nous dit la valeur d'une variable.
 Et variablename printenv ne nous dira pas beaucoup parce qu'il n'y a pas de variable.
 Blank.
 Mais donnons-lui quelque chose de significatif.
 Ce n'est pas là non plus. Très bien. Je suppose que je n'ai jamais défini que.
 Disons simplement vérifier mon environnement.
 C'est une autre commande qui vous permet d'inspecter votre environnement.
 Il est bon vieux EDITOR, celui qu'on a vu avant.
 Qu'est-ce que faire?
 Ici, nous avons une expression backquote.
 N'oubliez pas qu'il s'agit du C-shell.
 Donc EDITOR printenv nous donnera une valeur de EDITOR. C'est vi.
 Et puis il sera mis en valeur que la commande set variable a,.
 Alors maintenant, si je fais un echo $, je reçois vi.
 Cela ne semble pas très utile.
 Cependant, il a bel et bien un but.
 Comme nous ne savons pas si une variable est une variable de shell ou une variable d'environnement
 en utilisant la syntaxe d'évaluation de signe dollar, nous pouvons utiliser printenv
 pour s'assurer que c'est une variable d'environnement.
 Donc, si il y avait une coquille éditeur de variables, cela n'aurait pas eu il.
 Cela fonctionne uniquement avec la variable d'environnement.
 S'il y avait une variable de shell et je voulais sa valeur,
 Je dois trouver une autre façon de le faire.
 Une façon de faire qui serait en faisant ensemble et de la tuyauterie.
 Il s'agit d'un des caractères de remplacement, des caractères spéciaux.
 Il envoie la sortie du jeu à autre chose.
 Voyons ce que nous pourrions y trouver.
 Rien. Très bien. Disons simplement voir ce qui est là tous ensemble.
 C'était echo_style, celui que j'ai mentionné avant. D'accord, faisons-le.
 Se souvenir je l'ai mentionné avant, echo_style
 détermine la façon dont la commande echo sera exécutée.
 bsd signifie Berkeley standard distribution.
 C'est l'Unix de Berkeley dans les années 1970. C'est l'un des moyens qui font écho peut fonctionner.
 Réglage echo_style à cette valeur dans le TC-shell fera écho à se comporter de cette façon.
 Ainsi défini ne, mais mis seulement obtient variables shell.
 Il ne serait pas trouver EDITOR, qui n'est pas une variable de shell.
 Rien.
 Donc, c'est une façon de les distinguer.
 Mais le fait que vous devez passer par une certaine maîtrise étrange comme ça
 faire la distinction entre les variables du shell ou les variables d'environnement
 montre le genre de la nature pratique de la C-shell à certaines fins.
 Et maintenant, la dernière et peut-être moins, ce sont les pages de manuel.
 Ceux de qui vous savez peut-être, l'homme est à court de commande pour manuel.
 Les pages de manuel pour les coquilles sont difficiles à lire. Ils sont très long.
 Ils sont organisés d'une manière qui peut rendre difficile de trouver ce que vous cherchez.
 Donc, si vous cherchez quelque chose avec un but,
 vous ne pouvez pas savoir si ce but est une variable de shell ou autre chose,
 de sorte que vous ne pouvez pas savoir où chercher.
 Vous pouvez chercher des différentes chaînes, mais les cordes sont souvent répétées.
 Donc, il est généralement difficile à lire.
 Nous venons de voir la page de manuel TC-shell un peu avant de trouver la commande eval.
 Certaines choses vont plus vite.
 Une approche consiste à rechercher une chaîne.
 Vous pouvez utiliser le pager.
 Pager a la barre pour chercher une commande ou une chaîne dans une opération de pager.
 Man par défaut utilisera pagers, soit plus ou moins.
 Je ne sais pas si vous êtes familier avec ceux-ci, mais celles-ci peuvent afficher les fichiers bit par bit.
 Je me sers de MOINS pour afficher ces fichiers particuliers que nous avons ici.
 Vous pouvez rechercher à l'intérieur il.
 Vous pouvez essayer d'utiliser différentes chaînes de recherche.
 Également les pages de manuel dans différents systèmes d'exploitation peuvent ne pas être la même.
 Ils peuvent être des pages distinctes pour csh et tcsh.
 Ils sont ne sont pas sur le Mac, mais ils pourraient être si ce sont des commandes distinctes.
 Si sh ne vraiment pas appeler Bash, il serait probablement une page de manuel séparé.
 Certains systèmes ont des pages de manuel séparées seulement pour les C-shell commandes intégrées.
 Parfois, si vous voulez lire une description d'une commande intégrée
 c'est aussi dans le chemin, comme l'écho, vous devez lire la page de manuel sur cette commande sur écho
 pour déterminer comment cela va fonctionner comme une commande intégrée
 même si vous n'êtes pas d'appeler la commande intégrée.
 C'est un inconvénient du système d'exploitation en général, non seulement pour les coquilles,
 bien que pour les coques en particulier les pages de manuel sont assez longues,
 en partie parce qu'ils ont ajouté des fonctionnalités utiles pour eux, ce qui peut être positif.
 Très bien. Y at-il des questions? Tous les sujets que vous souhaitez aborder?
 Rien de pertinent ici?
 Eh bien, ça a été très agréable de vous parler tout.
 J'espère que vous avez quelque chose de ce séminaire
 qui seront utiles pour vous dans vos projets futurs.
 [CS50.TV]