[Top][All Lists]

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

[bug #28126] bug with Windows interface: echo. in command only works whe

From: anonymous
Subject: [bug #28126] bug with Windows interface: echo. in command only works when redirected
Date: Mon, 30 Nov 2009 05:03:43 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; MS-RTC LM 8)


                 Summary: bug with Windows interface:  echo. in command only
works when redirected
                 Project: make
            Submitted by: None
            Submitted on: Mon 30 Nov 2009 05:03:42 AM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 3.81
        Operating System: None
           Fixed Release: None
           Triage Status: None



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:  


gives me:
C:\tmp>make foobar


However, this one:



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)



Reply to this item at:


  Message sent via/by Savannah

reply via email to

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