Pourquoi faut-il éviter d'utiliser eval en Bash, et que dois-je utiliser à la place ?

Question

À maintes reprises, je vois des réponses de Bash sur Stack Overflow utilisant eval et les réponses sont critiquées, avec un jeu de mots, pour l'utilisation d'une construction aussi "mauvaise". Pourquoi est-ce que eval si maléfique ?

Si eval ne peut pas être utilisé en toute sécurité, que dois-je utiliser à la place ?

Answer 1

Ce problème est plus complexe qu'il n'y paraît. Commençons par l'évidence : eval a le potentiel d'exécuter des données "sales". Les données sales sont toutes les données qui n'ont pas été réécrites en tant que données sûres à utiliser dans la situation XYZ ; dans notre cas, il s'agit de toute chaîne de caractères qui n'a pas été formatée de manière à être sûre pour l'évaluation.

L'assainissement des données semble facile à première vue. En supposant qu'il s'agisse d'une liste d'options, bash fournit déjà un excellent moyen d'assainir les éléments individuels, et un autre moyen d'assainir le tableau entier comme une seule chaîne :

function println
{
    # Send each element as a separate argument, starting with the second element.
    # Arguments to printf:
    #   1 -> "$1\n"
    #   2 -> "$2"
    #   3 -> "$3"
    #   4 -> "$4"
    #   etc.

    printf "$1\n" "${@:2}"
}

function error
{
    # Send the first element as one argument, and the rest of the elements as a combined argument.
    # Arguments to println:
    #   1 -> '\e[31mError (%d): %s\e[m'
    #   2 -> "$1"
    #   3 -> "${*:2}"

    println '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit "$1"
}

# This...
error 1234 Something went wrong.
# And this...
error 1234 'Something went wrong.'
# Result in the same output (as long as $IFS has not been modified).

Disons maintenant que nous voulons ajouter une option pour rediriger la sortie comme argument de println. Nous pourrions, bien sûr, rediriger la sortie de println à chaque appel, mais pour les besoins de l'exemple, nous ne le ferons pas. Nous aurons besoin d'utiliser eval puisque les variables ne peuvent pas être utilisées pour rediriger la sortie.

function println
{
    eval printf "$2\n" "${@:3}" $1
}

function error
{
    println '>&2' '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit $1
}

error 1234 Something went wrong.

Ça a l'air bien, non ? Le problème est que eval analyse deux fois la ligne de commande (dans n'importe quel shell). Au premier passage de l'analyse, une couche de citations est supprimée. Une fois les guillemets supprimés, le contenu de certaines variables est exécuté.

Nous pouvons résoudre ce problème en laissant l'expansion de la variable s'effectuer dans le fichier eval . Il suffit de tout mettre entre guillemets, en laissant les guillemets doubles où ils sont. Une exception : nous devons étendre la redirection avant de eval donc cela doit rester en dehors des guillemets :

function println
{
    eval 'printf "$2\n" "${@:3}"' $1
}

function error
{
    println '&2' '\e[31mError (%d): %s\e[m' "$1" "${*:2}"
    exit $1
}

error 1234 Something went wrong.

Cela devrait fonctionner. C'est également sûr tant que $1 sur println n'est jamais sale.

Maintenant, attendez juste un moment : J'utilise ce même non coté que nous utilisions à l'origine avec sudo tout le temps ! Pourquoi ça marche là-bas, et pas ici ? Pourquoi avons-nous dû tout mettre entre guillemets ? sudo est un peu plus moderne : il sait qu'il doit mettre entre guillemets chaque argument qu'il reçoit, bien que ce soit une simplification excessive. eval concatène simplement tout.

Malheureusement, il n'existe pas de solution de remplacement pour eval qui traite les arguments comme sudo fait, comme eval est un shell intégré ; ceci est important, car il prend l'environnement et la portée du code environnant lorsqu'il s'exécute, plutôt que de créer une nouvelle pile et une nouvelle portée comme le fait une fonction.

