Date: Sat, 27 Jan 2001 12:17:55 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Michel de Ruiter <Michel AT smr DOT nl>
Message-Id: <6480-Sat27Jan2001121754+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <B0FEA00E82A7D1118BFB00A0CC990278463309@argon.smr.nl> (message
	from Michel de Ruiter on Fri, 26 Jan 2001 18:21:14 +0100)
Subject: Re: Emacs/grep problem
References:  <B0FEA00E82A7D1118BFB00A0CC990278463309 AT argon DOT smr DOT nl>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Michel de Ruiter <Michel AT smr DOT nl>
> Date: Fri, 26 Jan 2001 18:21:14 +0100
> 
> - start emacs -q
> - type M-! (shell-command)
> - type "grep notfound c:/autoexec.bat|wc" and RETs
> 
> The file c:/autoexec.bat should exist, and the string "notfound" should not
> occur in it.
> Emacs replies to me with:
> (Shell command succeeded with no output)
> Instead of:
>       0       0       0

This has nothing to do with either Emacs or Grep.  Try the same
command in a Makefile, and you will see that Make exhibits the same
behavior.  Conclusion: it's our `system' that does this.

And indeed it seems like a ``feature'' in `system': the internal
COMMAND.COM emulator stops a pipe once a program in the pipe exits
with a non-zero status.  And Grep exits with a non-zero status if it
doesn't find any matches.  So `wc' in the example above doesn't get
run at all.

To get around this, try this in Emacs:

	M-! command.com /c grep notfound c:/autoexec.bat | wc RET

The funny thing is, this has been in `system' forever, so I wonder
whether there's a good reason for it.  Morten, could you see any such
reason?

I guess I could fix this by keeping the pipe running as long as the
commands return non-negative status.  But this won't solve all the
problems, since a command could legitimately exit with a status of -1,
and we cannot distinguish between -1 returned by a program and -1
returned by _dos_exec and friends.  I don't think it is wise to keep
the pipe running if some command cannot be found or cannot be run, is
it?

Thoughts?