make-w32
[Top][All Lists]
Advanced

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

Caret escaping (was: Re: make'ing make-3.18beta4 under mingw/msys...


From: Alessandro Vesely
Subject: Caret escaping (was: Re: make'ing make-3.18beta4 under mingw/msys...
Date: Tue, 03 Jan 2006 14:17:29 +0100
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Paul D. Smith wrote:
%% KJKHyperion <address@hidden> writes:

k> all of them, with the possible exclusion of the change to sh_chars_dos k> (IIRC that controls which strings need to be quoted, but I'm not 100% k> sure. If that's true, the change is correct and needed).

No; the sh_chars_dos string controls whether GNU make runs the command
script using the "fast path" or the "slow path".


Thus, in case the "slow path" is taken, the LINE command should be replaced with
SHELL FLAG ESCAPED-LINE, where:
 SHELL may be either a unixy_shell, cmd.exe or the old command.com,
 FLAG should be -c for unixy_shell or /C otherwise, and
 ESCAPED-LINE should be escaped using backslashes for unixy_shell,
   carets for cmd.exe, or
   no escape at all for the old command.exe.
Then there is a batch_mode_shell flag, which is usually set for cmd.exe
and causes a NOT-SO-ESCAPED-LINE to be written to a temporary batch file.
Should we revise those specs in order to make a smarter use of cmd.exe?

Althought that patch also allowed -jN to be specified w/o unixy_shell,
after Paul's clarifications it seems the "-j"-change does not depend on 
escaping.

Typically, smarter escaping might be required if the command is, say,

   egrep ^foo $^ | something

In that case, cmd.exe eats the caret unless it is escaped as ^^foo;
command.com does not. As a workaround one can escape the command in
the makefile, which then cannot be ported to windows 98.




reply via email to

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