[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27495] echo behaves different in pipe for /bin/sh symlinked to das
Paul D. Smith
[bug #27495] echo behaves different in pipe for /bin/sh symlinked to dash
Tue, 22 Sep 2009 13:03:31 +0000
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/2009090216 Ubuntu/8.04 (hardy) Firefox/3.0.14
Update of bug #27495 (project make):
Status: None => Not A Bug
Open/Closed: Open => Closed
Follow-up Comment #1:
Basically what you're seeing is that dash has a builtin echo command, which
behaves differently than the separate echo program in /bin or /usr/bin; this
is not a make issue:
$ /bin/dash -c "/bin/echo 'nhi'"
$ /bin/dash -c "echo 'nhi'"
The reason you're seeing this here is that in the simple case (without
redirection or pipeline) make uses a fast path and avoids the shell
invocation; for performance reasons it simply directly forks/execs the
command. In the second case, with redirection, make sees that it can't use
the fast path and so it actually starts a shell and sends the command line to
that shell. Since the shell has a builtin "echo" which behaves differently
than the separate program "echo", whether make starts a shell or invokes echo
directly leads to different behavior.
There's really nothing make can do about this. According to the POSIX
standard, the "echo" command has implementation-defined results if any operand
contains a backslash, so technically neither the shell's builtin echo nor the
one in /bin are wrong. Also make cannot assume "echo" is a built-in.
If you want to avoid this, you should do one of the following: (a) stop using
echo if the strings to be printed may contain backslashes or the first one
could be "-n"; instead switch to printf(1); or (b) in your makefile, always
use "/bin/echo" instead of "echo"; at least this will be consistent on a given
system (but note that other operating systems may have a /bin/echo that
behaves differently in this context.
Reply to this item at:
Message sent via/by Savannah