Alternatives à l'évaluation

Les cas d'utilisation spécifiques présentent souvent des alternatives viables à eval . Voici une liste pratique. command représente ce que vous enverriez normalement à eval ; remplacez-la par ce que vous voulez.

No-op

Un simple deux-points n'est pas une option dans bash :

:

Créer un sous-shell

( command )   # Standard notation

Exécuter la sortie d'une commande

Ne vous fiez jamais à une commande extérieure. Vous devez toujours avoir le contrôle de la valeur de retour. Mettez-les sur leurs propres lignes :

$(command)   # Preferred
`command`    # Old: should be avoided, and often considered deprecated

# Nesting:
$(command1 "$(command2)")
`command "\`command\`"`  # Careful: \ only escapes $ and \ with old style, and
                         # special case \` results in nesting.

Redirection basée sur une variable

Dans le code d'appel, la carte &3 (ou tout ce qui est supérieur à &2 ) à votre cible :

exec 3<&0         # Redirect from stdin
exec 3>&1         # Redirect to stdout
exec 3>&2         # Redirect to stderr
exec 3> /dev/null # Don't save output anywhere
exec 3> file.txt  # Redirect to file
exec 3> "$var"    # Redirect to file stored in $var--only works for files!
exec 3<&0 4>&1    # Input and output!

Si c'était un appel unique, vous n'auriez pas à rediriger l'ensemble du shell :

func arg1 arg2 3>&2

Dans la fonction appelée, rediriger vers &3 :

command <&3       # Redirect stdin
command >&3       # Redirect stdout
command 2>&3      # Redirect stderr
command &>&3      # Redirect stdout and stderr
command 2>&1 >&3  # idem, but for older bash versions
command >&3 2>&1  # Redirect stdout to &3, and stderr to stdout: order matters
command <&3 >&4   # Input and output!

L'indirection des variables

Scénario :

VAR='1 2 3'
REF=VAR

Mauvais :

eval "echo \"\$$REF\""

Pourquoi ? Si REF contient un guillemet double, le code sera cassé et ouvert aux exploits. Il est possible d'assainir REF, mais c'est une perte de temps lorsque vous avez cela :

echo "${!REF}"

C'est vrai, bash a intégré l'indirection des variables à partir de la version 2. C'est un peu plus délicat que eval si vous voulez faire quelque chose de plus complexe :

# Add to scenario:
VAR_2='4 5 6'

# We could use:
local ref="${REF}_2"
echo "${!ref}"

# Versus the bash < 2 method, which might be simpler to those accustomed to eval:
eval "echo \"\$${REF}_2\""

Quoi qu'il en soit, la nouvelle méthode est plus intuitive, même si elle ne semble pas l'être pour les programmateurs expérimentés qui ont l'habitude de eval .

Tableaux associatifs

Les tableaux associatifs sont implémentés intrinsèquement dans bash 4. Un seul bémol : ils doivent être créés en utilisant declare .

declare -A VAR   # Local
declare -gA VAR  # Global

# Use spaces between parentheses and contents; I've heard reports of subtle bugs
# on some versions when they are omitted having to do with spaces in keys.
declare -A VAR=( ['']='a' [0]='1' ['duck']='quack' )

VAR+=( ['alpha']='beta' [2]=3 )  # Combine arrays

VAR['cow']='moo'  # Set a single element
unset VAR['cow']  # Unset a single element

unset VAR     # Unset an entire array
unset VAR[@]  # Unset an entire array
unset VAR[*]  # Unset each element with a key corresponding to a file in the
              # current directory; if * doesn't expand, unset the entire array

local KEYS=( "${!VAR[@]}" )  # Get all of the keys in VAR

Dans les anciennes versions de bash, vous pouvez utiliser l'indirection des variables :

VAR=( )  # This will store our keys.

