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 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
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
