Re: A note for read builtin

[John Reiser]

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
  [snip]
> 
> 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/^/    /'
  [snip]
> 
> 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?

--