$ bash --version GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html >
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ uname -a Linux host02 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux 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. All it appears exec does in this case is expand the relative path to a full path. Running it without exec returns the same pattern of pid and ppid values: $ ./t ./t pid: 13766 ppid: 12823 args: ./t pid: 13767 ppid: 13766 args: first ./t pid: 13768 ppid: 13766 args: second should not reach here Using source instead of exec does run the first piped command in the current shell process, as expected. In that case, I would have to replace the last echo line with an exit to meet my intentions: #!/bin/bash echo $0 pid: $$ ppid: $PPID args: $* 1>&2 if [ -z "$1" ]; then source $0 first | $0 second exit fi returns: $ ./t ./t pid: 13792 ppid: 12823 args: ./t pid: 13792 ppid: 12823 args: first ./t pid: 13794 ppid: 13792 args: second My intention is to give the second piped process the ability to send signals to the first using its $PPID variable.
