On Wed, February 2, 2005 10:01 am, Boyd Stephen Smith Jr. said: > On Wednesday 02 February 2005 11:59 am, "John Myers" > <[EMAIL PROTECTED]> wrote: >> On Wed, February 2, 2005 1:24 am, Sebastian Flothow said: >> > Am 2. Feb 2005 um 06:35 Uhr schrieb John Myers: >> >> It would keep the connection to the master open, and would also have >> >> a consistent PID (unlike a shell script, which, AFAIK, may not). >> > >> > A shell script itself has a consistent PID. However, any command >> > called within a shell script is assigned a new PID. >> >> That's not entirely true. Subshells are not executed in the same process >> as the script. > > Right, but a subshell *is* another command. It can be just as easily run > from a prompt. Yes, it is, but it is also part of the original line
> >> It won't >> work as variables are substituted by the original shell. Try this >> instead: bash -c '$(echo $(echo $(echo $(echo $(echo $(read))))))' >> suspending it, looking in ps, and counting how many shells you now have >> running. (the bash -c part is so that you _can_ suspend it) > > Or, look at a deeply nested recursive make run by emerge in a bash inside > su - from bash in an xterm in kde. >:) > > init-kdeinit-xterm-bash-su-bash-emerge-ebuild-make-make-make-make-sh-gcc > +as > I know that, but one might wish to be able to use the commands to manipulate the progress data inside a subshell. Thus, we cannot rely on PIDs alone. I can't think of such a situation off the top of my head, but it would be silly to ignore it. Also, one might even need to call the connect command from inside a subshell for some reason. -- [email protected] mailing list
