mksh tag cloud

Sponsored by
HostEurope Logo

mksh tag cloud

⚠ 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

I’m currently working on an mksh(1) and bc(1) script that takes a pitch standard (e.g. “A₄ = 440 Hz” or “C₄ = 256 Hz”) and a config file describing a temperament (e.g. the usual equal temperament, or Pythagorean untempered pure fifths (with the wolf), or “just” intonation, Werckmeister Ⅲ, Vallotti or Bach/Lehman 1722 (to name a few; these are all temperaments that handle enharmonics the same or, for Pythagorean in out case, ignore the fact they’re unplayable). Temperaments are rule-based, like in ttuner. Well, I’m not quite there yet, but I’m already able to display the value for MuseScore to adjust its pitch standard (it can only take A₄-based values), a frequency table, and a list and table of cent deltas (useful for using or comparing with other tuners). Of course, right now, the cent deltas are all 0 because, well, they are equal temperament against equal temperament (as baseline), but I can calculate that with arbitrary and very high precision!

For outputting, I wanted to make the tables align nicely; column(1), which I normally use, was out because it always left-aligns, so I used string padding in Korn Shell — except I’m also a Unicode BMP fan, so I had F♯ and B♭ in my table headings, which were for some reason correctly right-aligned (for when the table values were integers) but not padded right when aligning with the decimal dot. So I worked around it, but also investigated.

Turns out that the desired length was used as second snprintf(3) argument, instead of, as in the right-align case, the buffer size. This worked only until multibyte characters happened. A fun bug, which only took about three minutes to find, and is covered by a new check in the testsuite even. Thought I’d share.

Feedback on and improvements for the tuner, once it’ll be done, are, of course, also welcome. I plan to port the algorithm (once I’ve got it down in a programming language I know well) to QML for inclusion in the tuner MuseScore plugin, even. Check here, for now, for my work in progress… it’s quite big already despite doing basically nothing. Foundation laid (or so…).

mksh on Jehanne, a guest post by Shamar

2018-04-15 by tg@
Tags: archaeology debian fun guest mksh pcli

Giacomo Tesio referenced mksh(1) in his annual Jehanne report and provided a guest post (dated 2018-01-09, sorry for posting it this late only) for us on his journey on porting mksh to Jehanne, his Plan 9 derivative operating system. Read on for his story!

MirBSD's Korn Shell on Plan9 Jehanne

Let start by saying that I'm not really a C programmer.
My last public contribution to a POSIX C program was a little improvement to the Snort's react module back in 2008.

So while I know the C language well enough, I do not know anything about the subtliness of the standard library and I have little experience with POSIX semantics.

This is not a big issue with Plan 9, since the C library and compiler are not standard anyway, but with Jehanne (a Plan 9 derivative of my own) I want to build a simple, loosely coupled, system that can actually run useful free software ported from UNIX.

So I ported RedHat's newlib to Jehanne on top of a new system library I wrote, LibPOSIX, that provides the necessary emulations. I wrote several test, checking they run the same on Linux and Jehanne, and then I begun looking for a real-world, battle tested, application to port first.

I approached MirBSD's Korn Shell for several reason:

  • it is simple, powerful and well written
  • it has been ported to several different operating systems
  • it has few dependencies
  • it's the default shell in Android, so it's really battle tested

I was very confident. I had read the POSIX standard after all! And I had a test suite!
I remember, I thought "Given newlib, how hard can it be?"

The porting begun on September 1, 2017. It was completed by tg on January 5, 2018. 125 nights later.

Turn out, my POSIX emulation was badly broken. Not just because of the usual bugs that any piece of C can have: I didn't understood most POSIX semantics at all!


First, Cinap had to patiently explain me on #cat-v that UNIX signals are reentrant.
It took him a while: I wasn't able to understand.
Even now, I keep asking: "Why?!? Why they did this! why..."


Fixed that, I saw that mksh was unable to execute ls: in Plan 9 common environment variables are lower case.
The $PATH variable is called $path, the $CDPATH variable is called $cdpath and so on.
Also, when appropriate, they are NULL separated char arrays, since they are exposed as files from the env device, and rc can get their size with a simple seek.

I reflected on the issue for a while, tried several solutions to preserve both conventions (some of which even worked).
But finally, I surrended to the simplest solution: I adopted the POSIX convention for Jehanne.

Aesthetics amuse, but simplicity helps.

However it was not enough: I needed to hook mksh startup to read the variables from the filesystem (just like rc does). How to do that cleanly? I asked on #!/bin/mksh and tg did not simply explained a poor noob how to do that. He did it himself!

I was enchanted by his kindness. So far Jehanne is just a toy. Still he spent his own time for me.


But the journey was still ongoing.

I realized that to run a command, mksh requires SIGCHLD support. I added it. The first implementation worked.


It was able to run exactly one command in mksh. The shell stopped reading input after the second one.

So I wrote it again from scratch. And it worked! Yuppy! :-)

Till I tried echo test | grep test

Grep didn't get EOF, as mksh for some strange reason was keeping the pipe open.
I extended devdup to ensure fcntl's emulation was working as expected. I rewrote fcntl emulation. Still broken.

Out of despair I turned to annoy tg again over IRC. Talking with him I realized that the problem was the signal dispatching. So I rewrote it again, introducing a new 9P2000 file server that handles signal IPC among POSIX processes, taking care of masks, ignored signals, waited ones.

Finally echo test | grep test worked.



mksh was blaming me with two annoying warnings:

mksh: No controlling tty: open /dev/tty: No such file or directory
mksh: warning: won't have full job control

I asked tg and he tried to explain me what /dev/tty is, providing links about /dev/tty, /dev/ttyN and /dev/console.

So I modified vt (and later hmi/pipeconsole) to provide /dev/tty as an alias to /dev/cons.

The first warning was gone... but only the first one!

It was not just a matter of warnings: I was unable to interrupt a script (what you do with Ctrl+C on unix).


Down the rabbit hole, again.

I had to study the complex semantics of tty job control (asking boring questions to tg, again).
I had to fix setsid, getsid, setpgid, getpgid, getpgrp and to add support for termios' tcgetpgrp and tcsetpgrp.
Worse: I had to mostly rewrite the file server I had just written. Sob!

It took a while.
In the process I realized that a sys/posixly instance actually represents a single terminal session..


... did I say it took a while?


Then, suddenly... I saw this, and it was like an epiphany:

mksh running in Jehanne with full job control


MirBSD's Korn Shell was working on Jehanne! What a happy new year! :-D

mksh R56 was released with experimental fixes for the “history no longer persisted when HISTFILE near-full” and interactive shell cannot wait on coprocess by PID issues (I hope they do not introduce any regressioins) and otherwise as a bugfix release. You might wish to know the $EDITOR selection mechanism in dot.mkshrc changed. Some more alias characters are allowed again, and POSIX character classes (for ASCII, and EBCDIC, only) appeared by popular vote.

mksh now has a FAQ; enjoy. Do feel free to contribute (answers, too, of course).

The jupp text editor has also received a new release; asides from being much smaller, and updated (mksh too, btw) to Unicode 10, and some segfault fixes, it features falling back to using /dev/tty if stdin or stdout is not a terminal (for use on GNU with find | xargs jupp, since they don’t have our xargs(1) -o option yet), a new command to exit nonzero (sometimes, utilities invoking the generic visual editor need this), and “presentation mode”.

Presentation mode, crediting Natureshadow, is basically putting your slides as (UTF-8, with fancy stuff inside) plaintext files into one directory, with sorting names (so e.g. zero-padded slide numbers as filenames), presenting them with jupp * in a fullscreen xterm. You’d hit F6 to switch to one-file view first, then present by using F8 to go forward (F7 to go backward), and, for demonstrations, F9 to pipe the entire slide through an external command (could be just “sh”) offering the previous one as default. Simple yet powerful; I imagine Sven Guckes would love it, were he not such a vim user.

The new release is offered as source tarball (as usual) and in distribution packages, but also, again, a Win32 version as PKZIP archive (right-click on setup.inf and hit I̲nstall to install it). Note that this comes with its own (thankfully local) version of the Cygwin32 library (compatible down to Windows 95, apparently), so if you have Cygwin installed yourself you’re better off compiling it there and using your own version instead.

I’ve also released a new DOS version of 2.8 with no code patches but an updated jupprc; the binary (self-extracting LHarc archive) this time comes with all resource files, not just jupp’s.

Today, the jupprc drop-in file for JOE 3.7 got a matching update (and some fixes for bugs discovered during that) and I added a new one for JOE 4.4 (the former being in Debian wheezy, the latter in jessie, stretch and buster/sid). It’s a bit rudimentary (the new shell window functionality is absent) but, mostly, gives the desired jupp feeling, more so than just using stock jstar would.

CVS’ ability to commit to multiple branches of a file at the same time, therefore grouping the commit (by commitid at least, unsure if cvsps et al. can be persuaded to recognise it). If you don’t know what cvs(GNU) is: it is a proper (although not distributed) version control system and the best for centralised tasks. (For decentral tasks, abusing git as pseudo-VCS has won by popularity vote; take this as a comparison.)

If desired, I can make these new versions available in my “WTF” APT repository on request. (Debian buster/sid users: please change “https” to “http” there, the site is only available with TLSv1.0 as it doesn’t require bank-level security.)

I’d welcome it very much if people using an OS which does not yet carry either to package it there. Message me when one more is added, too ☺

In unrelated news I uploaded MuseScore 2.1 to Debian unstable, mostly because the maintainers are busy (though I could comaintain it if needed, I’d just need help with the C++ and CMake details). Bonus side effect is that I can now build 2.2~ test versions with patches of mine added I plan to produce to fix some issues (and submit upstream) ☻

In other news, I’m working on a new i386+sparc MirBSD snapshot more than ever. Mostly to get everything old out from under my feet before tackling the LibreSSL import (to get TLSv1.2 support, due to the aforementioned idio…decision). I’ve yet to see whether our G++ port works on sparc, and I’ve yet to create ports for libGLU and xlock which used to be in the base X system but had to go away for being written in an unmaintainable language (plus a system is only reliable if it has only one libstdc++), but it’ll be a good stepping stone (plus mfny asked for a sparc snapshot on IRC). I was considering distributing ISOs at FrOSCon but, with an installed user base in the single digits (likely), you can imagine how useful that’d be. (Fun side idea: distribute ISOs with a boot menu where you can choose not only MirBSD installer or live system but also “minimal Debian system directly booting into the MirBSD live system running under qemu-kvm”. But I’ve got not enough spare time right now.)

Hurried snapshot and known issues

2017-08-07 by tg@
Tags: mksh pcli plan snapshot

As already mentioned I planned creating a new snapshot. Well, it will be out shortly, albeit in a hurried manner and not with everything I had planned for it, and with lagging sparc (as if that were new, though…). A hurried mksh release will there be as well. The reason for this is the top #1 known issue:

  • Debian OpenSSL now excludes TLS < 1.2 from communication
    ⇒ there will be some followup release with LibreSSL, I think
  • There’s still no port for libGLU and xlock
  • We didn’t import lzlib into base yet, nor recent fixes to pax(1) from OpenBSD necessary
  • The new Unicode property code is not written yet (although I fixed the data shipped so it matches, at least)
  • I didn’t test g++ from ports on sparc yet, we’ll see how that goes

That being said, you’ll be able to work with what I’ve got, like in olden times when MirBSD was defined as “the contents of my /usr/src and /usr/ports” and be assured that, besides working on things like MuseScore in the meantime, I’m on it.

An unrelated minor update to another recent post; apparently I managed to make the GitHub Legal people aware enough of the problems that they are working on fixing their ToS; I admit there’s been an update since August 1ˢᵗ/2ⁿᵈ which I haven’t yet gotten around to reading at all.

wtf rocks; Eugen is working on an iOS äpp and already has a beta version which just needs bugfixing.

Beltane Snapshot and Mainframe Korn Shell…ish

2017-05-05 by tg@
Tags: mksh pcli plan snapshot

I was planning to do an mksh R56 release and then a full MirBSD snapshot (i386, sparc — due to actual user request — and possibly even a Live CD or at least baselive) but this got stones on my way.

I’m not quite finished with what I originally had planned for R56 (basically, the Debian postfix package’s maintainer scripts started using character classes in bracket expressions, and this required not only careful planning and design but also quite some rewriting and thinking, fixing other bugs, reading the specs, and considering EBCDIC) which led to me asking the EBCDIC porter some things again, which led to trying to merge his outstanding patches and make R56 the Mainframe Korn Shell release (also mksh ;-) but we’re not quite there yet.

The MirBSD snapshot was planned to be started from CVS as of Beltane (Walpurgis) 2017 except the latest and greatest mksh is also kinda a requirement, and CVE fixes are tricking in, to add insult to injury for stuff I had just updated. I’d also love to have the latest sendmail and lynx in it but that’ll have to wait.

I’ll also do a new CVS snapshot tarball at the same time, so keep your eyes open for the new rolling MirBSD snapshot.

Somehow, spring weather does not agree with me anyway. I didn’t get much done, nor much good sleep. Private life’s looking up but also more busy. I do manage to still help out others even in code I don’t really understand… must be good karma. Vacation would be nice… but then, I know I wouldn’t get all out of it.

The MirBSD Korn Shell R52c was published today as bugfix-accumulating release of low upto medium importance. Thanks to everyone who helped squashing all those bugs; this includes our bug reporters who always include reproducer testcases; you’re wonderful!

MirCPIO was also resynchronised from OpenBSD, to address the CVE-2015-{1193,1194} test cases, after a downstream (wow there are so many?) reminded us of it; thanks!
This is mostly to prevent extracting ../foo — either directly or from a symlink(7) — from actually ending up being placed in the parent directory. As such the severity is medium-high. And it has a page now — initially just a landing page / stub; will be fleshed out later.

Uploads for both should make their way into Debian very soon (these are the packages mksh and pax). Uploading backports for mksh (jessie and wheezy-sloppy) have been requested by several users, but none of the four(?) DDs asked about sponsoring them even answered at all, and the regular (current) sponsors don’t have experience with bpo, so… SOL ☹

I’ve also tweaked a bug in sed(1), in MirBSD. Unfortunately, this means it now comes with the GNUism -i too: don’t use it, use ed(1) (much nicer anyway) or perlrun(1) -p/-n…

Finally, our PDF manpages now use the PA4 paper size instead of DIN ISO A4, meaning they can be printed without cropping or scaling on both A4 and US-american “letter” paper. And a Бодун from the last announcement: we now use Gentium and Inconsolata as body text and monospace fonts, respectively. (And à propos, the website ought to be more legible due to text justification and better line spacing now.) I managed to hack this up in GNU groff and Ghostscript, thankfully. (LaTeX too) Currently there are PDF manpages for joe (jupp), mksh, and cpio/pax/tar.

And we had Grünkohl today!

Also, new console-setup package in the “WTF” APT repository since upstream managed to do actual work on it (even fixed some bugs). Read its feed if interested, as its news will not be repeated here usually. (That means, subscribe as there won’t be many future reminders in this place.)

The service appears to be gone. I’ll not remove our images, but if someone knows what became of it drop us a message (IRC or mailing list will work just fine).

