[Top][All Lists]

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

Re: A note for read builtin

From: John Reiser
Subject: Re: A note for read builtin
Date: Fri, 18 Jun 2010 08:20:50 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4

On 06/18/2010 07:05 AM, Dr. Werner Fink wrote:
> Just a remark about the sub shell usage in bash in comparision to
> ksh.  Let's try:
>     strace -f -o bash.strace bash -c 'echo a b | read a b'
>     > grep -E 'execve|clone|write\(1|read\(0' bash.strace
> and now the same with the Korn shell
>     strace -f -o ksh.strace ksh -c 'echo a b | read a b'
>     > grep -E 'execve|clone|write\(1|read\(0' ksh.strace | sed 's/^/    /'
> 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.

Running   strace -f -o ksh.strace ksh -c 'echo a b | cat'
shows that ksh requires a subprocess/shell for the 'cat'
which is the final command in _that_ pipe sequence.

Apparently ksh knows when the final command in a pipe sequence
is a shell builtin, then omits the subprocess in that case.

Could bash's $PIPE_STATUS[] or related issues about control,
environment, and history ("trap", etc.) be relevant here?


reply via email to

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