Re: exec vs. source spawning piped commands

[Andreas Schwab]

Pete Nelson <petiepooo@gmail.com> writes:

> I'm confused about what exec is doing in this case.
>
> Sample script t:
>
> #!/bin/bash
> echo $0 pid: $$ ppid: $PPID args: $* 1>&2
> if [ -z "$1" ]; then
>   exec $0 first | $0 second
>   echo should not reach here
> fi
>
> output:
>
> $ ./t
> ./t pid: 13746 ppid: 12823 args:
> /home/user/t pid: 13747 ppid: 13746 args: first
> ./t pid: 13748 ppid: 13746 args: second
> should not reach here
>
> Using exec, I would expect the second line (arg: first) to have the same pid
> and ppid, but it forks a new process.

Since the exec command is part of a pipeline, it is always run in a
subshell.

> Using source instead of exec does run the first piped command in the current
> shell process, as expected.

It doesn't really.  The $$ and $PPID variables are not reset when the
shell forks a subshell, even though it is a new process.  By the use of
source you aren't leaving the subshell context, whereas when you run the
script normally (with or without exec) a new shell is executed that
initializes its own $$ and $PPID variables.

> My intention is to give the second piped process the ability to send signals
> to the first using its $PPID variable.

The parent of a pipeline process is always the calling shell.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."