From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Broken lisp/Makefile.w32-in Date: Thu, 5 Sep 2002 16:57:30 +0200 (IST) Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020905081536.905C.LEKTU@terra.es> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1031238159 32558 127.0.0.1 (5 Sep 2002 15:02:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 15:02:39 +0000 (UTC) Cc: Takaaki.Ota@am.sony.com, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17my9U-0008Sg-00 for ; Thu, 05 Sep 2002 17:02:36 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17myjD-00028e-00 for ; Thu, 05 Sep 2002 17:39:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17myB5-0003gj-00; Thu, 05 Sep 2002 11:04:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17my7K-000348-00 for emacs-devel@gnu.org; Thu, 05 Sep 2002 11:00:22 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17my7D-00033L-00 for emacs-devel@gnu.org; Thu, 05 Sep 2002 11:00:21 -0400 Original-Received: from is.elta.co.il ([199.203.121.2]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17my7C-00032u-00 for emacs-devel@gnu.org; Thu, 05 Sep 2002 11:00:14 -0400 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id QAA18653; Thu, 5 Sep 2002 16:57:30 +0200 (IST) X-Sender: eliz@is Original-To: Juanma Barranquero In-Reply-To: <20020905081536.905C.LEKTU@terra.es> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7553 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7553 On Thu, 5 Sep 2002, Juanma Barranquero wrote: > On Thu, 5 Sep 2002 07:08:09 +0200 (IST), Eli Zaretskii 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.