make-w32
[Top][All Lists]
Advanced

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

Re: SHELL


From: Eli Zaretskii
Subject: Re: SHELL
Date: Fri, 03 Jun 2005 21:26:42 +0300

> Date: Fri,  3 Jun 2005 16:45:42 +0000
> From: "Earnie Boyd" <address@hidden>
> Cc: address@hidden
> 
> > I have a VERY simple makefile
> >
> > SHELL = /bin/sh
> >
> 
> Do you have an sh installed?

He most certainly does, as this part of the OP's sessions shows:

> process_begin: CreateProcess((null), echo C:/mingw/bin/sh.exe, ...)
                                            ^^^^^^^^^^^^^^^^^^^
As you see, Make found sh in C:\mingw\bin, otherwise where would that
absolute file name come from?

> > mingw32-make.exe: *** [all] Error 2
> >
> > If sh.exe is in  C:/mingw/bin/sh.exe.
> >
> >
> > Can anyone help explain this?
> >
> 
> CreateProcess needs c:\mingw\bin\sh.exe and mingw32-make doesn't change the
> / to a \.  It was ported to use on makefiles written in win32 style paths. 
> Patches I'm sure would be considered to convert the / to \ for the name of
> the file to spawn.

I think this is not the reason for the problem.  The reason, I think,
is that the function construct_command_argv_internal in job.c has this
snippet:

  #ifdef WINDOWS32
    static char sh_chars_dos[] = "\"|&<>";
    static char *sh_cmds_dos[] = { "break", "call", "cd", "chcp", "chdir", 
"cls",
                               "copy", "ctty", "date", "del", "dir", "echo",
                               "erase", "exit", "for", "goto", "if", "if", "md",
                               "mkdir", "path", "pause", "prompt", "rd", "rem",
                               "ren", "rename", "rmdir", "set", "shift", "time",
                               "type", "ver", "verify", "vol", ":", 0 };
    static char sh_chars_sh[] = "#;\"*?[]&|<>(){}$`^";
    static char *sh_cmds_sh[] = { "cd", "eval", "exec", "exit", "login",
                               "logout", "set", "umask", "wait", "while", "for",
                               "case", "if", ":", ".", "break", "continue",
                               "export", "read", "readonly", "shift", "times",
                               "trap", "switch", "test",
  #ifdef BATCH_MODE_ONLY_SHELL
                   "echo",
  #endif
                   0 };
    char*  sh_chars;
    char** sh_cmds;

As you see, sh_cmds_sh[] doesn't include "echo" unless
BATCH_MODE_ONLY_SHELL is defined.  I'm guessing that
BATCH_MODE_ONLY_SHELL is not defined in the MinGW build, and so Make
doesn't consider "echo" to be a shell builtin.  So it tries to find a
program named "echo", and if echo.exe is not installed, that will
predictably fail with error code of 2, exactly as the OP reported.

One could force Make to run the shell by enclosing $(SHELL) in quotes,
like this:

     @echo "$(SHELL)"

When I do that, the problem disappears, even if I remove echo.exe from
my PATH.

Personally, I don't understand the reason why "echo" is considered a
builtin only under BATCH_MODE_ONLY_SHELL.  Shouldn't we _always_ have
"echo" in the list of built-in commands of a Unixy shell?  Or are
there ported shells that don't have "echo"?  (I'd be surprised if
there are such shells.)

Here's the explanation of why BATCH_MODE_ONLY_SHELL was introduced,
from README.W32:


  GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL):

          Some versions of Bourne shell does not behave well when invoked
          as 'sh -c' from CreateProcess().  The main problem is they seem
          to have a hard time handling quoted strings correctly. This can
          be circumvented by writing commands to be executed to a batch
          file and then executing the command by calling 'sh file'.

          To work around this difficulty, this version of make supports
          a batch mode.  When BATCH_MODE_ONLY_SHELL is defined at compile
          time, make forces all command lines to be executed via script
          files instead of by command line.

          A native Windows32 system with no Bourne shell will also run
          in batch mode.  All command lines will be put into batch files
          and executed via $(COMSPEC) (%COMSPEC%).

I don't see anything here that could shed any light of the special
treatment for "echo".  Do you?




reply via email to

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