Developers’ Weblog

FOSS hosting by
HostEurope Logo

Developers’ Weblog

⚠ This page contains old, outdated, obsolete, … historic or WIP content! No warranties e.g. for correctness!

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

RFH: mksh development

2009-07-07 by tg@
Tags: mksh

mksh development is mostly done by a single person, "the mksh team" (as seen on Debian derivate from Canonical that cannot be named forums, out of all places!), a.k.a. me, myself and I. Sometimes, actual users report bugs or even send in patches. I keep track of oksh's development as well, of course. But there are times I would like to get feedback on issues from other people working on pdksh or its descendants. I mailed, for that specific issue in question, the Debian developer who created the original patch which addressed the scenario except for a corner case (interestingly, as the world is small, discovered in a Debian(!) init script from a package maintained by aforementioned formorer, on a DomU running Lenny — don't underestimate the effect of synergy) but would really like to talk to some of the OpenBSD devs about it; they mostly know what they're doing, even if I worked on ksh for longer than most of them, many eyes do help, and most of the time I do not know what I'm doing XD

[Update] There's also the issue of inter-(POSIX-compatible)-shell discussion. For instance, "set -u" vs "$@", which has come up in Debian #522255 because GNU bash4 decided to switch to the behaviour used by the Bourne shell (from V7 to SVR4.2), all Korn shells, ash and its descendents (like posh) except dash, to not treat it specially. (Funny too how they suggest 「${@:-}」 or 「${@:+}」 instead of 「${1+"$@"}」 (from the GNU(!) autoconf texinfo documentation) as replacements.) Oh well, zsh also behaves like bash2/3 and dash, but then, it's not even a POSIX compatible shell. *sigh* Now I wonder what AT&T ksh93 will do and a confirmation if it's indeed being forcibly changed by POSIX (IMHO, they could at least "agree to disagree", like they usually do, and make it vendor defined, so that scripts could not depend on it — "set -u" is something I don't use anyway).

So if you're interested in the further development of MirBSD, The MirOS Project, one of its subprojects, such as The MirPorts Framework, mksh(1), MirMake, even jupp-2.8 or jupp-3.x, please talk to me.

[Update] Do the same for POSIX compatible shell discussion, if you are going to take mksh, its goals, needs and history seriously. (Yes, it also has bugs, like a non-recursive parser troubling COMSUBs, but they may be fixed long-term, especially if people contribute. Ideas, at the very least.)

Thanks in advance.

MirBSD Logo