La différence la plus importante entre
bash -c "$1"
Et
eval "$1"
Est-ce que le premier fonctionne dans un sous-shell et le second ne le fait pas. Alors:
set -- 'var=something'
bash -c "$1"
echo "$var"
SORTIE:
#there doesn't seem to be anything here
set -- 'var=something'
eval "$1"
echo "$var"
SORTIE:
something
Je ne sais pas pourquoi quelqu'un utiliserait jamais l'exécutable bash
de cette manière, cependant. Si vous devez l’appeler, utilisez l’intégration garantie POSIX sh
. Ou (subshell eval)
si vous souhaitez protéger votre environnement.
Personnellement, je préfère la coquille .dot
avant tout.
printf 'var=something%d ; echo "$var"\n' `seq 1 5` | . /dev/fd/0
SORTIE
something1
something2
something3
something4
something5
Mais en avez-vous besoin?
En réalité, la seule cause à utiliser est le cas où votre variable en attribue ou en évalue une autre, ou le fractionnement des mots est important pour la sortie.
Par exemple:
var='echo this is var' ; $var
SORTIE:
this is var
Cela fonctionne, mais seulement parce echo
que peu importe le nombre d'arguments.
var='echo "this is var"' ; $var
SORTIE:
"this is var"
Voir? Les doubles guillemets arrivent car le résultat de l'expansion du shell de $var
n'est pas évalué quote-removal
.
var='printf %s\\n "this is var"' ; $var
SORTIE:
"this
is
var"
Mais avec eval
ou sh
:
var='echo "this is var"' ; eval "$var" ; sh -c "$var"
SORTIE:
this is var
this is var
Lorsque nous utilisons eval
ou que sh
le shell passe en revue les résultats des extensions et les évalue également comme une commande potentielle, les guillemets font une différence. Vous pouvez aussi faire:
. <<VAR /dev/fd/0
${var:=echo "this is var"}
#END
VAR
SORTIE
this is var
e='echo foo'; $e
fonctionne très bien.