Date:	Tue, 24 Oct 2000 09:31:58 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash 2.04 beta 6a
In-Reply-To:	<4.3.1.0.20001023205604.00b0edf0@pop5.banet.net>
Message-ID:	<Pine.SUN.3.91.1001024093137.24828H-100000@is>
MIME-Version:	1.0
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

On Mon, 23 Oct 2000, Peter J. Farley III wrote:

> 	open a piped command as a file: "echo #foo|"
> 	read one line from the piped file handle
> 	print the results of the read
> 	close the file handle
> 
> Well, under DJGPP "echo #foo|" produces a blank line from the first 
> read, rather than just "#foo".  When I patched the test to use the 
> modified command "echo \\#foo|", then the first read got "#foo" as a 
> result.

Sorry for asking a Perl-illiterate question: What exactly is the
importance of the backslashes in "\\#foo"?  Why does it affect the way
the above snippet works?

Also, can you outline the Perl implementation of this feature, in
terms of libc functions that get called when Perl processes the
command such as "echo #foo|"?

Anyway, my first suspicion would be some kind of buffering problem.
IIRC, the DJGPP port of Perl uses some FSEXT trick for implementing
invocations of external programs in some cases (I forget the details,
or perhaps I never knew them).  If so, it could be that an fflush
and/or an fsync somewhere is what you need to fix this.

You seem to be assuming that this is a Bash problem.  Why do you think
that?  Does Bash 2.03 work with this example?

- Raw text -