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?
--
