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
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 ;).
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
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
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
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
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
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 $*
> 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
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
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 --
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
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,
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
14 matches
Mail list logo
