Re: dircolors man page should mention proper quoting

[Eduardo A . Bustamante López]

On Tue, Jun 28, 2016 at 06:50:21PM +0200, Reuti wrote:
[...]
> Ok, I see the point in ssh-agent not including the single quotation marks. 
> But enclosing the complete output across several lines into quotation marks 
> doesn't seem to change anything:
> 
> $ unset sock
> $ cat foo.sh
> echo -n sock=\'xx xx/baz\'\;' '
> echo export sock\;
> $ ./foo.sh
> sock='xx xx/baz'; export sock;
> $ eval `./foo.sh`
> $ echo $sock
> xx xx/baz
> $ unset sock
> $ eval "`./foo.sh`"
> $ echo $sock
> xx xx/baz
> 
> -- Reuti
> 

There are two problems here:

(1) You're testing with single spaces, which will give you the false idea of
correctness.
(2) You're outputting with 'echo $sock', so it doesn't matter if you quoted the
eval, you're using an unquoted expansion to prove both are the same.

Here's a clearer example:

    dualbus@hp ~ % cat a
    x='a  b  c'

    dualbus@hp ~ % eval $(cat a); declare -p x
    typeset x='a b c'

    dualbus@hp ~ % eval "$(cat a)"; declare -p x
    typeset x='a  b  c'

In case it's not evident, there are *two* spaces separating a, b and c.

When the shell expands $(cat a), it will use IFS to split the resulting string
into multiple tokens, so eval will see:

<eval> <x='a> <b> <c'>

With <...> representing a token.

Which will be reconstructed and interpreted as: x='a b c' (single spaces).

When you quote correctly (i.e. "$(cat a)"), the shell will not perform such IFS
splitting, so eval will see:

<eval> <x='a  b  c'>, storing the correct value in x.

When you do: echo $sock, it has the same problem. Even if sock had the proper
value stored due to using quotes, the unquoted $sock will be subject of word
splitting.

Read more about word splitting here: http://mywiki.wooledge.org/WordSplitting

Or consult the "Word Splitting" in the bash manual.

-- 
Eduardo Bustamante
https://dualbus.me/