Blaine Simpson wrote: > Bob Proulx wrote: > > Please keep the mailing list in the CC so that others may participate > > in the discussion and enable it to be available in the archives.
Grr... This means please do a list reply in your mailer or if list reply is not available then use the followup to all or reply to all action. > >> #!/bin/bash -p > > > > Why are you using the -p option? > > > To prevent possible side effects from inheriting shell functions from > current environment, SHELLOPTS, any settings in $ENV, etc. Why would I > want to have all that crap in my environment if my goal is to test > exactly what I have coded in my script? If you have crap in your environment then you should fix that problem first. It led me to believe that you were trying to run a setuid script or something. > > In another terminal look at the processes running. I used 'ps -efH'. > > Look for pid 8924. > > > > rwp 8924 8923 0 10:10 pts/36 00:00:00 bash > > rwp 1016 8924 0 10:13 pts/36 00:00:00 sleep 123 > > VERY interesting. Thanks very much. Glad to help. Bob Blaine Simpson wrote: > Bob Proulx wrote: > > Please keep the mailing list in the CC so that others may participate > > in the discussion and enable it to be available in the archives. > > > > > >> #!/bin/bash -p > >> > > > > Why are you using the -p option? > > > To prevent possible side effects from inheriting shell functions from > current environment, SHELLOPTS, any settings in $ENV, etc. Why would I > want to have all that crap in my environment if my goal is to test > exactly what I have coded in my script? > >> echo $$ > >> cat /tmp/atf | while read; do echo $$; exit 3; done > >> > > > > In both cases the $$ is expanded by the shell before invoking the > > command. So they get the same pid value, the pid of the parent. > > > > I don't know how to output the pid of the subshell. Perhaps someone > > on the mailing list will have an answer. > > > > You can verify that there is a subshell however. > > > > echo $$ ; echo foo | sleep 123 > > 8924 > > ...sleep 123 now running... > > > > In another terminal look at the processes running. I used 'ps -efH'. > > Look for pid 8924. > > > > rwp 8924 8923 0 10:10 pts/36 00:00:00 bash > > rwp 1016 8924 0 10:13 pts/36 00:00:00 sleep 123 > > > > Bob > > > VERY interesting. Thanks very much. > > Blaine Simpson wrote: > > > >> Thanks for taking the time to answer (both), Bob. Inline reply below. > >> > >> Bob Proulx wrote: > >> > >>> Blaine Simpson wrote: > >>> > >>> > >>>> "exit" doesn't exit the current shell when inside of PIPED read blocks, > >>>> yet everything works find if the input comes from "redirection". > >>>> > >>>> > >>> This is because pipes operate in subshells and the exit applies to the > >>> subshell. Please see the bash FAQ question E4 for more information. > >>> > >>> ftp://ftp.cwru.edu/pub/bash/FAQ > >>> > >>> > >>> > >>>> cat /tmp/atf | while read; do exit 3; done # for any text file > >>>> /tmp/atf > >>>> Yet the following works > >>>> cat /tmp/atf | while read; do exit 3; done > >>>> > >>>> > >>> Those two are the same. You probably meant to say: > >>> > >>> while read; do exit 3; done < /tmp/atf > >>> > >>> > >> Exactly. Copy and paste error from the file where my notes are. > >> > >>> No pipeline there and so that is done in the current shell. > >>> > >>> > >> I thought I had eliminated shelling as the cause because I echo'd $$ in > >> the body (where "exit 3" is above), and it is the same exact pid as the > >> root shell. > >> > >> I'm attaching the test script. > >> > >>> Bob > >>> > >>> > > > > > >> #!/bin/bash -p > >> > >> echo $$ > >> cat /tmp/atf | while read; do echo $$; exit 3; done > >> > >> # WORKS: > >> #while read; do exit 3; done < /tmp/atf > >> > >> echo "Post in $$" > >> >
