> Am 28.06.2016 um 18:10 schrieb Eric Blake <[email protected]>: > > On 06/28/2016 10:06 AM, Eric Blake wrote: >> On 06/28/2016 10:00 AM, Reuti wrote: >> >>>> I mention this because the 'ssh-agent' man page has a bug: it suggests: >>>> >>>> eval `ssh-agent -s` >>>> >>>> which BREAKS if any of the environment variables thus output contain >>>> whitespace. It should be: >>>> >>>> eval "`ssh-agent -s`" >>> >>> I don't see this, You mean instead of "SSH_AUTH_SOC" it's named "SSH AUTH >>> SOC" which wouldn't be allowed? What would break exactly as there are >>> already multiple lines output? >> >> $ mkdir '/tmp/with spaces' >> $ TMPDIR='/tmp/with spaces/' ssh-agent -s >> SSH_AUTH_SOCK=/tmp/with spaces//ssh-kJTBa5h6m7pC/agent.20407; export > > As it is, ssh-agent is broken for not outputting: > > SSH_AUTH_SOCK='/tmp/with spaces//...' > > but my point remains that if ssh-agent were fixed, it is the difference > between executing this with an unquoted eval: > > SSH_AUTH_SOCK="'/tmp with'" spaces//... > > vs. the intended version: > > SSH_AUTH_SOCK='/tmp/with spaces//...'
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
signature.asc
Description: Message signed with OpenPGP using GPGMail
