Please move printf to /bin so that scripts can use it when /usr is not
mounted.

Hi Michael.

Has there been any progress or review on this issue?

Perhaps you've noted the following thread I've opened on debian-devel:
http://lists.debian.org/debian-devel/2010/07/msg00192.html


Regardless of the debate on what "essential" actually means (per
policy),... I guess it would be really a good idea to put some things
from /usr/bin to /bin... because they're likely to be used during system
initialisation.

printf is only one of them, but perhaps a prominent example, as at least
POSIX suggests to use it instead of echo.

While bash/dash seem to have a built-in printf, this is not true for all
shells. And in place it's mandated, that a shell must have such
built-ins.
The same is btw true for echo.

But I guess many other stuff (e.g. id, stat, base64) is used during
system initialization.


I'm currently writing a new version of /etc/init.d/skeleton which I'll
propose as a (hopefully better) replacement for the current one.
I'll add some notes, that init-script writes have to take care, that not
everything from essential packages and not even als basic SUSv3
utilities are there.... but I strongly believe that this is not the way
it should be.



Cheers,
Chris.

Hi,

there have been systems failing to boot in the past (#532324) because
there was no consensus about what scripts may assume that /bin/sh
implements.

Due disagreement on #532324, the Technical Committee was called to decide
in #539158.  Their decision was:
| 1. The Technical Committee refuses to overrule the udev maintainer, as
| requested by Bug 539158. The committee suggests that the policy
| maintainers document in the policy what the current best practices on
| providing printf (and similar functions used in the initrd like [ and
| test) by shells.

I think not overruling udev's maintainer was correct, because #532324
was just one symptom of an underlying problem and just fighting symptoms
is wrong.  The underlying problem is that the policy does not reflect
reality, or, vice versa, that reality does not care about section 10.4
of the policy.

Imagine, for example, what could happen if 'which' would not work until
/usr/ is mounted[1]. 'setupcon', that is used to setup the console
during boot, also uses 'printf', but luckily not the part that currently
is run before mounting.  Not requiring '[' as builtin command without
providing /bin/[ is also wrong, and even if nobody ever would build such
a shell, policy and reality should match (at least for documentation
purposes).

There are also a few bugs somehow related to /bin/sh, among them #538822
and #540512.  A sane solution to the /bin/sh related bugs might enable
additional shells to become /bin/sh.  This would significantly raise the
probability of bugs similar to #532324 to occur.

I see two possible ways solve this problem without requiring to remove
'printf' from various scripts:

 1. Move the binaries 'printf', '[' and 'test' to /bin with
    compatibility symlinks in /usr/bin.

 2. Adapt the Debian policy to require 'printf', '[' and 'test' as
    builtin commands for all shells that can be used as /bin/sh.


Moving the binaries to /bin has already been requested in #532343.
Quoting the relevant part[2]:
| >would you be willing to move [, printf and test to /bin/ and place
| >symlinks to them in /usr/bin/ to help resolving this problem?
|
| Not really, as to be consistent you'd need *all* posix utilities in
| /bin. I'd rather just say that debian supports all posix commands, shell
| builtin or not, once /usr is mounted. Anything else is just too
| complicated (and affects more than just this specific case, and more
| than just coreutils).

Your decision seems to be based on the assumption that the reason why
this was requested was to comply with POSIX, even before /usr is
mounted.

A more appropriate reason for this request is to improve the conformance
between Debian's policy and its userland.

Having these binaries in /bin/ would also:
 * avoid the need to adapt (nearly?) all shells before they are eligible
   to become /bin/sh in Debian
 * avoid the need to adapt the Debian policy accordingly[3]
 * make the way 'printf' is provided consistent to the way its
   predecessor[4] 'echo' is provided


Please reconsider your decision regarding moving these binaries to
/bin.

If you do not want to move them, please reassign this bug to
"debian-policy" and retitle it to "debian-policy: please require builtin
printf, test and [ by system shells".


Thanks
Carsten

 [1] /bin/which uses printf on non-ksh shells, though there is
     a possible workaround for this:
http://git.eyrie.org/?p=devel/c-tap-harness.git;a=commitdiff;h=83dc5bef09e6dd6fef60debf257039b758f2a43b

 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532343#57

 [3] Otherwise at least the '[' and 'test' part would require to be
     fixed and very likely the 'printf' part too.

 [4] POSIX reads: "New applications are encouraged to use printf instead
     of echo".

Good question.

I had moved true and false to /bin in MirBSD to match coreutils.
Apparently (also, from the d-devel thread), besides printf, [ and
test are missing in /bin (they are there in MirBSD).

The problem here is that printf is used in early boot, and without
/usr/bin on the PATH.

bye,
//mirabilos

+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

On Thu, Oct 16, 2014 at 09:45:08AM +0200, Thorsten Glaser wrote:
[...#428189]
[...]

I'm somewhat inclined to say that it's futile at this point to try to
maintain the /bin + /usr/bin distinction. The reality is that the
historic purpose of /bin is basically met by initrd, which is based on
busybox and not coreutils (and which already has printf in /bin). All
that said, I don't have a particular objection to moving printf, but
I've been moving things in a whack-a-mole fashion for years and am not
sure what coreutils binaries should *not* be in /bin. I could make the
coreutils directory structure match the de facto reality of what is in
the initrd /bin, but will that remain static? Or I could just move
everything in coreutils to /bin. I'm open to suggestions.

Mike Stone

Right, but again, the question is what might *not* be used in early
boot? I increasingly lean toward just moving the whole thing to /bin and
to hell with it, but is there a downside to that?

Mike Stone