make-alpha
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Handling of the slow path: why do we do it this way?


From: Paul Smith
Subject: Handling of the slow path: why do we do it this way?
Date: Wed, 07 Oct 2009 17:10:16 -0400

Sorry for more email.

I've been looking at the code in job.c that handles the slow path, and I
don't understand why it's being done the way it is.

What happens for the slow path is that we get $(SHELL) and construct a
string containing its expansion, plus " -c ", then we go through the
command line and prepend backslash escapes to every special character
and append that to the string as well.  Then we recurse (this is in
construct_command_argv_internal) on this newly constructed string.  So,
suppose we had a makefile like:

        all: ; @true && echo yes

then the first time we'd call it with the string "true && echo false".
After the first, slow path version of construct_command_argv_internal()
we would call it again recursively, this time with the string:

        "/bin/sh -c true\ \&\&\ echo\ yes"

The recursion does exactly the same parsing on the string we just built
as it did on the original one, but this time since all the special
characters are quoted, we do take the fast path here and end up parsing
that into the arguments "/bin/sh", "-c", and "true && echo yes" as you'd
expect.


But I can't see a reason to go to that trouble?  Once we determine that
the fast path doesn't work, would it work to simply construct a
3-element argv and put the expansion of $(SHELL) in the first, "-c" in
the second, and the string in the third (after handling
backslash/newlines)?  It seems simpler and more straightforward.

The only reason I can see is that the current method allows SHELL to be
set to a value that contains spaces, and have those parsed.  But, if the
value of SHELL contains special characters like quotes, so that the
SECOND string is not able to use the fast path, it breaks anyway
(there's a savannah bug about this).  It seems impossible to allow the
value of SHELL to be itself a value with special shell characters... so
we can use a simple word parser here.  That seems simpler than escaping
the entire string, just so it can be unescaped again during the
recursion.


Anyone have other thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]