[Top][All Lists]

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

[bug #15718] Weird behavior of the SHELL variable on Win32

From: Eli Zaretskii
Subject: [bug #15718] Weird behavior of the SHELL variable on Win32
Date: Sat, 4 Mar 2006 16:46:27 +0200
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Follow-up Comment #14, bug #15718 (project make):

Paul is right: the Windows port does not invoke cmd.exe with the -c switch. 
So there's no bug here and nothing to fix.

Here are the gory details:

If you look closer at job.c:construct_command_argv_internal, you will see
that, in the `slow' case, if the shell is not a Unixy shell, the code creates
a temporary batch file via the call to create_batch_file.  It then writes to
that batch file the actual command, but without the shell name and the -c
switch (it uses command_ptr which was set past the shell name and -c).  Next,
it creates new_argv[] whose zeroth member is the name of the batch file.  This
new_arg[] array is then passed (under the name argv[]) to process_easy, which
simply calls CreateProcess to run the batch file.  The OS will then invoke
the shell to do that.

So there's no -c switch passed to cmd.exe nowhere in sight.

Btw, when you type "cmd -c echo hello", cmd.exe doesn't _ignore_ that, it
actually invokes another copy of cmd.exe (that's why you see the Windows
banner).  Type "exit" to return to your original shell.

If you still think there's a bug related to working with cmd.exe in a
Makefile, please show a test case where it fails.  AFAIK, the current release
candidate code supports cmd.exe with no problems.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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