[Bug 1857195] Re: here string behaviour different in mksh and ksh93
** Changed in: mksh
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
Fix Released
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
OK, turns out that this was indeed a bug (but the presence of DOHEREDOC
probably predates the existence of DOSCALAR so understandable). I hope
this doesn’t introduce any regressions. Testcase also committed.
** Changed in: mksh
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
Fix Committed
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
that (restoring consistency with ksh93/bash) would be good, I believe.
subtle incompatibilities in behaviour (as opposed to syntax differences
causing manifest syntax errors) are the most painful when porting
scripts between shells in my experience, especially because they might
be missed during (imperfect) testing and only surface much later in a
bad way. so trying to avoid such incompatibilities seems beneficial.
this assessment also applies to the issue I reported here
https://bugs.launchpad.net/mksh/+bug/1857702
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
Triaged
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
Thanks for the extensive debugging/comparing work.
I think I’ll change mksh to match AT&T ksh93 for consistency and will
try to hunt down the cause for the difference.
** Changed in: mksh
Importance: Undecided => Low
** Changed in: mksh
Status: New => Triaged
** Changed in: mksh
Assignee: (unassigned) => Thorsten Glaser (mirabilos)
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
Triaged
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
correction: regarding "zsh does here strings like mksh and something
different from all other shells when printing unquoted variable
assignment.", this is true for the output of the provided script which,
incidentally, uses here strings as in `zsh <<< $input' to make the
respective shell evaluate the different commands listed in the above
table. as I just had to realize, zsh behaves peculiar here (different
from all other shells in that the output of, e.g.
x=$*; echo $x
is different if a) issued at the zsh prompt and b) is part of the here
string fed to a zsh call (as is done in my script). in the latter case
zsh seems to introduce a further level of "hidden" quoting (or whatever)
which yields the listed output. issued at the command prompt the above
command yields the same result as the other shells. so this is a special
zsh hickup and unrelated to the presented issue. sorry for the
confusion...
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
fyi, attached a small script which facilitates the inter-shell
comparison (might be augmented for further contexts in which $* and $@
get expanded, if necessary). the result looks like
+
$1=a, $2=b, IFS=,
+
command ksh mksh bash zsh
echo $* a b a ba ba b
echo "$*" a,b a,ba,ba,b
echo $@ a b a ba ba b
echo "$@" a b a ba ba b
x=$*; echo "$x" a,b a,ba,ba,b
x="$*"; echo "$x" a,b a,ba,ba,b
x=$@; echo "$x" a b a ba ba,b
x="$@"; echo "$x" a b a ba ba,b
x=$*; echo $x a b a ba ba,b
x="$*"; echo $x a b a ba ba,b
x=$@; echo $x a b a ba ba,b
x="$@"; echo $x a b a ba ba,b
cat <<< $* a,b a,ba,ba,b
cat <<< "$*"a,b a,ba,ba,b
cat <<< $@ a b a,ba ba,b
cat <<< "$@"a b a,ba ba,b
what it shows is, that bash manages to mimic ksh behaviour completely
here. mksh differs only in the handling of the here strings from
ksh/bash and only for $@. zsh does here strings like mksh and something
different from all other shells when printing unquoted variable
assignment.
since all these differences seem to concern details of interpreting the
standard and/or decisions whether to follow ksh or not, I think you are
in a better position (as the author of one of the shells) to contact the
other shells' maintainers than me. but if you think it makes sense, I
also could do that.
overall, I still neither do understand the differences between the
shells nor the differences between the different variants of
accessing/using $* and $@ completely...
but from a pragmatic point of view: if mksh would modify its here string
handling somewhat, ksh, mksh, bash would behave identical. and identical
behaviour of different shells I like ;).
** Attachment added: "compat"
https://bugs.launchpad.net/mksh/+bug/1857195/+attachment/5315544/+files/compat
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
> Nowhere did I deliberately do anything wrt. field splitting or not-
splitting or joining.
understood.
> I’m somewhat afraid even that, if this is wrong, it’s systematically
wrong somewhere…
could very well be. I even believe that ksh93 might also not do what it
should/intends to do at this point. e.g. the ksh93 manpages states:
```
The meaning of $* and $@ is identical when not quoted or when
used as a variable assignment value or as a file name. However, when
used as a command argument, "$*" is equivalent to "$1d$2d...", where d
is the first character of the IFS variable, whereas "$@" is equivalent
to "$1" "$2"
```
this (meaning of $* and $@ identical w/o quotes) seems definitely not
completely true considering (and skipping the array part since it seems
irrelevant to the problem):
```
set a 'b c'
IFS=,
print ' * : '$*
print '"*": '"$*"
print ' @ : '$@
print '"@": '"$@"
print ++
a=$*; print ' * : '"$a"
a="$*"; print '"*": '"$a"
a=$@; print ' @ : '"$a"
a="$@"; print '"@": '"$a"
```
where
a=$*; print ' * : '"$a"
produces different output than
a=$@; print ' @ : '"$a"
(mksh does the same but seemingly does not explicitly claim what ksh does, here
;)). do you agree?
in the above examples it seems that even when first assigning to `a', the
expansion is only coming into effect in the subsequent print (where double
quotes are used), like in a sort of "lazy evaluation". this is also true for
a=$*; print ' * : '"$a"
vs.
a="$*"; print '"*": '"$a"
I wouldn't expect this. should I?
> What do the zsh developers say regarding this? I assume you also contacted
> them?
no, not at all. I have decided quite some years ago that ?ksh?? is the
way to go for me;).
> What does the GNU bash developer say? Did you contact Chet?
sorry, no again, for the same reason: I always preferred ksh93 due to
its clear specification, additional useful features (rather than
feature-creep...) and much better performance.
> For that matter, situ (ksh2020), although I could talk to him directly
(#ksh on IRC).
well... I've had some contact to _that_ project during the last 2 months
or so. if `situ' is the same guy as "Siteshwar Vashisht", it might make
sense if you talk to him. he seems sensible as far as I can tell. but
what is going on in that project (the main committer there being some
ignoramus doing severe harm to the ksh93 legacy for the last two years
in a row, getting according feedback from assorted people -- I also
raised a few issues there recently and received astonishing reactions --
and basically misunderstanding or ignoring it completely) has made me
look for a viable alternative to (a no longer properly maintained) ksh93
(successor): hence mksh (plus a working binary of ksh93u+). so, given my
discouraging experience there I did not bother to raise this (in my view
sufficiently intricate) issue there... but maybe you'll have more luck.
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
“it should be deterministic/always the same” this is a very good point,
and at this, well, point, I’ve not yet got any opinion.
I modelled the here strings after here documents: first, the first two
“<<” are parsed indicating it’s a here document, then the here document
delimiter is parsed; if that begins with another “<” it’s stripped off,
and a flag is set that it’s a here string (that the delimiter is the
document), otherwise, a document is read until the end delimiter.
Nowhere did I deliberately do anything wrt. field splitting or not-
splitting or joining.
I’m somewhat afraid even that, if this is wrong, it’s systematically
wrong somewhere…
At this point… curious:
What do the zsh developers say regarding this? I assume you also
contacted them?
What does the GNU bash developer say? Did you contact Chet?
For that matter, situ (ksh2020), although I could talk to him directly (#ksh on
IRC).
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
Re: [Bug 1857195] Re: here string behaviour different in mksh and ksh93
On 22.12.19 21:05, Thorsten Glaser wrote:
> Args, hit Return too early.
>
> - contact me in IRC or so if you’re up for SMTP debugging
> -
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02
> for the POSuX reference
thanks (for both pointers!).
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
Re: [Bug 1857195] Re: here string behaviour different in mksh and ksh93
On 22.12.19 21:04, Thorsten Glaser wrote:
> Almost a good point, considering…
>
> $ x=(a 'b c')
> $ IFS=,
> $ a="${x[*]}"; print -r -- "<$a>"
>
> $ a="${x[@]}"; print -r -- "<$a>"
>
> $ a=${x[*]}; print -r -- "<$a>"
>
> $ a=${x[@]}; print -r -- "<$a>"
>
> $ a="${u:-"${x[*]}"}"; print -r -- "<$a>"
>
> $ a="${u:-"${x[@]}"}"; print -r -- "<$a>"
>
>
> Oh the other hand, according to POSIX, using “$@” (contrary to “$*”) in
> double-quotes in scalar context is unspecified unless part of “word” in
> “${foo:-word}”… I guess mksh and zsh just equal it to $* there, whereas
> AT&T ksh93 and GNU bash don’t.
I try to summarize my understanding so far: the missing bit for me was your
above
example of first assigning to an auxiliary variable before printing. what you,
then,
show above in your `print' output is identical with what ksh93/bash do when
issuing
the different variants of `cat <<< ${x[*]}': IFS honoured with `*' and ignored
with `@',
irrespective of quoting (when constructing the here string or auxiliary
variable).
while this is one twist too much for me already (since it it not immediately
obvious to the user
that the here string introduces that second level of expansion), I probably
understand it now.
regarding the discrepant behaviour of mksh and zsh regarding `@', I have to
believe you that it is
OK, i.e. covered by the standard since unspecified ;). what I still do _not_
really get:
IFS=,
a="${x[@]}"; print -r -- "<$a>" # ==>
a="${u:-x[@]}"; print -r -- "<$a>" # ==>
# vs.
cat <<< "$x[@]}" # ==?> a, b c
I thought what you were saying is that during here string construction the same
is going on as when
assigning to the auxiliary variable `a' above? so even if the behaviour at this
point is
unspecified, it should be deterministic/always the same, no?
and in any case the question remains: are ksh93/bash not less surprising here
and closer to what the
naive user might expect (simply because `@' continues to behave as defined
(even if only in a
different context...))? and would it not be better if mksh would follow ksh93
behaviour here
(considering that it overall is the most faithful ksh93 clone/look alike I know
of...)?
>
> As for the mailing list… writing to postmaster@, but if your mail
> provider is either on the blacklist (Yahoo, OVH, …) or too stupid for
> SMTP (Hotmail, Googlemail, …) I guess you’re somewhat out of luck. (I
yes, gmail it is...
> didn’t see any connection to postmaster@ in my logs (from Dec 20, 16:00,
> onwards, I don’t retain older logs), nor in my greylisting, if that’s a
my tries where earlier, somewhen in november.
> consolation.) You can try another eMail service or read at https://www
> .mail-archive.com/miros-mksh@mirbsd.org/ or so…
that or I declare every question a bug and post it here ;). no, won't do
that. promise
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
Almost a good point, considering…
$ x=(a 'b c')
$ IFS=,
$ a="${x[*]}"; print -r -- "<$a>"
$ a="${x[@]}"; print -r -- "<$a>"
$ a=${x[*]}; print -r -- "<$a>"
$ a=${x[@]}; print -r -- "<$a>"
$ a="${u:-"${x[*]}"}"; print -r -- "<$a>"
$ a="${u:-"${x[@]}"}"; print -r -- "<$a>"
Oh the other hand, according to POSIX, using “$@” (contrary to “$*”) in
double-quotes in scalar context is unspecified unless part of “word” in
“${foo:-word}”… I guess mksh and zsh just equal it to $* there, whereas
AT&T ksh93 and GNU bash don’t.
As for the mailing list… writing to postmaster@, but if your mail
provider is either on the blacklist (Yahoo, OVH, …) or too stupid for
SMTP (Hotmail, Googlemail, …) I guess you’re somewhat out of luck. (I
didn’t see any connection to postmaster@ in my logs (from Dec 20, 16:00,
onwards, I don’t retain older logs), nor in my greylisting, if that’s a
consolation.) You can try another eMail service or read at https://www
.mail-archive.com/miros-mksh@mirbsd.org/ or so…
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
Args, hit Return too early.
- contact me in IRC or so if you’re up for SMTP debugging
-
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02
for the POSuX reference
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
one unrelated question: how can I reach (or subscribe to) the mksh
mailing list? my attempts to write mail to the list were unsuccessful
(mails rejected by your server).
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
Re: [Bug 1857195] Re: here string behaviour different in mksh and ksh93
On 22.12.19 01:05, Thorsten Glaser wrote:
> Not a definite decision, but consider this:
thanks for the quick reply!
>
> print -r -- "${x[@]}"
>
> - vs. -
>
> a="${x[@]}"
>
> In the first code, the elements of array x are expanded in list context,
> that is, each element as separate word, unset elements generating no
> words.
yes. that is the expected behaviour for "${x[@]}" expansion (according to my
reading/understanding,
of the manpage, anyway).
>
> In the second code, the elements are expanded in scalar context (because
> they are then assigned to a scalar), that is, the same as in:
>
> a="${x[*]}"
>
> First, one string is built from *all* array elements, IFS[0]-separated,
> then it is passed to the assignee.
I can not follow, I'm afraid. the latter behaviour you describe above
is specific for `[*]', no?. i.e.
a="${x[*]}"; print "$a"
produces what you describe above (and the same as `print "${x[*]}"'),
i.e. IFS[0] separated words but
a="${x[@]}"; print "$a"
produces the same as `print "${x[@]}"' i.e. SPACE separated elements
irrespective of IFS -- as I
would expect it to be in accord with the difference of `*' and `@' as explained
in the (m)ksh manpages.
>
> I think it’s not unusual to consider the argument of a here string
> scalar context.
I have no opinion/knowledge at all in these matters.
>
> I built here stings in mksh to parallel here documents, where the
> separator is scalar, so this is by coïncidence, but I don’t see anything
> wrong with the mksh behaviour, upon a short two-minute reflection.
that's what I am not sure about. if the POSIX standard or manpage of ksh93 would
allow to determine unambiguously _should_ happen here, than one would have to
conclude that at least
one of mksh and ksh93 (or even both!) are wrong, simply because they do behave
differently.
from this user's perspective, for the initially given example, i.e.
IFS=$'\n'
x=(a "b c")
the difference between
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
and
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
is confusing/unexpected (and, as said, there _is_ a difference for ksh93 as
well, too, but a
different one than for mksh). the latter (the `prints') do what the manpage
seems to demand
regarding the difference between * and @ expansion of the elements and the
effect of double quoting.
so I really would expect the here strings to expand in exactly the same way.
so basically I have these questions:
1.
does the standard allow to determine what _should_ happen? if so, is ksh93
doing it right or mksh?
or are both wrong and what actually should happen is that the here strings
behave like in the
`prints' above?
2.
if the question what is "right" can not be decided by looking at the docs,
would it not be
preferable if mksh would mimic ksh (and bash) at this point since consistency
is preferable (even if
the behaviour would not be necessarily "better")?
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
[Bug 1857195] Re: here string behaviour different in mksh and ksh93
Not a definite decision, but consider this:
print -r -- "${x[@]}"
- vs. -
a="${x[@]}"
In the first code, the elements of array x are expanded in list context,
that is, each element as separate word, unset elements generating no
words.
In the second code, the elements are expanded in scalar context (because
they are then assigned to a scalar), that is, the same as in:
a="${x[*]}"
First, one string is built from *all* array elements, IFS[0]-separated,
then it is passed to the assignee.
I think it’s not unusual to consider the argument of a here string
scalar context.
I built here stings in mksh to parallel here documents, where the
separator is scalar, so this is by coïncidence, but I don’t see anything
wrong with the mksh behaviour, upon a short two-minute reflection.
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195
Title:
here string behaviour different in mksh and ksh93
Status in mksh:
New
Bug description:
consider
IFS=$'\n'
x=(a "b c")
cat <<< ${x[*]}
cat <<< "${x[*]}"
cat <<< ${x[@]}
cat <<< "${x[@]}"
executing this in mksh (or zsh, incidentally) yields the output
a
b c
a
b c
a
b c
a
b c
(i.e. identical output, always inserting first IFS char between
elements, for all variants of accessing all elements of the array)
while ksh93 (or bash, for that matter) yields
a
b c
a
b c
a b c
a b c
(i.e. `*' behaves different from `@' but double quoting is
ineffectual).
I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to
report this inconsistency and to ask for clarification. what I _would_ have
expected to start with is, that
the above "here string" commands would yield the same output as
print ${x[*]}
print "${x[*]}"
print ${x[@]}
print "${x[@]}"
which is neither true for ksh93 nor for mksh. is this all good and
well and I am only overlooking something obvious?
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions
