[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


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: