bug with Windows interface: echo. in command only works when redirected

[Mark Galeck (CW)]

Hello,  I asked for help on this issue (with GNU make on Windows) on the 
help-make list, and Paul Smith says, this is a bug.  I am using WinXP Pro, SP3. 
 Here is an SSCCE:  

makefile:
-------------------------
SHELL=cmd.exe
foobar:
                @echo.>foo
------------------------

gives me:
C:\tmp>make foobar

C:\tmp>


However, this one:

makefile:
-------------------------
SHELL=cmd.exe
foobar:
                @echo.
------------------------

gives:

C:\tmp>make foobar
process_begin: CreateProcess(NULL, echo., ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [foobar] Error 2


Here's what Paul says:  

" 

I'd guess that this is due to make's fast path processing: if make can 
determine that the command you're invoking does not need a shell, it won't 
start one; instead it will simply try to invoke the command directly.

In this case, the command "echo." is not known to make as a command that 
requires a shell, so it tries to run it directly.  In reality this is not a 
real command but rather a builtin command for the Windows shell (for example 
command.com), so trying to invoke it directly fails.

On the other hand, when you run "echo.>foo" make sees the redirection
(">") and understands that this is not a simple command and can't be run using 
the fast path, so it invokes the shell to run it and it works.

(...)

It's not in the manual because it's supposed to be invisible to the user (that 
is, it's an implementation detail, not a user-visible feature, and so not 
documented in the user manual).  The idea is to improve performance by avoiding 
an extra (and sometimes costly) shell invocation in situations where it can be 
shown that the results are the same either way.

If it's visible to the user, as it is in this case, then there's a bug in the 
fast path processing.

" (end of quotes from Paul)


Mark