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,b c> > $ a="${x[@]}"; print -r -- "<$a>" > <a b c> > $ a=${x[*]}; print -r -- "<$a>" > <a,b c> > $ a=${x[@]}; print -r -- "<$a>" > <a b c> > $ a="${u:-"${x[*]}"}"; print -r -- "<$a>" > <a,b c> > $ a="${u:-"${x[@]}"}"; print -r -- "<$a>" > <a b c> > > 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 b c> a="${u:-x[@]}"; print -r -- "<$a>" # ==> <a b c> # 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