• expand-unglob-{dblq,unq} are the same as dash, but with ‘\}’ → ‘}’ as
per austin-group-l discussion, although this is not (yet) a standards
requirement, just a “doesn’t make sense otherwise” thing
expand-ugly:
• printf '%s\n' "foo ${IFS+"b c"} baz" → no field splitting, ksh93 is
wrong here (§2.6.2)
• ‘\}’ vs. ‘}’ as above
• ksh93 dropping a ‘}’ is probably another ksh93 bug
now that we use the same name as quiet-by-design autoconf
to please ccache anyway (and no we will not become quiet,
I can't usually get my hand on a buildd's conftest.log)
and vendor pdksh versions, re-introduce FPOSIX alongside FSH. The semantics
are now:
‣ set -o posix ⇒
• disable brace expansion and FSH when triggered
• use Debian Policy 10.4 compliant non-XSI “echo” builtin
• do not keep file descriptors > 2 to ksh
‣ set -o sh ⇒
• set automatically #ifdef MKSH_BINSHREDUCED
• disable brace expansion and FPOSIX when triggered
• use Debian Policy 10.4 compliant non-XSI “echo” builtin
• do not keep file descriptors > 2 to ksh
• trigger MKSH_MIDNIGHTBSD01ASH_COMPAT mode if compiled in
• make “set -- $(getopt ab:c "$@")” construct work
Note that the set/getopt one used to behave POSIXly only with FSH or
FPOSIX (depending on the mksh version) set and Bourne-ish with it not
set, so this changes default mksh behaviour to POSIX!
(I think this is because the TAND and the Job are not visible to
the code at the same time; patches welcome, as usual)
I don't think this is related to ^Z'd systrace(1)'d programmes
sometimes being unawakable, though.
concurrently accessing the same $HISTFILE be more synchronised with
each other: empty lines (just pressing Return) and duplicates (that
are split and written twice by the lines loaded from $HISTFILE in
the meantime); requested by Maximilian “mxey” Gaß in #!/bin/mksh
of foo[0] (but not its attributes), and the rest of the array, so that
later “set +A foo bar” will set foo[0]=bar but retain the attributes.
This is important, because, in the future, arrays will have different
attributes per element, instead of all the same (which, actually, is
not entirely true right now either, since “unset foo[0]” will not mo-
dify the attributes of a foo[1] existing at that point in time), where
foo[$newkey] will inherit from foo[0], but typeset foo will only affect
foo[0] no longer foo[*] in the future. (The rules about typeset=local
will still apply, as they affect creation of variables in a scope.)
tg