The only thing it adds is insecurity.
If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.
sh -c "$1 $2 $3 $4 ..."
sh -c "ls $dir"
That should be:
dir=$(escape "$dir") sh -c "ls $dir"
ls "$dir"
It's similar to ShellShock -- you can argue it was documented behavior, but it's still a security problem.
It's similar to curl CWE-93[1], where it was documented and in-use behavior and consequently was rejected as a security problem.
Example for ssh:
ssh host ls "$(quote "$dir")"
ssh does not unquote. Its the local shell, if you are invoking ssh via execv, this does not apply.
$ printf "%s\n" "asdf" asdf
This happens as part of the shell turning the command string into argument vectors to pass to execv().
ssh foo@bar "echo 'hello world'"
ssh chooses to unquote the string: echo 'hello world'
splitting it into two parts (echo, and hello world), and then running the program echo with the argument hello world.
The fact it does this via a separate program is irrelevant.
wrong, ssh does no argument splitting
> then running the program echo
wrong, it passes the string to the users login shell, whatever program that is. See sshd(8).
> The fact it does this via a separate program is irrelevant
just gently caress yourself.
And research (aka: consulting the manpage) is an essential part of engineering. Doing that would also solve the problem.
The only thing it adds is insecurity.
If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.