Re: "exit" doesn't work from inside of PIPED read block
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 No pipeline there and so that is done in the current shell. Bob
Re: read doesn't work with piped stdin
Blaine Simpson wrote: > read silently fails when stdin is piped to it. -u switch does > not help. Redirection works fine. Same as the other problem with exit in a pipeline. Pipelines operate in subshells. Environment variables are local to the process. Please see question E4 in the bash FAQ for more information. http://www.gnu.org/software/bash/ Bob
Re: read doesn't work with piped stdin
> Description: > read silently fails when stdin is piped to it. -u switch does not > help. > Redirection works fine. > This and your other bug result from the fact that the commands in the pipe run in subshells. echo foo | read # doesn't work because a subshell cannot modify the parent process echo foo | exit # only exits the subshell exit < file # works because the redirection doesn't create a subshell read var <<< foo # again no subshell here It's the same thing as if you try: (read foo) or (exit foo) see also: http://wooledge.org:8000/BashFAQ#24
Re: "exit" doesn't work from inside of PIPED read block
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? > 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 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 $$"
Re: "exit" doesn't work from inside of PIPED read block
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 $$" > >> >
Re: how could I execute a set of script in a directoy tree?
3x for your patience. i find the infomation i want. 3x again :) On Sat, 2007-11-17 at 05:34 -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to 龙海涛 on 11/16/2007 11:21 PM: > > two more questions: > > 1.about syntax (r "$d") > > i didn't find any introduction in 'info bash'. could you tell me how > > could find the explanation of '( )'? > > Search for the term subshell. > > > > > 2.about synax "find /testcase -name autotest.sh -perm /111 -execdir > > bash -c ./autotest.sh \;" > > what does the last '\' mean? > > It is quoting the ; so that the shell won't parse it. By itself, ; is a > shell meta-character, but here, you want it to be an argument to find. > Read the find documentation for more about why -execdir requires a literal > ; to end the sequence. You could also have quoted it as '\' or "\\", but > that is more typing. > > - -- > Don't work too hard, make some time for fun as well! > > Eric Blake [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Cygwin) > Comment: Public key at home.comcast.net/~ericblake/eblake.gpg > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHPt/I84KuGfSFAYARApv1AKDO+W3IzC6zEcwmAXLdDYF91uZbOACguf/a > 6GEsYG+ZubAXn1zeBrgn7SM= > =wzir > -END PGP SIGNATURE-
Re: "exit" doesn't work from inside of PIPED read block
Bob Proulx wrote: >>> 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? >> > #!/bin/bash -p > > > 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. > By "all that crap", I meant "All that stuff which is unnecessary for the task at hand." Everything in my environment is useful, but that doesn't mean I want it influencing shell scripts. I write a lot of cross-platform shell scripts for use by other people. It does not do to test these with my own personal customizations. When I am testing base Bash behavior, like in this case, I want to test with a basic Bash environment, not a customized one where personal settings may mask a problem with default Bash behaior, or even be the cause of the problem at hand. If Bash had a setting to not inherit customizations without modifying uid behavior, I wouldn't need to use misleading switches.
