Time and time again, I see Bash answers on Stack Overflow using eval and the answers get bashed, pun intended, for the use of such an "evil" construct. Why is eval so evil?
If eval can't be used safely, what should I use instead?
Why should eval be avoided in Bash, and what should I use instead?
How to make
There's more to this problem than meets the eye. We'll start with the obvious: eval has the potential to execute "dirty" data. Dirty data is any data that has not been rewritten as safe-for-use-in-situation-XYZ; in our case, it's any string that has not been formatted so as to be safe for evaluation.
Sanitizing data appears easy at first glance. Assuming we're throwing around a list of options, bash already provides a great way to sanitize individual elements, and another way to sanitize the entire array as a single string:
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).
Now say we want to add an option to redirect output as an argument to println. We could, of course, just redirect the output of println on each call, but for the sake of example, we're not going to do that. We'll need to use eval, since variables can't be used to redirect output.
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.
Looks good, right? Problem is, eval parses twice the command line (in any shell). On the first pass of parsing one layer of quoting is removed. With quotes removed, some variable content gets executed.
We can fix this by letting the variable expansion take place within the eval. All we have to do is single-quote everything, leaving the double-quotes where they are. One exception: we have to expand the redirection prior to eval, so that has to stay outside of the quotes:
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.
This should work. It's also safe as long as $1 in println is never dirty.
Now hold on just a moment: I use that same unquoted syntax that we used originally with sudo all of the time! Why does it work there, and not here? Why did we have to single-quote everything? sudo is a bit more modern: it knows to enclose in quotes each argument that it receives, though that is an over-simplification. eval simply concatenates everything.
Unfortunately, there is no drop-in replacement for eval that treats arguments like sudo does, as eval is a shell built-in; this is important, as it takes on the environment and scope of the surrounding code when it executes, rather than creating a new stack and scope like a function does.
eval Alternatives
Specific use cases often have viable alternatives to eval. Here's a handy list. command represents what you would normally send to eval; substitute in whatever you please.
No-op
A simple colon is a no-op in bash:
:
Create a sub-shell
( command ) # Standard notation
Execute output of a command
Never rely on an external command. You should always be in control of the return value. Put these on their own lines:
$(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 based on variable
In calling code, map &3 (or anything higher than &2) to your target:
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!
If it were a one-time call, you wouldn't have to redirect the entire shell:
func arg1 arg2 3>&2
Within the function being called, redirect to &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!
Variable indirection
Scenario:
VAR='1 2 3'
REF=VAR
Bad:
eval "echo \"\$$REF\""
Why? If REF contains a double quote, this will break and open the code to exploits. It's possible to sanitize REF, but it's a waste of time when you have this:
echo "${!REF}"
That's right, bash has variable indirection built-in as of version 2. It gets a bit trickier than eval if you want to do something more complex:
# 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\""
Regardless, the new method is more intuitive, though it might not seem that way to experienced programmed who are used to eval.
Associative arrays
Associative arrays are implemented intrinsically in bash 4. One caveat: they must be created using 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
In older versions of bash, you can use variable indirection:
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"`"
# ...
I'm missing a mention of
eval "export $var='$val'" ... (?) –
Likely @Likely Chances are that doesn't do what you expect.
export "$var"="$val" is probably what you want. The only time you might use your form is if var='$var2', and you want to double-dereference it--but you shouldn't be trying to do anything like that in bash. If you really must, you can use export "${!var}"="$val". –
Extravaganza I'm actually using
eval "export "$var"=\"\$val\"", I think there is a way to do this in (newer) bash without eval, but I think it's bash-specific. –
Likely @Likely Well, this is specifically for Bourne Again (bash), not Bourne (sh). If you need to do anything like that, then traditional Bourne is definitely the wrong choice of languages. Even bash is pushing it. –
Extravaganza
Execute output of a command: Is it safe? I don't think so, but feel free to correct me... executing $(command) is only safe if command output is safe. If command writes poweroff or reboot or rm -rf / on stdout, then your system goes down. –
Yoder @Yoder That part wasn't really clear. I think what I was attempting to say was that
command should be a function internal to your script; something you have control over, at the very least. That's assuming you must execute the result of a command. It's better than eval because you avoid a lot of escaping issues, but it's still less than ideal. For example, if I need to prefix several lines with a dynamic command, it's better for me to do $(something) command than to run each line through eval. –
Extravaganza I think, it should have been
: $(command) then. This will cause the command to be executed, but the result will be ignored by the : (: is same as true) command. –
Yoder @Yoder No, the intention was still to run the result. –
Extravaganza
Suppose,
x="echo hello world"; Then to execute whatever is contained in x, we can use eval $x However, $($x) is wrong, isn't it? –
Yoder $($x) would execute echo hello world, and then execute hello world. You'd probably want : $($x). Neither of those would be particularly clean because you're not quoting $x; ideally: x=( echo 'hello world' ); : $("${x[@]}") –
Extravaganza @anishsane: For your Suppose,
x="echo hello world"; Then to execute whatever is contained in x, we can use eval $x However, $($x) is wrong, isn't it? Yes: $($x) is wrong because it runs echo hello world and then tries to run the captured output (at least in the contexts where I think you're using it), which will fail unless you've got a program called hello kicking around. –
Lianna Sorry to come back again to this question... I'm having an hard time finding a solution of passing a string with pipe to a function avoiding eval. myexec () { eval $@ ; } If I don't use eval, passing "ls -la /path/to/foo | grep bar" won't work. –
Kenning
@Kenning You can't just remove the
eval keyword? $@ should run fine on its own, I believe, and it won't have many of the caveats of eval. –
Extravaganza @Extravaganza unlucky not, the "| grep bar" is removed from the function arguments list –
Kenning
@Kenning Ah, so you actually want eval functionality. If that's what you want, then you can use eval; just keep in mind that it has a lot of security caveats. It's also a sign that there's a design flaw in your application. –
Extravaganza
@Extravaganza yes, for sure, I'm considering to write other more genric functions to avoid that strings... thanks! –
Kenning
ref="${REF}_2" echo "${!ref}" example is wrong, it will not work as intended since bash substitutes variables before a command is executed. If ref variable is really undefined before, the result of substitution will be ref="VAR_2" echo "", and that's what will be executed. –
Parabolic Nice catch, @YooryN. Fixed. –
Extravaganza
How to make eval safe
eval can be safely used - but all of its arguments need to be quoted first. Here's how:
This function which will do it for you:
function token_quote {
local quoted=()
for token; do
quoted+=( "$(printf '%q' "$token")" )
done
printf '%s\n' "${quoted[*]}"
}
Example usage:
Given some untrusted user input:
% input="Trying to hack you; date"
Construct a command to eval:
% cmd=(echo "User gave:" "$input")
Eval it, with seemingly correct quoting:
% eval "$(echo "${cmd[@]}")"
User gave: Trying to hack you
Thu Sep 27 20:41:31 +07 2018
Note you were hacked. date was executed rather than being printed literally.
Instead with token_quote():
% eval "$(token_quote "${cmd[@]}")"
User gave: Trying to hack you; date
%
eval isn't evil - it's just misunderstood :)
How does the "token_quote" function use its arguments? I can't find any documentation on this feature... –
Shadchan
@Shadchan The
in words part of a for loop is optional. –
Ing I guess I worded it too unclearly. I meant the function arguments. Why is there no
arg="$1"? How does the for loop know which arguments were passed to the function? –
Shadchan I would go further than simply "misunderstood", it's also often misused and really not needed. Zenexer's answer covers a lot of such cases but any use of
eval should be a red flag and closely examined to confirm there really isn't a better option already provided by the language. –
Aldosterone What’s the advantage of this
eval "$(token_quote "${cmd[@]}")" over just writing "${cmd[@]}"? Bash is able to expand the array itself and run the resulting command; I get the correct output, here. –
Underpinnings Edit: I went ahead and turned my “just let the array be expanded” into a full-fledged answer, because why not. –
Underpinnings
@Shadchan
for foo is equivalent to for foo in "$@", hence for foo in "$1" … "$n". –
Underpinnings I’ll split this answer in two parts, which, I think, cover a large proportion of the cases where people tend to be tempted by eval:
- Running weirdly built commands
- Fiddling with dynamically named variables
Running weirdly built commands
Many, many times, simple indexed arrays are enough, provided that you take on good habits regarding double quotes to protect expansions while defining the array.
# 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[@]}"
This will create foo bar and plop yo (two files, not four).
Note that sometimes it can produce more readable scripts to put just the arguments (or a bunch of options) in the array (at least you know at first glance what you’re running):
touch "${args[@]}"
touch "${opts[@]}" file1 file2
As a bonus, arrays let you, easily:
- Add comments about a specific argument:
cmd=(
# Important because blah blah:
-v
)
- Group arguments for readability by leaving blank lines within the array definition.
- Comment out specific arguments for debugging purposes.
- Append arguments to your command, sometimes dynamically according to specific conditions or in loops:
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[@]}")
- Define commands in configuration files while allowing for configuration-defined whitespace-containing arguments:
readonly ENCODER=(ffmpeg -blah --blah 'yo plop')
# Deprecated:
#readonly ENCODER=(avconv -bloh --bloh 'ya plap')
# […]
"${ENCODER[@]}" foo bar
- Log a robustly runnable command, that perfectly represents what is being run, using printf’s
%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.
- Enjoy better syntax highlighting than with
evalstrings, since you don’t need to nest quotes or use$-s that “will not be evaluated right away but will be at some point”.
To me, the main advantage of this approach (and conversely disadvantage of eval) is that you can follow the same logic as usual regarding quotation, expansion, etc. No need to rack your brain trying to put quotes in quotes in quotes “in advance” while trying to figure out which command will interpret which pair of quotes at which moment. And of course many of the things mentioned above are harder or downright impossible to achieve with eval.
With these, I never had to rely on eval in the past six years or so, and readability and robustness (in particular regarding arguments that contain whitespace) were arguably increased. You don’t even need to know whether IFS has been tempered with! Of course, there are still edge cases where eval might actually be needed (I suppose, for example, if the user has to be able to provide a full fledged piece of script via an interactive prompt or whatever), but hopefully that’s not something you’ll come across on a daily basis.
Fiddling with dynamically named variables
declare -n (or its within-functions local -n counterpart), as well as ${!foo}, do the trick most of the time.
$ help declare | grep -- -n
-n make NAME a reference to the variable named by its value
Well, it’s not exceptionally clear without an example:
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
(I love this trick ↑ as it makes me feel like I’m passing objects to my functions, like in an object-oriented language. The possibilities are mind-boggling.)
As for ${!…} (which gets the value of the variable named by another 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
© 2022 - 2024 — McMap. All rights reserved.
evalthat may be bad; see vidarholen.net/contents/blog/?p=716 for some other examples. There are many shell constructs that end up being evaled, expanded, etc. and focussing only on eval is bad as it creates a false sense of security. It's important to understand the risk of working with any untrusted data and how it could be exploited. That said, a good SO answer should assume untrusted external data or at least warn of the possible pitfalls, so I tend to agree on the bashing, except maybe thatevalis being unfairly picked by a large amount. – Glovskyevalis often very easy to replace with another approach – which in some cases even simply consists in running the command directly without resorting to a string – so it’s worth yelling at it. Absolutely wanting to useevaloften leads to overkill things, like that answer on that page that converts a whole array into another array (and then to a string) when the initial array could have been used directly to run the command with the same amount of safety and withouteval, AFAICT. – Underpinnings