Re: Broken lisp/Makefile.w32-in

[Eli Zaretskii <eliz@is.elta.co.il>]

On Thu, 5 Sep 2002, Juanma Barranquero wrote:

> On Thu, 5 Sep 2002 07:08:09 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
> > How about if you invoke command.com explicitly, like this:
> > 
> > 	command.com /c for .... >>foo.txt
> 
> I'll have to test it tonight at home, but I don't see how could it work,
> because, as my example .BAT file showed, the bug with "for", "if" and
> redirection happens also in the command line (or at least inside a .BAT
> file) and is not related to nmake.

I'm guessing you are unaware of how ugly things can get with COMMAND.COM 
when redirection of built-in commands and especially batch files is 
involved.  For starters, you cannot redirect output of a batch file
at all(!).  Try it:

  C:\> type foo.bat
  echo Hi there
  C:\> foo > foo.txt
  Hi there
  C:\>

In other words, the output of `echo' still goes to the screen even though 
you've redirected it to foo.txt.  Now try this, and observe the change:

  C:\> command.com /c foo.bat > foo.txt

I suspect that something similar might happen with a FOR loop.

When you invoke "command.com /c ... >>foo.txt", the situation is 
different: here, the subsidiary COMMAND.COM does not redirect any output 
of FOR.  Instead, it is invoked by the parent shell with its stdout 
already redirected to a file.  Since COMMAND.COM is just a program, not a 
batch file or internal command like FOR, redirection of its output works 
much more reliably.