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
>> exact
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 introduc
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
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
> 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
pa
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
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 mor
