Pete Nelson <petiep...@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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
