Steve Langasek dixit: >You're aware that [ (test) is also not listed as a mandatory shell built-in, >according to the POSIX reference you've cited?
Interesting. >So from that perspective, there are lots of POSIX failures. Do you think we >should treat [ specially, but not printf, because mksh happens to implement >the one as a built-in but not the other? I see that this weakens my argumentation, but I could still mention that [ lies in /bin/ on BSD (and possibly a lot more OSes), and that (almost?) all POSIX compatible shells available on Debian implement it, whereas having printf as builtin is a feature in GNU bash, a mere speed hack in dash, and not available in many other shells. >No, portability beyond Debian is not relevant to Policy 10.4. We've never >been able to usefully rely on /bin/sh complying with POSIX on arbitrary >other Unices. I didn’t mean that; it was more in the sense of writing somewhat portable POSIX (not Bourne) shell scripts. >Does the mksh package somehow support switching /bin/sh automatically on >installation? Yes. >who want to use mksh instead of dash/bash that /usr must be on the same >partition as /. udev EXPLICITLY sets $PATH to /bin:/sbin in its init script, so that is not an option, unfortunately. >>From a Policy perspective, it would be ideal to document the set of >built-ins that we expect from a shell as /bin/sh, that scripts may rely on >prior to the mounting of /usr. Indeed. (Note that the printf in NetBSD® ash speed hack is rather recent.) >Have you looked at this set yet, by chance, >to see if there are others besides printf that mksh doesn't share with dash >and bash? Not yet, but I will and report. I also have looked at adding a printf builtin to mksh, but I don’t quite like it because it pulls in a *lot* of external symbols, including strtod, and introduces floating point into the binary. This is undesirable (also seeing that I have a project of an mksh linked against klibc, which I’d like to offer for initramfs, replacing the one from klibc-utils *and* busybox (if replacing both, at an actual size gain), for very little (in terms of disc space) cost but some benefit). bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org