On Thu, Jun 24, 2010 at 01:18:25PM -0400, Chet Ramey wrote:
> On 6/23/10 6:08 AM, Dr. Werner Fink wrote:
>
> > Yet an other version of the patch to avoid trouble with the
> > coproc builtin tested out in tests/coproc.tests. There is one
> > difference more with tests/redir.tests at
>
> Thanks, t
On 6/23/10 6:08 AM, Dr. Werner Fink wrote:
> Yet an other version of the patch to avoid trouble with the
> coproc builtin tested out in tests/coproc.tests. There is one
> difference more with tests/redir.tests at
Thanks, this is a great start. There's still more work to be done with
bookkeeping
On Wed, Jun 23, 2010 at 12:08:20PM +0200, Werner Fink wrote:
>
> Yet an other version of the patch to avoid trouble with the
> coproc builtin tested out in tests/coproc.tests. There is one
> difference more with tests/redir.tests at
>
> exit 3 | $EXIT > $TMPDIR/null-redir-e
> echo $? -- ${pi
On Wed, Jun 23, 2010 at 10:00:12AM +0200, Werner Fink wrote:
> On Tue, Jun 22, 2010 at 04:50:54PM -0400, Chet Ramey wrote:
> > On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
> >
> > > as now is visible the last command in the pipe sequence done
> > > in the bash is a real sub process whereas in the k
On Tue, Jun 22, 2010 at 04:50:54PM -0400, Chet Ramey wrote:
> On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
>
> > as now is visible the last command in the pipe sequence done
> > in the bash is a real sub process whereas in the ksh it is not.
> >
> > The question rises: Why does the bash require a
On 6/18/10 10:05 AM, Dr. Werner Fink wrote:
> as now is visible the last command in the pipe sequence done
> in the bash is a real sub process whereas in the ksh it is not.
>
> The question rises: Why does the bash require a sub peocess/shell
> for the final command of a pipe sequence.
It's an i
RESEND FOR THE MAILINGLIST
Britton Kerin schrieb:
Which in a pipeline is supposed to be the output of the previous command, right?
Its not at all obvious to me why it behaves as it does.
The other subthread of this thread is about it: In Bash, all parts of a
pipeline are executed in an own su
Dr. Werner Fink wrote:
The question rises: Why does the bash require a sub peocess/shell
for the final command of a pipe sequence.
I'd think this is more or less a design choice at first (with one or the
other issue, maybe for both solutions - though I can't construct a
failing case for the
On 06/18/2010 07:05 AM, Dr. Werner Fink wrote:
> Just a remark about the sub shell usage in bash in comparision to
> ksh. Let's try:
>
> strace -f -o bash.strace bash -c 'echo a b | read a b'
> > grep -E 'execve|clone|write\(1|read\(0' bash.strace
[snip]
>
> and now the same with the K
Just a remark about the sub shell usage in bash in comparision to
ksh. Let's try:
strace -f -o bash.strace bash -c 'echo a b | read a b'
and grep about execve, clone, write on stdout, read from stdin:
> grep -E 'execve|clone|write\(1|read\(0' bash.strace
17183 execve("/bin/bash", ["
Britton Kerin wrote:
How so? It seems that read always reads from the terminal even when its in a
shell pipeline.
This isn't correct. Read reads from STDIN by default.
Regards,
Jan
Marc Herbert schrieb:
From section 2.12 and from messages posted here in the past I
understand that POSIX allows either one. This ambiguity reinforces the
need for documentation IMHO.
I agree with Greg here, it's a well known "don't". What should be
documented is (maybe it is?) how pipelines
>> - The POSIX standard does allow "echo 1 2 | read a b" to be useful
>>(cf. 2.12 "Shell Execution Environment").
> Maybe the POSIX expect shell to execute the last command of pipeline
> not in subshell.
>From section 2.12 and from messages posted here in the past I
understand that POSIX
On 06/17/2010 10:28 AM, Marc Herbert wrote:
- The POSIX standard does allow "echo 1 2 | read a b" to be useful
(cf. 2.12 "Shell Execution Environment"). Some alternatives to
bash actually make it useful. Standard and portability concerns
definitely belong to a reference manual.
Mayb
Le 16/06/2010 19:03, Greg Wooledge a écrit :
> On Wed, Jun 16, 2010 at 07:47:03PM +0200, Krzysztof ??elechowski wrote:
>> The description of the read builtin [19] would benefit of the following note:
>> Warning: A pipeline of the form { echo 1 2 | read a b; } is not useful. Use
>> {
>> read<<<"1
On Wed, Jun 16, 2010 at 07:47:03PM +0200, Krzysztof ??elechowski wrote:
> The description of the read builtin [19] would benefit of the following note:
> Warning: A pipeline of the form { echo 1 2 | read a b; } is not useful. Use
> {
> read<<<"1 2" a b; } instead.
That kind of advice is certain
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-4.0 -
L/usr/src/packages/BUILD/bash-4.0/../readline-6.0
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -
DCONF_OSTYPE='linux-gnu' -DCONF_MAC
17 matches
Mail list logo
