we don’t get SIGWINCH when the window size changes during the runtime of
that, so, the signal is only usable reliably during editing in the shell
and we re-check the window size before each interactive edit line again
a string buffer whose window size is currently 32 (initial), your data
is 96 bytes, this routine used to resize the buffer to 64, append your
first 64 bytes to it (no matter if there's already something in it)
and then writes the remaining bytes to stdio fd instead of the string…
if it doesn’t SIGABRT before
discovered by wbx@ – thanks – bug inherited from pdksh 5.2.14 (AD 1999)
• deactivate %a and %A since our libc doesn’t have it
• rewrite the mksh integration code to use shf instead of stdio, removing
floating point support always in the process, as shf doesn’t support it
⇒ saves 11114 (6706 text, 168 data, 4240 bss) with dietlibc on Debian
• fix -Wall -Wextra -Wformat -Wstrict-aliasing=2 for gcc (Debian 4.4.4-7)
• fix these and -Wc++-compat for gcc version 4.6.0 20100711 (experimental)
[trunk revision 162057] (Debian 20100711-1) except:
– a few enum warnings that relate to eglibc’s {g,s}etrlimit() functions
taking an enum instead of an int because they’re too stupid to adhere
to POSIX interfaces they design by themselves
– all “request for implicit conversion” involving a "void *" on one side
• tweak the manual page somewhat more
• avoid calling realloc twice in sequence, since the final
size is known at the first call already
• do not lstat(2) the same path twice in the Hurd codepath
• 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
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!
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.)
some idiotic terminal emulators and/or people seem to use the es-
cape codes normally denoting Alt-Arrowkey instead so let's simply
bind them to the vt_hack as well... (untested)
• merge the rest of branch tg-wcswidth-behaviour
• enhance test cases for wcswidth-like behaviour
• switch hash table collision resolution algorithm to Python’s as announced
• bump vsn
│remember to restore errno (ie. stop someone from making a mistake later)
│ok guenther
check.t, sh.h: bump vsn
I wonder though why errno must be restored even if nothing was
called after reading it… moid?
which, in its latest sid incarnation, even received mksh's ability
to produce ${!foo[*]} array keys, wow!)
* plug a memory leak while here (ATEMP only, but still)
I read, IIRC in the Cederqvist, that 'cvs tag' sets a sticky tag onto
the cwd… it doesn’t, apparently. (I actually like it better this way,
but one needs to know!)
tg