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'"
nhi
$ /bin/dash -c "echo 'nhi'"
hi
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:
<http://savannah.gnu.org/bugs/?27495>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
