[Bug 1857702] Re: " +=" operator does string concatenation for integer variables
maybe you can convince the `shellcheck' guys to support mksh ;). but I was rather thinking of "error" as in "syntax error", i.e. disallow += on integers all together as being then easy to spot and repair. I am somewhat paranoid about shells silently behaving differently, that's all ... :). for the time being I will try to strictly avoid += altogether for arithmetic outside ((...)) in all shells... -- 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/1857702 Title: " +=" operator does string concatenation for integer variables Status in mksh: Fix Committed Bug description: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). To manage notifications about this bug go to: https://bugs.launchpad.net/mksh/+bug/1857702/+subscriptions
[Bug 1857702] Re: " +=" operator does string concatenation for integer variables
thanks for making this discrepant behaviour of mksh more explicit in the manpage/FAQ. I believe this is helpful (as, generally, a "(in)compatibility table" comparing all relevant shells would be...). regarding opening bugs all over the place in (at least) 3 other shells for this issue: funny ;). I think the strongest argument against changing mksh here is maintaining upward compatibility (old scripts yield same answer with new mksh: that's upward, right?). the same of course holds for the others... I even would claim that, e.g., x+=1 in an "integer context" as a short hand for ((x+=1)) might be used rather often in bash/ksh93/zsh while it should hardly _ever_ be used on integers in mksh scripts (who wants to get the integer sequence 1, 11, 111, ... in this way, eg.?). so even if the breaking change were done, it would possibly not be causing much pain, I could imagine. so I still believe that += either should choke on integers (throw an error) or do the same as the others. getting an error would be quite OK: fixing it via ((...)) would than be trivial. _not_ getting an error but totally different result than in the other shells, _that_ is not so good in my view. but I understand you do not want this change. so that's that... ;) -- 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/1857702 Title: " +=" operator does string concatenation for integer variables Status in mksh: Fix Committed Bug description: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). To manage notifications about this bug go to: https://bugs.launchpad.net/mksh/+bug/1857702/+subscriptions
Re: [Bug 1857702] Re: " +=" operator does string concatenation for integer variables
On 27.12.19 23:02, Thorsten Glaser wrote: > and it’s most definitely not emulation of ksh93 > > some ksh88 and little parts of ksh93, but e.g. no float and other crap I've never used ksh88. so I do not know the intersection with ksh93. but my experience so far is that it seems easier to port a ksh93 script to mksh than to bash. so ... > or complicated things out of curiosity: what's on your "crap" list? what's on the "complicated" list regarding ksh93 (beyond compound variables ... ;))? personally, I wouldn't count ability of a "general purpose" scripting language to do floating point arithmetic as "crap". admittedly, I don't use that very often in ksh93 but it's good that it's there if needed (and calls to awk or whatever can be avoided). -- 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/1857702 Title: " +=" operator does string concatenation for integer variables Status in mksh: New Bug description: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). To manage notifications about this bug go to: https://bugs.launchpad.net/mksh/+bug/1857702/+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
Re: [Bug 1857702] Re: " +=" operator does string concatenation for integer variables
On 27.12.19 17:02, Thorsten Glaser wrote:
> Erm… that’s right, += is string concatenation.
ok, I got it that this seems to be the idea here, but
1.
what about
typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh)
if += categorically does string concat no matter what, should this not
yield "01"?
2.
the trio ksh93/bash/zsh all adjust the meaning of += to denoting integer
addition/increment if the
variable is declared integer. do you consider this "evil" and intentionally do
not do it? it bit me
when porting a somewhat elaborate script from ksh93 to mksh: suddenly 1+=1
yielded 11 rather than 2.
I'm not sure what the "mission statement" of mksh is (if any) but I see that
you come closer to
ksh93 than bash in some regards (e.g. `set -A' and '${... ;}' command
substitution are provided)
and presume it is intended to emulate ksh93 where the latter is not manifestly
broken? meaning:
should mksh not follow the other shells (notably ksh) in how they handle += for
integer variables?
>
> Write “let” before the line to make it integer addition.
understood. thanks for pointing this out. I never so far hat any use for
`let' ;)
--
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/1857702
Title:
" +=" operator does string concatenation for integer variables
Status in mksh:
New
Bug description:
consider
typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh)
but
typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other
shells)
I believe mksh should honour the integer declaration and interpret
`+=' accordingly. currently, it does not even consistently use string
concatentation (since the first example does not yield `01' ...).
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857702/+subscriptions
[Bug 1857702] [NEW] " +=" operator does string concatenation for integer variables
Public bug reported: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). ** Affects: mksh Importance: Undecided Status: New -- 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/1857702 Title: " +=" operator does string concatenation for integer variables Status in mksh: New Bug description: consider typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh) but typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other shells) I believe mksh should honour the integer declaration and interpret `+=' accordingly. currently, it does not even consistently use string concatentation (since the first example does not yield `01' ...). To manage notifications about this bug go to: https://bugs.launchpad.net/mksh/+bug/1857702/+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
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
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] [NEW] here string behaviour different in mksh and ksh93
Public bug reported:
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?
** Affects: mksh
Importance: Undecided
Status: New
--
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
