Bug in bash? different from ksh, at any rate...
Can anybody explain this difference between the behavior of bash and
ksh?
When reading the man page, I would expect both of them to have the
behavior exhibited by ksh.
Why does bash seem to treat return like a single level break in
this context?
The echo $AA | while read is important context. If I change it to
for i in 0 1, return does as expected.
If it's any help, changing return to break 2 doesn't help. with
bash, it still gives 1 1 1 1
while ksh still gives 1
I wonder if it has anything to do with while read causing a subshell
to be created, and bash getting confused about the return inside of
a subshell. If so, it's a bug in bash that ksh gets right, so it
ought to be fixable.
ADVthanksANCE
Rick
--- example of strange behavior below ---
:~$ cat /tmp/testit
function strange {
for j in 0 1 2 3
do
AA=' 1
2'
echo $AA | while read i
do
echo $i
return
done
done
}
echo $(strange)
:~$ bash /tmp/testit
1 1 1 1
:~$ ksh /tmp/testit
1
--- example of strange behavior above ---
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2ad2a80f-b087-4730-b7ff-6b7daa0f4...@pobox.com
Re: Bug in bash? different from ksh, at any rate...
On Sat, May 28, 2011 at 01:14:42AM -0700, Rick Thomas wrote:
Can anybody explain this difference between the behavior of bash and
ksh?
When reading the man page, I would expect both of them to have the
behavior exhibited by ksh.
Why does bash seem to treat return like a single level break in
this context?
The echo $AA | while read is important context. If I change it
to for i in 0 1, return does as expected.
If it's any help, changing return to break 2 doesn't help. with
bash, it still gives 1 1 1 1
while ksh still gives 1
I wonder if it has anything to do with while read causing a
subshell to be created, and bash getting confused about the return
inside of a subshell. If so, it's a bug in bash that ksh gets
right, so it ought to be fixable.
I can't reproduce it:
$ cat strange.sh
function strange {
for j in 0 1 2 3
do
AA=' 1
2'
echo $AA | while read i
do
echo $i
return
done
done
}
echo $(strange)
$ bash ./strange.sh
1 1 1 1
$ ksh ./strange.sh
1 1 1 1
ii bash 4.1-3 The GNU Bourne Again SHell
ii mksh 39.3.20100725-1 MirBSD Korn Shell
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: Bug in bash? different from ksh, at any rate...
On 2011-05-28 10:14 +0200, Rick Thomas wrote:
Can anybody explain this difference between the behavior of bash and
ksh?
It depends on whether the shell starts a subshell for (compound)
commands in pipelines.
When reading the man page, I would expect both of them to have the
behavior exhibited by ksh.
Why does bash seem to treat return like a single level break in
this context?
The echo $AA | while read is important context. If I change it to
for i in 0 1, return does as expected.
Actually, the pipeline is the most important. You can achieve the same
with a simpler script:
--8---cut here---start-8---
strange () {
for j in 0 1 2 3
do
: | { echo 1;return; }
done
}
echo $(strange)
--8---cut here---end---8---
I wonder if it has anything to do with while read causing a subshell
to be created,
Not exactly, it's the pipeline that causes creation of the subshell.
and bash getting confused about the return inside of
a subshell.
It does not get confused; as you can see, the subshell properly returns.
If so, it's a bug in bash that ksh gets right, so it
ought to be fixable.
There is no wrong or right here, since the susv3 specification is rather
vague:
,
| Additionally, each command of a multi-command pipeline is in a subshell
| environment; as an extension, however, any or all commands in a pipeline
| may be executed in the current environment.
`
So bash implements the default, while ksh implements the extension.
Having an option in bash to control the behavior would be nice, however.
See also the following blog entry:
http://backreference.org/2010/10/23/on-pipes-subshells-and-descriptors/.
Sven
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwnzjc0s@turtle.gmx.de
Re: Bug in bash? different from ksh, at any rate...
On May 28, 2011, at 2:47 AM, David Sastre wrote:
On Sat, May 28, 2011 at 01:14:42AM -0700, Rick Thomas wrote:
Can anybody explain this difference between the behavior of bash and
ksh?
When reading the man page, I would expect both of them to have the
behavior exhibited by ksh.
Why does bash seem to treat return like a single level break in
this context?
The echo $AA | while read is important context. If I change it
to for i in 0 1, return does as expected.
If it's any help, changing return to break 2 doesn't help. with
bash, it still gives 1 1 1 1
while ksh still gives 1
I wonder if it has anything to do with while read causing a
subshell to be created, and bash getting confused about the return
inside of a subshell. If so, it's a bug in bash that ksh gets
right, so it ought to be fixable.
I can't reproduce it:
$ cat strange.sh
function strange {
for j in 0 1 2 3
do
AA=' 1
2'
echo $AA | while read i
do
echo $i
return
done
done
}
echo $(strange)
$ bash ./strange.sh
1 1 1 1
$ ksh ./strange.sh
1 1 1 1
ii bash 4.1-3 The GNU Bourne Again SHell
ii mksh 39.3.20100725-1 MirBSD Korn Shell
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04
5299 EC56
As noted in other responses to my question, the behavior depends on
how your particular shell does pipes (with or without generating a
subshell) You have the MirBSD Korn Shell. I was using the ksh that
calls itself The real, ATT version of the Korn shell which has
different behavior.
Thanks for testing!
Rick
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/afc95b26-55d3-4395-847d-57cb8133b...@pobox.com
