%% Alessandro Vesely <[EMAIL PROTECTED]> writes:

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

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

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

  av>     egrep ^foo $^ | something

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

It may be that the DOS/Windows port does more with this than the UNIX
port; I'm pretty sure there's no need to escape anything in UNIX since
the string is passed directly to the shell with exec().

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[EMAIL PROTECTED]>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32

Reply via email to