Réponses:
Un point dans ce contexte signifie "source" le contenu de ce fichier dans le shell actuel. En source
étant elle - même une coquille commande interne. Et source
et l'opérateur de points étant des synonymes.
Disons que j'avais le contenu suivant dans un sample.sh
fichier.
$ cat sample.sh
echo "hi"
echo "bye?"
Maintenant, quand je le source:
$ . sample.sh
hi
bye?
$
Les fichiers tels que celui-ci sont souvent utilisés pour incorporer des commandes de configuration telles que l'ajout d'éléments à des variables d'environnement.
Dire que j'avais ces commandes dans un autre fichier, addvars.sh
.
$ cat addvars.sh
export VAR1="some var1 string"
export VAR2="some var2 string"
Notez que je n'ai aucune variable dans l'environnement de mon shell actuel.
$ env | grep VAR
$
Maintenant, quand je source ce fichier:
$ . addvars.sh
$
OK, ça ne semble rien avoir, mais quand on vérifie env
à nouveau les variables:
$ env | grep VAR
VAR1=some var1 string
VAR2=some var2 string
Pour ajouter à la réponse de slm:
Il existe deux manières d'exécuter un script shell. L'une consiste à exécuter le script dans un processus séparé, ce qui signifie que tout ce qui concerne l'environnement du shell (état de la mémoire) reviendra à l'état du shell "parent" avant d'exécuter le processus du shell "enfant".
Par exemple, le répertoire de travail actuel (l'emplacement dans le système de fichiers dans lequel il se trouve) est déterminé processus par processus. Alors, avons un script qui ressemble à ceci:
#!/bin/bash
cd ~
cd ..
pwd
Alors appelons ce script, oh foo
. Et exécutons ce script comme suit:./foo
Nous verrons ce qui suit:
/home
(Clause de non-responsabilité standard indiquant qu'il existe un grand nombre de distributions de clones Linux et UNIX, dont certaines n'inscrivent pas les répertoires de l'utilisateur /home
. Ou, comme nous le disions auparavant, "votre kilométrage peut varier")
Maintenant, après avoir exécuté ce script, tapez cette commande
pwd
Pour voir dans quel répertoire nous sommes. Nous verrons quelque chose comme ceci:
/home/username
La raison en est, encore une fois, que le script shell que nous avons exécuté avait son propre environnement (y compris son propre répertoire dans lequel les commandes étaient exécutées) et que cet environnement a disparu une fois l'exécution du script terminée.
Maintenant, exécutons le foo
script comme ceci
. ./foo
Ou équivalent:
source ./foo
Si nous faisons un pwd
après, nous verrons ceci:
/home
La raison en est: La création d'un script n'appelle pas un processus séparé. C'est comme si vous tapiez toutes les commandes du processus parent à la main. son environnement est préservé à la fin du script.
Permettez-moi de vous donner un exemple plus simple. Ayons un script qui ressemble à ceci:
#!/bin/bash
exit
Appelons-le foo
. Assurons - nous exécuter: chmod 755 foo
. Ensuite, exécutons-le comme ceci:
./foo
Rien ne se passe. Cependant, si nous faisons cela, par contre:
. ./foo
Ou ca:
source ./foo
Nous nous déconnectons.
Le point (point) est un raccourci pour la bash intégrée source
. Il lira et exécutera les commandes d’un fichier de l’environnement actuel et renverra l’état de sortie de la dernière commande exécutée. Les fichiers peuvent être dans le répertoire en cours ou n'importe où dans le répertoire PATH
. Il n'a pas besoin d'être exécutable.
# type .
. is a shell builtin
# help .
.: . filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.
Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.
. (opérateur source ou point)
Lire et exécuter des commandes à partir de l'argument filename dans le contexte actuel du shell.
Syntax
. filename [arguments]
source filename [arguments]
source est un synonyme de point / période '.' dans bash, mais pas dans POSIX sh, utilisez donc le point pour une compatibilité maximale.
Lorsqu'un script est exécuté à l'aide de source, il s'exécute dans le shell existant. Toute variable créée ou modifiée par le script reste disponible une fois le script terminé. En revanche, si le script est exécuté comme un nom de fichier, un sous-shell distinct (avec un ensemble de variables complètement séparé) sera créé pour exécuter le script.
Il existe une différence subtile entre l'exécution d'un script en exécutant .ss64script (dot ss64script) et. ss64script (espace de points ss64script)
le premier exécute un fichier caché dans la commande 'ls' (bien que ls -a affiche les fichiers cachés), la seconde option exécutera ss64script même s'il n'a pas été défini comme exécutable avec chmod.
TL; DR
Le point est identique à la commande source.
source est une commande Unix qui évalue le fichier suivant la commande en tant que liste de commandes exécutées dans le contexte actuel.