Quelle est la signification d'un point avant une command en shell?

Tout en suivant le tutoriel de debugging android eclipse, je rencontre les commands suivantes.

cd /path/to/android/root . build/envsetup.sh lunch 1 make emulator 

Mon problème est ce que le point avant build/envsetup.sh signifie?

Un point dans ce context signifie "source" du contenu de ce file dans le shell courant. Avec la source elle-même est une command shell embeddede. Et la source et l'opérateur de points étant des synonymes.

Exemple

Disons que j'avais le contenu suivant dans un file sample.sh .

 $ cat sample.sh echo "hi" echo "bye?" 

Maintenant, quand je le trouve:

 $ . sample.sh hi bye? $ 

Les files de ce type sont souvent utilisés pour incorporer des commands d'installation telles que l'ajout de choses à des variables d'environnement.

Exemples

Dire que j'avais ces commands dans un autre file, addvars.sh .

 $ cat addvars.sh export VAR1="some var1 ssortingng" export VAR2="some var2 ssortingng" 

Notez que je n'ai pas de variables dans l'environnement de mon shell actuel.

 $ env | grep VAR $ 

Maintenant, quand je source ce file:

 $ . addvars.sh $ 

OK, ne semble pas avoir fait quoi que ce soit, mais quand on vérifie à nouveau les variables env :

 $ env | grep VAR VAR1=some var1 ssortingng VAR2=some var2 ssortingng 

Pour append à la réponse de slm:

Il y a deux façons d'exécuter un script shell. L'une consiste à exécuter le script dans un process distinct, ce qui signifie que tout ce qui concerne l'environnement du shell (état de la memory) reviendra à l'état du shell «parent» avant d'exécuter le process shell «enfant».

Par exemple, le directory de travail actuel (l'location dans le système de files dans lequel il se trouve) est déterminé par process. Donc, nous allons avoir un script qui ressemble à ceci:

 #!/bin/bash cd ~ cd .. pwd 

Alors, appelons ce script, oh, foo . Et ./foo ce script comme suit: ./foo

Nous verrons ce qui suit:

 /home 

(Avertissement standard selon lequel il existe un grand nombre de dissortingbutions de clones Linux et autres UNIX, dont certaines ne mettent pas les directorys de l'user dans /home , ou comme nous le disions «Votre kilométrage peut varier»).

Maintenant, après avoir exécuté ce script, tapons cette command

 pwd 

Pour voir dans quel directory nous sums. Nous verrons quelque chose comme ceci:

 /home/username 

La raison étant, encore une fois, que le script shell que nous avons exécuté avait son propre environnement (y compris son propre directory où les commands étaient exécutées) et que cet environnement disparaissait une fois le script terminé.

Maintenant, foo script foo comme ça

 . ./foo 

Ou, de manière équivalente:

 source ./foo 

Si nous faisons un pwd par la suite, nous verrons ceci:

 /home 

La raison étant la suivante: L'obtention d'un script n'appelle pas un process distinct. C'est comme écrire toutes les commands du process parent à la main; son environnement est préservé après la fin du script.


Laissez-moi en venir avec un exemple plus simple. Ayons un script qui ressemble à ceci:

 #!/bin/bash exit 

Disons-le foo . Faisons en sorte que nous puissions l'exécuter: chmod 755 foo . Alors, courons comme ça:

 ./foo 

Rien ne se passe. Cependant, d'un autre côté, si nous faisons ceci:

 . ./foo 

Ou ca:

 source ./foo 

Nous nous déconnectons.

La période (point) est une main courte pour le bash construit dans "source". Il lit et exécute les commands d'un file dans l'environnement actuel et renvoie l'état de sortie de la dernière command exécutée. Les files peuvent être dans le directory actuel ou n'importe où dans le PATH. Il n'a pas besoin d'être exécutable.