Bug#490605: Bug#532324: udev init script bash+dashism: assumes printf is a builtin
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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. My proposals: ① udev in sid will be changed to use "#!/bin/dash" as shebang; udev in lenny will be changed to use "#!/bin/bash" as shebang. The change in lenny is necessary, as it is affected as well. ② udev in both sid and lenny will be changed to not use printf any more. Both ① and ② need to override the maintainer’s decision. I would be most pleased if one of the above were to be decided upon. ③ coreutils will be changed to move /usr/bin/printf to /bin/printf and have a /usr/bin/printf@ → ../../bin/printf symbolic link. I do not like this. It is non-standard, an evil workaround, and will(!) lead to the creation of more unportable scripts. ④ dash will be changed to have the printf builtin removed, so that maintainers will be forced to change their scripts. I do not like this. Debian uses dash to provide a rather minimal /bin/sh for quick system startup. While the presence of a printf builtin is a speed hack, it serves this purpose well. Other shells, including bash, ksh93, mksh and posh, but not pdksh, can be used to validate scripts instead. ⑤ Debian changes policy to allow the use of bash+dash as /bin/sh. I do not like this, for similar reasons as in ③, as well as for the fact that I fought to have mksh an allowed /bin/sh in Debian, which has led to improvements upstream. These may be personal, but I expect this proposal to be rejected due to the unportabi- lity argument. 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.) The motion to have maintainer scripts, whether in udev or other places, fixed so that /bin/sh can be a shell other than GNU bash or dash, is supported (as in, they don't like the current situa- tion) by the DDs Alexander Wirt, Gerfried Fuchs, and possibly others. Thank you very much for your consideration. //mirabilos – mksh Debian Maintainer – Project Leader, The MirOS Project - -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MirBSD) iQIVAwUBSnBN2Ha1NLLpkAfgAQNmxQ//RCMN/DovvBuFp2nGqhm55lccA6iGLUCX EDUGcwPVX0OdWlESa6UjSswNv75kXyuAY1vX5PW09o9M/6NLQU46L+TOP6ZbGDsz dunimBEoEhw/YzZU1KkOplX7uCyOB39+cvQ4CmwP9U4N5hIGqlttDkWFO+1fwEWR yEUQ1W8h0zH9M8APGCwgGf6BbdTE2Cmx4uV+tppZ4xwEhxgH6UvjjGm6KmOsKpfl OzFIb37hhZbxpyywNzWs7Fw4Ze4PC8UqK/dbzn40LLfbQSob3bDj/dfODX0dpwoL DmelAZzrdDC5CLJASpXC05Jw3Wo2IgMkaCRWJx6/40SMdA9TKVejSD9LbnCAkamj M1M3aNdFxOW35GEXaJ4EByXGxCY9wTm93xD/f1j49zIBe/IIrfacpa9AU1YUhwaF W317xSHDJjXJGwLl5QPWGwxwV9lHvMG7K8rTiR/j/F6lMXwNf3nAQE9JvmRgnhVF D48LBygx7yXVD97Gtv4N9zv7namCDrBd5BrH4lQu2eAwWrtu5fmhODVxBEuBRt/L Sqv9ApBZaQmoE2P2ULyaEhpN4qCOi63GBzzEVuB7i2pUCfEdGTqqxP16EhK9bzzN s1L7mPagKcE2jfx1QsBGFeVafLNFs9WxyKhnjCU8V4Rj4xuCLyNCKLxO1DQw/Jx+ LTP8EfDi1xA= =1ufg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 +, 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490605: Bug#532324: udev init script bash+dashism: assumes printf is a builtin
On Wed, Jul 29, 2009 at 01:25:48PM +, Thorsten Glaser wrote: > ① udev in sid will be changed to use "#!/bin/dash" as shebang; > udev in lenny will be changed to use "#!/bin/bash" as shebang. > The change in lenny is necessary, as it is affected as well. > ② udev in both sid and lenny will be changed to not use printf > any more. > Both ① and ② need to override the maintainer’s decision. > I would be most pleased if one of the above were to be decided upon. For my part, I reject both of these; we had a discussion yesterday among four members of the TC present at DebConf, and there is a clear consensus that "echo" should be considered deprecated in favor of printf (at least in certain cases), so we should not override the maintainer for using it. > ③ coreutils will be changed to move /usr/bin/printf to /bin/printf > and have a /usr/bin/printf@ → ../../bin/printf symbolic link. > I do not like this. It is non-standard, an evil workaround, and > will(!) lead to the creation of more unportable scripts. This has the consequence of increasing the footprint of the root partition for all users, not just those who opt to install mksh. I don't think this is the appropriate tradeoff. > ④ dash will be changed to have the printf builtin removed, so that > maintainers will be forced to change their scripts. > I do not like this. Debian uses dash to provide a rather minimal > /bin/sh for quick system startup. While the presence of a printf > builtin is a speed hack, it serves this purpose well. Other shells, > including bash, ksh93, mksh and posh, but not pdksh, can be used > to validate scripts instead. This is definitely the wrong answer. > ⑤ Debian changes policy to allow the use of bash+dash as /bin/sh. > I do not like this, for similar reasons as in ③, as well as for > the fact that I fought to have mksh an allowed /bin/sh in Debian, > which has led to improvements upstream. These may be personal, > but I expect this proposal to be rejected due to the unportabi- > lity argument. I don't think we would ever want to phrase this in terms of "bash+dash", but certainly if there are built-ins common to these implementations, that we have a specific reason for wanting to let scripts rely on (e.g.: printf obsoletes echo in some cases, and echo is a required built-in), then that should be documented in Policy. Cheers, -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