# Store a value with a simple key.
# You will need to declare it in a global scope to make it global prior to bash 4.
# In bash 4, use the -g option.
declare "VAR_$key"="$value"
VAR+="$key"
# Or, if your version is lacking +=
VAR=( "$VAR[@]" "$key" )

# Recover a simple value.
local var_key="VAR_$key"       # The name of the variable that holds the value
local var_value="${!var_key}"  # The actual value--requires bash 2
# For < bash 2, eval is required for this method.  Safe as long as $key is not dirty.
local var_value="`eval echo -n \"\$$var_value\""

# If you don't need to enumerate the indices quickly, and you're on bash 2+, this
# can be cut down to one line per operation:
declare "VAR_$key"="$value"                         # Store
echo "`var_key="VAR_$key" echo -n "${!var_key}"`"   # Retrieve

# If you're using more complex values, you'll need to hash your keys:
function mkkey
{
    local key="`mkpasswd -5R0 "$1" 00000000`"
    echo -n "${key##*$}"
}

local var_key="VAR_`mkkey "$key"`"
# ...

Answer 2

Comment faire eval sûr

eval peut peut être utilisé en toute sécurité - mais tous ses arguments doivent être cités au préalable. Voici comment procéder :

Cette fonction qui le fera pour vous :

function token_quote {
  local quoted=()
  for token; do
    quoted+=( "$(printf '%q' "$token")" )
  done
  printf '%s\n' "${quoted[*]}"
}

Exemple d'utilisation :

Étant donné une entrée utilisateur non fiable :

% input="Trying to hack you; date"

Construit une commande à évaluer :

% cmd=(echo "User gave:" "$input")

Evaluez-le, avec apparemment citation correcte :

% eval "$(echo "${cmd[@]}")"
User gave: Trying to hack you
Thu Sep 27 20:41:31 +07 2018

Notez que vous avez été piraté. date a été exécuté plutôt que d'être imprimé littéralement.

Au lieu de cela, avec token_quote() :

% eval "$(token_quote "${cmd[@]}")"
User gave: Trying to hack you; date
%

eval n'est pas mauvais - il est juste mal compris :)

Answer 3

Je vais diviser cette réponse en deux parties qui, je pense, couvrent une grande partie des cas où les gens tendent à être tentés par eval :

1. Exécution de commandes construites de manière étrange
2. Manipulation de variables nommées dynamiquement

Exécution de commandes construites de manière étrange

Beaucoup, beaucoup de fois, simple tableaux indexés sont suffisants, à condition de prendre les bonnes habitudes concernant les guillemets doubles pour protéger les expansions lors de la définition du tableau.

# One nasty argument which must remain a single argument and not be split:
f='foo bar'
# The command in an indexed array (use `declare -a` if you really want to be explicit):
cmd=(
    touch
    "$f"
    # Yet another nasty argument, this time hardcoded:
    'plop yo'
)
# Let Bash expand the array and run it as a command:
"${cmd[@]}"

Cela créera foo bar y plop yo (deux fichiers, pas quatre).

Notez que parfois il peut produire des scripts plus lisibles en mettant juste les arguments (ou un tas d'options) dans le tableau (au moins vous savez au premier coup d'œil ce que vous exécutez) :

touch "${args[@]}"
touch "${opts[@]}" file1 file2

En prime, les tableaux vous permettent, facilement :

1. Ajouter des commentaires sur un argument spécifique :

   cmd=(

   Important because blah blah:

   -v

   )

2. Regroupez les arguments pour en faciliter la lecture en laissant des lignes vides dans la définition du tableau.

3. Commentez des arguments spécifiques à des fins de débogage.

4. Ajoutez des arguments à votre commande, parfois de manière dynamique en fonction de conditions spécifiques ou dans des boucles :

   cmd=(myprog) for f in foo bar do cmd+=(-i "$f") done if [[ $1 = yo ]] then cmd+=(plop) fi to_be_added=(one two 't h r e e') cmd+=("${to_be_added[@]}")

