Bug#490605: Bug#532324: udev init script bash+dashism: assumes printf is a builtin
Hi Thorsten,
On Wed, Jul 29, 2009 at 01:25:48PM +0000, Thorsten Glaser wrote:
> Debian Policy 10.4 states that shell scripts using a /bin/sh shebang
> line must conform to POSIX Shell, with a few (listed) exceptions.
> http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
> specifies, under “Command Search and Execution” 1.c, a list of required
> shell builtins. I cannot find printf(1) there, or in any other place of
> current SUSv3 (online edition), for that matter, except as stand-alone
> utility.
> udev uses /bin:/sbin as $PATH whereas printf(1) lies in /usr/bin.
> udev uses printf nevertheless, assuming it right because GNU bash sup-
> ports it and dash, unlike posh (I think) and other Debian Policy 10.4
> compliant /bin/sh-capable shells, implements it as a speed hack (lower
> boot times combined with portable use of printf, since echo isn’t).
> I call for the CTTE to decide that no maintainer is above Policy 10.4
> and that udev shall be fixed to not use printf as builtin, or require
> a different shebang.
You're aware that [ (test) is also not listed as a mandatory shell built-in,
according to the POSIX reference you've cited?
Yet the following list of scripts make use of it at boot time, prior to the
point at which /usr is guaranteed to be mounted:
/etc/rcS.d/S01readahead
/etc/rcS.d/S02hostname.sh
/etc/rcS.d/S02mountkernfs.sh
/etc/rcS.d/S06keyboard-setup
/etc/rcS.d/S07linux-restricted-modules-common
/etc/rcS.d/S10udev
/etc/rcS.d/S11mountdevsubfs.sh
/etc/rcS.d/S13pcmciautils
/etc/rcS.d/S15module-init-tools
/etc/rcS.d/S17procps
/etc/rcS.d/S20checkroot.sh
/etc/rcS.d/S22mtab.sh
/etc/rcS.d/S25brltty
/etc/rcS.d/S26cryptdisks-early
/etc/rcS.d/S28cryptdisks
/etc/rcS.d/S30checkfs.sh
/etc/rcS.d/S30etc-setserial
/etc/rcS.d/S35mountall.sh
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 think using printf is okay *as long* as it it possible for the
> script to pick it up in /usr/bin/ and *not* rely on an unportable
> builtin. The whole point of Policy 10.4 is portability, and maybe
> even portability beyond Debian. It _is_ well-known, after all,
> that shell and utility "echo" are both unportable. (This serves
> as comment to #490605.)
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.
Does the mksh package somehow support switching /bin/sh automatically on
installation? If not, I think the best option may be to document for users
who want to use mksh instead of dash/bash that /usr must be on the same
partition as /.
>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. 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?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: