mksh tag cloud

Sponsored by
HostEurope Logo

mksh tag cloud

All 1 2 3 4 5 6 7 8

mksh has just been adjusted to behave as future POSIX will demand, after a lengthy discussion (on the bug-bash and miros-discuss mailing lists as well as the Debian bug tracker), for “set -u” (-o nounset). This, as well as the “stop () {…}” fix, must be tested extensively.

Therefore I urge all of you to

 % CVS_RSH=ssh; export CVS_RSH
 % cvs -d :ext:_anoncvs@anoncvs.mirbsd.org:/cvs co -PA mksh
 % cd mksh
 % (sh Build.sh -r && ./test.sh -v) 2>&1 | tee log

and possibly send me the log. See an earlier post for more information about testing mksh(1) snapshots, as well.

Tests for better standards compliance and bugs, especially in corner cases, are also welcome. Known are: all but the first command of a pipeline are run in subprocesses (made to be an mksh feature, not a bug); the lexer is not recursive (issues with parenthesēs and comments in COMSUBs); some IFS/whitespace issues. Fixes for these bugs, and maybe for the regression tests (they may or may not be correct) are desirable… as well as development related communication.

On an unrelated side note, aptituz told me that Debian etch already had Debhelper v5, and as such, the mksh package has been converted over from Debhelper v4 (yay, RCS IDs in debhelper configuration files! but what about changelog (no-no) and menu? dunno…).

mksh(1)'s "set -u" handling will change RSN to match what POSIX will mandate in the next version, matching similar changes in GNU bash 4 and AT&T ksh93.

Most of the thread can be seen on the miros-discuss@ mailing list archives (although both MARC and GMane seem to not have all related eMails... weird).

RFH: mksh development

07.07.2009 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.

mksh R38c released

10.06.2009 by tg@
Tags: mksh

The MirBSD Korn Shell R38c has been released. This is one of the everyone-should-upgrade versions because of the fixes for crashes and the likes. Read the online manual page in HTML – mksh(1) – or as PDF for printing.

mksh R38 released

31.05.2009 by tg@
Tags: bug mksh

The MirBSD Korn Shell R38b has been released. It adds portability to QNX 6.4, a built-in base64 decoder and encoder written in mksh itself, and most importantly fixes a regression introduced in R38 causing memory corruption.

This – and a lot more bugs – were discovered while porting Git (resp. running its test suite) for Michael Gebetsroither (grml).

With another mksh release out, and the first feedback (actually a patch with explanation – naaina ported it to the newly released QNX 6.4, 10x) already in, I would like to request user feedback if mksh compiles okay for them, the regression test suite results, and if it does its job – especially on the more obscure platforms. Current plans for R36b are mere portability and bug fixes, and maybe some more of the Syllable, Plan 9 or Haiku issues touched if someone does it.

On the other hand, I'm really glad I get feedback, even patches from people I've never heard of beforehand, which even touch documentation as it should be. One had the luck of adding a feature that had been, independently, requested in IRC mere days beforehand. You're welcome ;)

Let me plug a link to the fine manual page mksh(1) or its PDF version.

Thanks to all users as well, we cracked the 100 in Debian popcon a few days ago (102), even though it's down a tad right now, to 94.

Plans are to get promoted to Arch Linux Community from AUR, included into Mac OSX, Minix, pkgsrc® (as bootstrap shell) and QNX by default, and the usual world domination in general. Hey, I'm fixing dietlibc bugs on Launchpad now, so low I've sunk, so gimme some rest.

mksh R38 released

27.05.2009 by tg@
Tags: mksh

The MirBSD Korn Shell R38 has been released. Most prominently, our developer wbx@ (Waldemar Brodkorb) has suggested to allow for expansion of “!string” style lines, and several things (string lengths, substring expansion) have been made more aware of UTF-8. Grab it as long as it’s hot!

mksh semantics for evaluating substring expansion ${strvar:pos:len} and string length ${#strvar} expressions has changed today. These operations now work on characters, not on bytes. Characters are octets in non-UTFMODE (which is pretty much the same as bytes, because mksh(1) is a BSD application and, as per style(9), allowed to assume certain things about the environment) and MirOS OPTU-8 multibyte character sequences in utf8-mode.

This means things like typeset -Uui16 -Z7 wc=1#${str::1} now do the right thing (getting you the MirOS OPTU-16 wide character value of the first character in the str).

mksh R38 will thusly be released RSN.

Solución al reto del script

16.05.2009 by tg@
Tags: mksh

asarch ha escrito un artículo acerca de cómo se usa la función isatty(3) de para verificar si un script tiene datos en stdin, quizas en "$@", o para imprimir su uso.

Para el soporte oficial del mksh eres bienvenido en su canal (en inglés, ya que no todos hablan el castellano) en #!/bin/mksh (sí, sí es un nombre válido XD) del Freenode PDPC (irc.freenode.net:6667).

Update: asarch ha corregido mi español... ¡gracias!

mksh $(…) evaluation bug

22.04.2009 by tg@
Tags: bug mksh

RedHat BZ#496791 is another example of a bug I documented better in the commitids 10049EF448F5F89A278 and 10049EF493039137B14 in mksh(1).

The gist is: $(…) are not parsed recursively but by a lexer hack, namely merely looking at matching parenthesēs; this needs to go away. Until then, this bug cannot be fixed.

And while at it, ((foo); bar) subshells need to be fixed so that they are not parsed as ((…)) arithmetic expression with a failure upon encountering a sole closing parenthesis.

The mksh plans list this.

Not an mksh bug

08.04.2009 by tg@
Tags: bug debian mksh

When R37c was brought out, I fixed a bug on (among others) IA64. The simple memory allocator added a pointer (or two, in Espie's) to the storage, placed before what the user got. Of course, gcc wanted to align the struct not taking this into account, failing evilly. Luckily, another FTBFS was not my fault, but sigsetjmp(3) was merely broken on S/390 with dietlibc; waldi fixed it in the meanwhile, but I uploaded another version of mksh to Debian for now whose mksh-static binary links against glibc instead and added me a TODO bug.

All the testsuite failures are certainly interesting though; the hppa one looks like a bug in ed(1) there; as to the others, either Perl, or binfmt_misc was configured to accept or drop (but not reject) shebangs præfixed with a BOM. Whatever.

Maybe I can now finally go back to working on MirBSD instead? :D
After all, we want a new snapshot (for NetInstall, at least).

The MirBSD Korn Shell R37c has been released. You do not need to update if you are already running R37b, unless one of the following items affects you:

  • Fix a file descriptor bug on Minix 3 (all users are affected, unless their Minix 3 version supports >64 fds already)
  • Support ACK on Minix 3 by means of a workaround
  • Change structure alignment and padding (affects people getting a SIGBUS or sometimes SIGSEGV on strict-alignment arches, e.g. IA64)

Since bsiegert@ has not indicated willingness to take over Freshmeat announcements of mksh releases, and I am almost unable and certainly unwilling to, this ceases our use of said site's services. Please use https://www.mirbsd.org/tag_mksh.rss to keep informed about things related to the MirBSD Korn Shell.

All 1 2 3 4 5 6 7 8

MirOS Logo