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, AT&T 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
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 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
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?
I think this is a feature of Bash 2.0, not a bug. I don't know how to fix it since I'm still in Bash 1.x. E.- BG Lim ([EMAIL PROTECTED]) wrote: : I'm using bash 2.0 from the base installation. I notices that if the line : that I type exceeds the wide of the screen, instead of going down to the : next line, it goes to the start of the same line, thus obliterating the : prompt and whatever I had typed. : : This occurs in Xterm as well. Bash 1.4 and other shells on my sytem didn't : have this problem. Is this corrected in Bash 2.01 or am I doing somethign : wrong? : : : BG : : : -- : TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to : [EMAIL PROTECTED] . : Trouble? e-mail to [EMAIL PROTECTED] . : -- Eloy A. Paris Information Technology Department Rockwell Automation de Venezuela Telephone: +58-2-9432311 Fax: +58-2-9430323 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
bug in bash?
I'm using bash 2.0 from the base installation. I notices that if the line that I type exceeds the wide of the screen, instead of going down to the next line, it goes to the start of the same line, thus obliterating the prompt and whatever I had typed. This occurs in Xterm as well. Bash 1.4 and other shells on my sytem didn't have this problem. Is this corrected in Bash 2.01 or am I doing somethign wrong? BG -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