5. Définir les commandes dans les fichiers de configuration tout en autorisant les arguments contenant des espaces définis par la configuration :

   readonly ENCODER=(ffmpeg -blah --blah 'yo plop')

   Deprecated:

   readonly ENCODER=(avconv -bloh --bloh 'ya plap')

   […]

   "${ENCODER[@]}" foo bar

6. Enregistrez une commande exécutable de manière robuste, qui représente parfaitement ce qui est en train d'être exécuté, en utilisant la fonction printf. %q :

   function please_log_that { printf 'Running:'

   From help printf:

   # “The format is re-used as necessary to consume all of the arguments.”
   # From `man printf` for %q:
   # “printed in a format that can be reused as shell input,
   # escaping  non-printable  characters with the proposed POSIX $'' syntax.”
   printf ' %q' "$@"
   echo

   }

   arg='foo bar' cmd=(prog "$arg" 'plop yo' $'arg\nnewline\tand tab') please_log_that "${cmd[@]}"

   “Running: prog foo\ bar plop\ yo $'arg\nnewline\tand tab'”

   You can literally copy and paste that to a terminal and get the same execution.

7. Profitez d'une meilleure coloration syntaxique qu'avec eval puisque vous n'avez pas besoin d'imbriquer des guillemets ou d'utiliser des $ -qui "ne seront pas évalués tout de suite mais le seront à un moment donné".

Pour moi, le principal avantage de cette approche (et à l'inverse l'inconvénient de eval ) est que vous pouvez suivre la même logique que d'habitude concernant la citation, l'expansion, etc. Il n'est pas nécessaire de se creuser la tête pour essayer de mettre des guillemets entre guillemets "à l'avance" tout en essayant de savoir quelle commande interprétera quelle paire de guillemets à quel moment. Et bien sûr, beaucoup des choses mentionnées ci-dessus sont plus difficiles ou carrément impossibles à réaliser avec eval .

Avec ceux-ci, je n'ai jamais eu à compter sur eval au cours des six dernières années environ, et la lisibilité et la robustesse (en particulier en ce qui concerne les arguments qui contiennent des espaces) ont sans doute été améliorées. Vous n'avez même pas besoin de savoir si IFS a été tempéré avec ! Bien sûr, il y a toujours des cas limites où eval pourrait être nécessaire (je suppose, par exemple, si l'utilisateur doit être capable de fournir un morceau complet de script via une invite interactive ou autre), mais j'espère que ce n'est pas quelque chose que vous rencontrerez quotidiennement.

Manipulation de variables nommées dynamiquement

declare -n (ou ses fonctions internes local -n ), ainsi que ${!foo} font l'affaire la plupart du temps.

$ help declare | grep -- -n
      -n    make NAME a reference to the variable named by its value

Eh bien, ce n'est pas exceptionnellement clair sans un exemple :

declare -A global_associative_array=(
    [foo]=bar
    [plop]=yo
)

# $1    Name of global array to fiddle with.
fiddle_with_array() {
    # Check this if you want to make sure you’ll avoid
    # circular references, but it’s only if you really
    # want this to be robust.
    # You can also give an ugly name like “__ref” to your
    # local variable as a cheaper way to make collisions less likely.
    if [[ $1 != ref ]]
    then
        local -n ref=$1
    fi

    printf 'foo  %s\nplop  %s\n' "${ref[foo]}" "${ref[plop]}"
}

# Call the function with the array NAME as argument,
# not trying to get its content right away here or anything.
fiddle_with_array global_associative_array

# This will print:
# foo  bar
# plop  yo

(J'adore cette astuce car elle me donne l'impression de passer des objets à mes fonctions, comme dans un langage orienté objet. Les possibilités sont époustouflantes).

Quant à ${!…} (qui obtient la valeur de la variable nommée par une autre variable) :

foo=bar
plop=yo

for var_name in foo plop
do
    printf '%s = %q\n' "$var_name" "${!var_name}"
done

# This will print:
# foo = bar
# plop = yo