PS: This was originally written on 20160304 but opax refused to be merged in time… Happy Birthday, gecko2! In the meantime, the Street Food festival weekend provided wonderful food at BaseCamp, and headache prevented this from being finished on the fifth.

Update 06.03.2016: The pax changes were too intrusive, so I decided to only backport the fixes OpenBSD did (both those they mentioned and those silently included), well, the applicable parts of them, anyway, instead. There will be a MirCPIO release completely rebased later after all changes are merged and, more importantly, tested. Another release although not set for immediate future should bring a more sensible (and mksh-like) buildsystem for improved portability (and thus some more changes we had to exclude at first).

I’ve also cloned the halfwidth part of the FixedMisc [MirOS] font as FixedMiscHW for use with Qt5 applications, xfonts-base in the “WTF” APT repo. (Debian #809979)

tl;dr: mksh R52c (bugfix-only, low-medium); mircpio 20160306 (security backport; high) with future complete rebase (medium) upstream and in Debian. No mksh backports due to lacking a bpo capable sponsor. New console-setup in “WTF” APT repo, and mksh there as usual. xfonts-base too. gone?

Our PDF manpages will, starting from now, be generated with Inconsolata instead of Bitstream Vera Mono as monospace font. The body font is still Gentium, of course.

To be more exact: the Teχ flavour of Inconsolata Regular and Bold, with the varl and varqu flags, is used, and because GNU groff also requires an Italic or at least Oblique font (also in its bold variant, which the mksh(1) manpage doesn’t use though), Inconsolata LGC (both Italic and Bold Italic) are plugged in there. I added them as PFA Type 1 fonts to GNU groff, so I had to make some fixes in FontForge (merging the variants into the main font, removing unused glyphs (not for LGC), fixing the validation (mostly, and not so much for LGC), autohinting where FontForge expressed a need for that, renaming glyphs to the names expected by afmtodit, …), but it works.

I’m not regenerating older PDF manpages though.

Inconsolata is also not all I wish for a monospaced font (and even bsiegert@ says nothing goes over FixedMisc) but it has, at least, a 0 (digit zero) with a correct stroke through it ☺

I just published the first version of git find on gh/mirabilos/git-find for easy collaboration. The repository deliberately only contains the script and the manual page so it can easily be merged into git.git with complete history later, should they accept it. git find is MirOS licenced. It does require a recent mksh (Update: I did start it in POSIX sh first, but it eventually turned out to require arrays, and I don’t know perl(1) and am not going to rewrite it in C) and some common utility extensions to deal with NUL-separated lines (sort -z, grep -z, git ls-tree -z); also, support for '\0' in tr(1) and a comm(1) that does not choke on embedded NULs in lines.

To install or uninstall it, run…

	$ git clone
	$ cd git-find
	$ sudo ln -sf $PWD/git-find /usr/lib/git-core/
	$ sudo cp git-find.1 /usr/local/share/man/man1/
	… hack …
	$ sudo rm /usr/lib/git-core/git-find \

… then you can call it as “git find” and look at the documentation with “git help find”, as is customary.

The idea behind this utility is to have a tool like “git grep” that acts on the list of files known to git (and not e.g. ignored files) to quickly search for, say, all PNG files in the repository (but not the generated ones). “git find” acts on the index for the HEAD, i.e. whatever commit is currently checked-out (unlike “git grep” which also knows about “git add”ed files; fix welcome) and then offers a filter syntax similar to find(1) to follow up: parenthesēs, ! for negation, -a and -o for boolean are supported, as well as -name, -regex and -wholename and their case-insensitive variants, although regex uses grep(1) without (or, if the global option -E is given, with) -E, and the pattern matches use mksh(1)’s, which ignores the locale and doesn’t do [[:alpha:]] character classes yet. On the plus side, the output is guaranteed to be sorted; on the minus side, it is rather wastefully using temporary files (under $TMPDIR of course, so use of tmpfs is recommended). -print0 is the only output option (-print being the default).

Another mode “forwards” the file list to the system find; since it doesn’t support DOS-style response files, this only works if the amount of files is smaller than the operating system’s limit; this mode supports the full range (except -maxdepth) of the system find(1) filters, e.g. -mmin -1 and -ls, but it occurs filesystem access penalty for the entire tree and doesn’t sort the output, but can do -ls or even -exec.

The idea here is that it can collaboratively be improved, reviewed, fixed, etc. and then, should they agree, with the entire history, subtree-merged into git.git and shipped to the world.

Part of the development was sponsored by tarent solutions GmbH, the rest and the entire manual page were done in my vacation.

izabera did make a good point in IRC the other day for why we will need to have two locales at the very least in MirBSD – C and C.UTF-8 (the latter being widespread enough by now, thanks to me, interestingly enough. He uses code which leads to unexpected results…

	$ generate() { tr -dc "[:alnum:]" < /dev/urandom | dd bs="$len" count=1; }
	$ len=10; echo $(generate 2>/dev/null)

… because tr(1) was the first utility I converted to Unicode, to explore possibilities and craft the OPTU encoding and, thus, “流” is, indeed, an alphanumeric character.

This implies two things: we need to change MirBSD libc locale functions back to support two charsets (and make setlocale(3) match), and mksh(1) should implement locale tracking (to change set ±U whenever one of the relevant parameters (${LC_ALL:-${LC_CTYPE:-${LANG:-C}}}) changes in the session; users could still set utf8-mode manually though). For this to not break anything, we’ll have to audit scripts in MirBSD though (usually adding export LC_ALL=C at their begin is enough, and we need this for portable scripts anyway) and remove all occurrences of #ifndef __MirBSD__ before setlocale(3) calls in applications. This will take a while.

Secondly, I opened an issue with POSIX about handling of the (deprecated, and for good reason) `-style command substitutions. The GNU autoconf texinfo manual gives good advice for portable shell scripts, and we all knew that foo="bar `echo \"baz\"`" wasn’t portable due to use of more than one set of double quotes, but my (and the yash authors’) reading of the standard (and mksh R52’s POSIX mode) make it set $foo to bar "baz" instead of the historic bar baz now, and I wish to get this clarified (and, possibly, the standard changed to match historic practice, as this breaks at least the Acrobat Reader 5 start script). Nothing has been decided yet (due to the holidays, I’m sure), but we got input from some other people involved in shell.

So, if any #!/bin/sh scripts break or behave weirdly with R52, you now know why. I’m waiting for an official statement.

mksh R52 released

2015-12-12 by tg@
Tags: mksh pcli

The MirBSD Korn Shell R52 was published today. While there are still several known bugs, this is a release that primarily fixes lots of these, and, as with R51, we have no known regressions. Some of the itinerary for R52 has moved to R53 instead, as some bugfixes change the shell language and thus warrant a new major version, which is why this is not R51b, and they accumulated and could use some testing ;-)

This release has a nōnzero chance to break existing scripts that use some extension features – I had to quote some tildes in dot.mkshrc and a variable expansion in ${x/y"$z"} in MirWebseite (the $z) – twice!. As usual, test!

In less related news, a new release of the FixedMisc [MirOS] font is available (in BDF form and no conflict with the system Fixed [Misc] font); our CVS has the sources in bdfctool(1) format.

The MirBSD Korn Shell R51 was published today. This is a feature release clearly, but still something a lot of people would wish to use. It contains several known severe bugs, but they all are no regressions, i.e. they exist in R50f already.

This one is kinda an early release, as I wish to have those known issues all fixed, but the changes – both deep down and enduser-visible – already warrant people looking for breakages, plus it makes synchronisation with mksh-os2 easier.

mksh R52 will follow, as bugfix release, pretty soon. Itinerary:

  • Fixes for as much of these known bugs as possible (code rewrites)
  • Unicode 8
  • New feature: print -a
  • Fixes for bugs reported against R51
  • Possibly more EBCDIC and OS/2 code synchronisation
  • Maybe a dead useful debug tool…

Once that’s out, I’ll roll up the fixes into R50g, so that particular code branch is not dead yet either ☺

And afterwards, at least mksh(1)-wise – I have got a lot of other things on my plate after all – we can attempt getting EBCDIC and maybe OS/2 to a state where the code is included in CVS.

carstenh asked in IRC how to make a shebang for mksh(1) scripts that works on both regular Unix and Android.

This is not as easy as it looks, though. Most Unicēs will have mksh installed, either manually or by means of the native package system, as /bin/mksh. Some put it into package manager-specific directories; I saw /sw/bin/mksh, /usr/local/bin/mksh and /usr/pkg/bin/mksh so far. Some systems have it as /usr/bin/mksh but these are usually those who got poettering’d and have /bin a symlink anyway. Most of these systems also have env(1) as /usr/bin/env.

Android, on the contrary, ships with precisely one shell. This has been mksh for a while, thankfully. There is, however, neither a /bin nor a /usr directory. mksh usually lives as /system/bin/mksh, with /system/bin/sh a symlink(7) to the former location. Some broken Android versions ship the binary in the latter location instead and do not ship anything that matches mksh on the $PATH, but I hope they merge my AOSP patch to revert this bad change (especially as some third-party Android toolkits overwrite /system/bin/sh with busybox sh or GNU bash and you’d lose mksh in the progress). However, on all official Android systems, mksh is the system shell. This will be important later.

The obvious and correct fix is, of course, to chmod -x the scripts and call them explicitly as mksh scriptname. This is not always possible or desirable; sometimes, people will wish it to be in the $PATH and executable, so we need a different solution.

There’s a neat trick with shebangs — the absence of one is handled specifically by most systems in various ways. I remember reading about it, but don’t remember where; I can’t find it on Sven Mascheck’s excellent pages… but: the C shell variants run a script with the Bourne Shell if its first line is a sole colon (‘:’), the Bourne family shells run it with themselves or ${EXECSHELL:-/bin/sh} in those cases, and the kernel with the system shell, AFAIK. So we have a way to get most things that could call the script to interpret it as Bourne/POSIX shell script on most systems. Then we just have to add a Bourne shell scriptlet that switches to mksh iff the current shell isn’t it (lksh, or something totally different). On Android, there is only ever one shell (or the toolkit installer better preserve mksh as mksh), so this doesn’t do anything (I hope — but did not test — that the kernel invokes the system shell correctly despite it not lying under /bin/sh) nor does it need to.

This leaves us with the following “shebang”:

	case ${KSH_VERSION-} in
	*MIRBSD\ KSH*) ;;
	*)	# re-run with The MirBSD Korn Shell, this is an mksh-specific script
		test "${ZSH_VERSION+set}" = set && alias -g '${1+"$@"}'='"$@"'
		exec mksh "$0" ${1+"$@"}
		echo >&2 E: mksh re-exec failed, should not happen
		exit 127 ;;

The case argument not only does not need to, but actually should not be quoted; the expansion is a set -u guard; the entire scriptlet is set -e safe as well; comments and expansions are safe. exec shall not return, but if it does (GNU bash violates POSIX that way, for example), we use POSIX’ appropriate errorlevel. zsh is funny with the Bourne shell’s way of using "$@" properly. But this should really be portable. The snippet is both too short and too obvious (“only way to do it”) to be protected by copyright law.

Thanks to carstenh and Ypnose for discussing things like this with us in IRC, sending in bugfixes (and changes we decline, with reason), etc. — it feels like we have a real community, not just consuments ☺

All 1 2 3 4 5 6 7 8 9

MirOS Logo