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