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

[Eli Zaretskii]

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:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15718>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/