[Top][All Lists]

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

Re: A note for read builtin

From: Dr. Werner Fink
Subject: Re: A note for read builtin
Date: Wed, 23 Jun 2010 10:00:12 +0200
User-agent: Mutt/1.5.9i

On Tue, Jun 22, 2010 at 04:50:54PM -0400, Chet Ramey wrote:
> On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
> > as now is visible the last command in the pipe sequence done
> > in the bash is a real sub process whereas in the ksh it is not.
> > 
> > The question rises: Why does the bash require a sub peocess/shell
> > for the final command of a pipe sequence.
> It's an implementation decision: the code as it exists today is more
> straightforward.  Since Posix requires that all commands in a pipeline
> be executed in a subshell environment, though it allows the ksh behavior
> as an extension, there's been no requirement to change it.
> If anyone would like to take a shot at changing the code to not fork when
> executing a command with a pipe for stdin, I'd be glad to take a look at
> the result.

OK ... after a deeper look into execute_cmd.c I'd like to suggest
something like in the attachment.  Anyone around with a better
solution? Maybe there is a way to emulate the first pipe commands
as a named fifo for the last element of the pipe which may avoid
moving stdin around.  Anyway the patch makes things like:

 bash/bash-4.1> ./bash -c 'echo a b | while read x y; do a=$x b=$y; done; echo 
$a $b'
 a b
 bash/bash-4.1> ./bash -c 'echo a b | read a b ; echo $a $b'
 a b

work.  The change of sh_coproc is simply to avoid a (correct)
compiler warning.


  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

Attachment: bash-4.1-pipe.dif
Description: Text Data

reply via email to

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