The following one liner illustrates a bug in sh:
$ /bin/bash -c '/bin/bash -cx '\''x=`echo hello`'\''' > @x
++ echo hello
+ x=$'hello\r'
$
The problem is as follows. When a built-in shell command (such as pwd
or echo) is executed within back quotes (or within $(...)) when the
shell's output is redirected to a file, the command produces \r\n at the
end of the line of which only the final \n is removed.
Normally when a command is executed within back quotes, the final line
ending is removed before the result is substituted. That happens here
also, but the difference is that there is still a \r at the end.
When the echo command in the above example is replace by /bin/echo, the
result is correct (i.e. no \r in the assignment to x):
$ /bin/bash -c '/bin/bash -cx '\''x=`/bin/echo hello`'\''' > @x
++ /bin/echo hello
+ x=hello
$
The bug, it seems to me, is that the shell checks that its output is
redirected to a file and that it therefore has to write \r\n at the end
of each line. So far so good. However, when it executes a built-in
command within back quotes, it still uses this knowledge and still
writes \r\n.
It may be relevant that I have Cygwin configured to use DOS line
endings. Also, my Cygwin installation is up-to-date (except for pending
updates to readline). My bash version is 3.2.9-10.
--
Sjoerd Mullender
signature.asc
Description: OpenPGP digital signature
