Re: Another potential ksh bug?
Hi Vadim,
Thanks for looking into this, all I ever wanted was an ancient pdksh bug
fix for Christmas.
Regards,
Jordan
On 12/7/20 10:47 AM, Vadim Zhukov wrote:
For me, this is a definite bug. I've opted my students to fix this
bug, so unless there's a hurry, there must be a fix till the end of
December. :)
пн, 7 дек. 2020 г. в 07:43, Jordan Geoghegan :
Hello again,
I was playing around with ksh array syntax and its behaviour when set as
read-only. In my testing I noticed that ksh will allow you to overwrite
the first element of a read-only array. Example snippet:
#!/bin/ksh
arr[0]=val1
arr[1]=val2
readonly arr
echo "${arr[@]}"
arr=yikes
echo "${arr[@]}"
I tested a few other shells, and this bug does exists in the original
pdksh and is also present in zsh. This bug is not present in ksh93, mksh
or bash, where they abort when trying to modify the read-only array.
I don't have access to a proper ksh88 shell, but it would be nice if
someone could confirm its behaviour.
I was just hoping someone could confirm if this is intended behaviour,
or if it's a bug.
Regards,
Jordan
Re: Another potential ksh bug?
On 12/7/20 10:14 PM, Noth wrote:
On 07/12/2020 05:41, Jordan Geoghegan wrote:
Hello again,
I was playing around with ksh array syntax and its behaviour when set
as read-only. In my testing I noticed that ksh will allow you to
overwrite the first element of a read-only array. Example snippet:
#!/bin/ksh
arr[0]=val1
arr[1]=val2
readonly arr
echo "${arr[@]}"
arr=yikes
echo "${arr[@]}"
I tested a few other shells, and this bug does exists in the original
pdksh and is also present in zsh. This bug is not present in ksh93,
mksh or bash, where they abort when trying to modify the read-only
array.
I don't have access to a proper ksh88 shell, but it would be nice if
someone could confirm its behaviour.
I was just hoping someone could confirm if this is intended
behaviour, or if it's a bug.
Regards,
Jordan
Hi,
I tries this with AMIX (UNIX SVR4 for Commodore Amiga) v2.1 which
presumably is using ksh88 as it hasn't been updated since circa 1992
and it does abort at the same place. Screenshot here:
http://casper.nineinchnetworks.ch/images/kshtest.png .
Cheers,
Noth
Hi Noth,
Sorry for the late reply, I've been AFK for several days.
Thanks for testing that out and confirming ksh88's behaviour!
Regards,
Jordan
Re: Another potential ksh bug?
On 07/12/2020 05:41, Jordan Geoghegan wrote:
Hello again,
I was playing around with ksh array syntax and its behaviour when set
as read-only. In my testing I noticed that ksh will allow you to
overwrite the first element of a read-only array. Example snippet:
#!/bin/ksh
arr[0]=val1
arr[1]=val2
readonly arr
echo "${arr[@]}"
arr=yikes
echo "${arr[@]}"
I tested a few other shells, and this bug does exists in the original
pdksh and is also present in zsh. This bug is not present in ksh93,
mksh or bash, where they abort when trying to modify the read-only array.
I don't have access to a proper ksh88 shell, but it would be nice if
someone could confirm its behaviour.
I was just hoping someone could confirm if this is intended behaviour,
or if it's a bug.
Regards,
Jordan
Hi,
I tries this with AMIX (UNIX SVR4 for Commodore Amiga) v2.1 which
presumably is using ksh88 as it hasn't been updated since circa 1992 and
it does abort at the same place. Screenshot here:
http://casper.nineinchnetworks.ch/images/kshtest.png .
Cheers,
Noth
Re: Another potential ksh bug?
For me, this is a definite bug. I've opted my students to fix this
bug, so unless there's a hurry, there must be a fix till the end of
December. :)
пн, 7 дек. 2020 г. в 07:43, Jordan Geoghegan :
>
> Hello again,
>
> I was playing around with ksh array syntax and its behaviour when set as
> read-only. In my testing I noticed that ksh will allow you to overwrite
> the first element of a read-only array. Example snippet:
>
> #!/bin/ksh
> arr[0]=val1
> arr[1]=val2
> readonly arr
> echo "${arr[@]}"
> arr=yikes
> echo "${arr[@]}"
>
> I tested a few other shells, and this bug does exists in the original
> pdksh and is also present in zsh. This bug is not present in ksh93, mksh
> or bash, where they abort when trying to modify the read-only array.
>
> I don't have access to a proper ksh88 shell, but it would be nice if
> someone could confirm its behaviour.
>
> I was just hoping someone could confirm if this is intended behaviour,
> or if it's a bug.
>
> Regards,
>
> Jordan
>
--
WBR,
Vadim Zhukov
Another potential ksh bug?
Hello again,
I was playing around with ksh array syntax and its behaviour when set as
read-only. In my testing I noticed that ksh will allow you to overwrite
the first element of a read-only array. Example snippet:
#!/bin/ksh
arr[0]=val1
arr[1]=val2
readonly arr
echo "${arr[@]}"
arr=yikes
echo "${arr[@]}"
I tested a few other shells, and this bug does exists in the original
pdksh and is also present in zsh. This bug is not present in ksh93, mksh
or bash, where they abort when trying to modify the read-only array.
I don't have access to a proper ksh88 shell, but it would be nice if
someone could confirm its behaviour.
I was just hoping someone could confirm if this is intended behaviour,
or if it's a bug.
Regards,
Jordan
Re: Potential ksh bug?
On Nov 17 09:01:18, alexan...@beard.se wrote: > > > On November 17, 2020 5:04:19 AM GMT+01:00, Jordan Geoghegan > wrote: > >Hello, > > > >I'm not sure if this is a bug, or if it's just a pdksh thing, but I > >stumbled upon some interesting behaviour when I was tinkering around > >with quoting and using a poor mans array: > > > >test=$(cat <<'__EOT' > ># I'll choose not to close this quote > >other_stuff > >__EOT > >) > > > >echo "$test" > > > > > >When I run this command on ash, dash, yash, bash, zsh or ksh93 I get > >the > >following output: > > > ># I'll choose not to close this quote > >other_stuff > > > >But when I run it on ksh from base or any pdksh derivative it throws an > > > >error about an unclosed quote: > > > >test.sh[8]: no closing quote > > I believe this is a known shortcoming of how ksh determines the scope of the > $(...). Does that also mean the 8th line in a 7-line script?
Re: Potential ksh bug?
On Mon, Nov 16, 2020 at 11:04 PM Bodie wrote: > On 17.11.2020 05:04, Jordan Geoghegan wrote: > > Hello, > > > > I'm not sure if this is a bug, or if it's just a pdksh thing, but I > > stumbled upon some interesting behaviour when I was tinkering around > > with quoting and using a poor mans array: > > > > test=$(cat <<'__EOT' > > # I'll choose not to close this quote > > other_stuff > > __EOT > > ) > > > > echo "$test" > > > > > > When I run this command on ash, dash, yash, bash, zsh or ksh93 I get > > the following output: > > > > # I'll choose not to close this quote > > other_stuff > > > > But when I run it on ksh from base or any pdksh derivative it throws > > an error about an unclosed quote: > > > > test.sh[8]: no closing quote > > > > This snippet works on every POSIX-y shell in the ports tree, and fails > > on every pdksh variant I tried, including on NetBSD and DragonflyBSD > > as well. I don't have the requisite esoteric knowledge regarding > > pdksh's internal quoting logic, so I'm hoping one of the gurus here > > can determine whether this is a bug or if I'm just doing something > > annoying. > > > > Any insight that can be provided would be much appreciated. > > > > What exactly are you trying to achieve? > > If you will look in sh(1) for 'Command expansion' then there are defined > rules and your form is not between them. > I disagree. I believe this: cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT matches the syntax for 'command'...once you take into account redirections, including 'here-docs'. Or do you believe that's not a valid command on it's own? To put another way, I agree with halex@ that this is a (known, not yet fixed) bug. So error message about missing closing quote is actually proper > behavior. > Nope. This is a bug in OpenBSD ksh. > As well it is good idea to avoid reserved words as a names for variables > ;-) > (test) Hmm? * 'test' is not a reserved word in the shell * shell variable names are a completely different namespace than shell reserved words or commands * code written to check whether something is a bug is 1000% out-of-bounds for style comments: either there's a bug or there isn't Philip Guenther
Re: Potential ksh bug?
On November 17, 2020 5:04:19 AM GMT+01:00, Jordan Geoghegan wrote: >Hello, > >I'm not sure if this is a bug, or if it's just a pdksh thing, but I >stumbled upon some interesting behaviour when I was tinkering around >with quoting and using a poor mans array: > >test=$(cat <<'__EOT' ># I'll choose not to close this quote >other_stuff >__EOT >) > >echo "$test" > > >When I run this command on ash, dash, yash, bash, zsh or ksh93 I get >the >following output: > ># I'll choose not to close this quote >other_stuff > >But when I run it on ksh from base or any pdksh derivative it throws an > >error about an unclosed quote: > >test.sh[8]: no closing quote I believe this is a known shortcoming of how ksh determines the scope of the $(...). /Alexander > >This snippet works on every POSIX-y shell in the ports tree, and fails >on every pdksh variant I tried, including on NetBSD and DragonflyBSD as > >well. I don't have the requisite esoteric knowledge regarding pdksh's >internal quoting logic, so I'm hoping one of the gurus here can >determine whether this is a bug or if I'm just doing something >annoying. > >Any insight that can be provided would be much appreciated. > >Regards, > >Jordan
Re: Potential ksh bug?
On 11/16/20 10:36 PM, Bodie wrote: On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. What exactly are you trying to achieve? If you will look in sh(1) for 'Command expansion' then there are defined rules and your form is not between them. So error message about missing closing quote is actually proper behavior. Plus I will not be so sure that bash is behaving properly: $ bash -x test.sh ++ cat + test=' # I'\''ll choose not to close this quote other_stuff' + echo '#' 'I'\''ll' choose not to close this quote other_stuff # I'll choose not to close this quote other_stuff $ Notice how one single quote is here "test='" abd second one is in "other_stuff'" You can compare results between various shells with ktrace/ktruss too $ bash --version | head -1 GNU bash, version 5.0.18(1)-release (x86_64-unknown-openbsd6.8) $ If you want to read the file then you do not need interaction and if you want to get input from user then use 'read' As well it is good idea to avoid reserved words as a names for variables ;-) (test) Regards, Jordan I'm not trying to achieve anything in particular, I was just testing out differences in behaviour between different shells. I just noticed that pdksh variants handled this differently than any other shell I tested in the ports tree. Regards, Jordan
Re: Potential ksh bug?
On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. BTW try it somewhere with vim and enabled color syntax and you will see immediately what is wrong Any insight that can be provided would be much appreciated. Regards, Jordan
Re: Potential ksh bug?
On 17.11.2020 05:04, Jordan Geoghegan wrote: Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. What exactly are you trying to achieve? If you will look in sh(1) for 'Command expansion' then there are defined rules and your form is not between them. So error message about missing closing quote is actually proper behavior. Plus I will not be so sure that bash is behaving properly: $ bash -x test.sh ++ cat + test=' # I'\''ll choose not to close this quote other_stuff' + echo '#' 'I'\''ll' choose not to close this quote other_stuff # I'll choose not to close this quote other_stuff $ Notice how one single quote is here "test='" abd second one is in "other_stuff'" You can compare results between various shells with ktrace/ktruss too $ bash --version | head -1 GNU bash, version 5.0.18(1)-release (x86_64-unknown-openbsd6.8) $ If you want to read the file then you do not need interaction and if you want to get input from user then use 'read' As well it is good idea to avoid reserved words as a names for variables ;-) (test) Regards, Jordan
Potential ksh bug?
Hello, I'm not sure if this is a bug, or if it's just a pdksh thing, but I stumbled upon some interesting behaviour when I was tinkering around with quoting and using a poor mans array: test=$(cat <<'__EOT' # I'll choose not to close this quote other_stuff __EOT ) echo "$test" When I run this command on ash, dash, yash, bash, zsh or ksh93 I get the following output: # I'll choose not to close this quote other_stuff But when I run it on ksh from base or any pdksh derivative it throws an error about an unclosed quote: test.sh[8]: no closing quote This snippet works on every POSIX-y shell in the ports tree, and fails on every pdksh variant I tried, including on NetBSD and DragonflyBSD as well. I don't have the requisite esoteric knowledge regarding pdksh's internal quoting logic, so I'm hoping one of the gurus here can determine whether this is a bug or if I'm just doing something annoying. Any insight that can be provided would be much appreciated. Regards, Jordan
