Bug#267142: huh?
Clint Adams <schizo@debian.org> writes:
> But you are not calling /usr/bin/test, and the likelihood that you
> will get the GNU coreutils test without using a full path is extremely
> low.
I'm not terribly interested in "probabilities". I'm interested in
making the policy as good as possible, and no more restrictive than
necessary.
In fact, one is allowed in Debian maintainer scripts to assume that
the PATH is set appropriately, and to assume that packages you depend
on are properly installed.
FWIW, policy says not to call /usr/bin/test. Review the original bug
report.
> If you mean with regard to changing policy, I may have articulated that.
> Otherwise, I think the best course of action is for everyone to convert
> their #!/bin/bash scripts to #!/bin/sh scripts, make their #!/bin/sh
> scripts happily portable to the degree that the people who have been
> filing 10.4 sane bugs want them to be, drop the Essentialness of bash,
> and then everyone will have an easier time installing a system on a 16MB
> flash card.
Frankly, I don't give a damn about 16MB flash cards, and Policy says I
don't have to. Making Debian support 16MB flash cards may be a good
idea, but it requires a lot of work, and I don't think miscfiles is
the place to begin that work.
But my first reaction to the issue here is to simply depend on bash.
If I were to fix the bug in question, I would not alter my use of test
to comply with some foolish idea about what "looks better". To me, -a
looks better, because -a is typical for command arguments and "&&" is
not. "&&" looks like a freaky backgrounding command to me. And in
Version 7 Unix, -a was the only option, so it's really "&&" that is
the freaky novelty. To my eye, at least.
So my reaction would be to say that bash is a required package anyway,
so I can simply use /bin/bash.
But I'm not going to do that so long as policy (under my reading)
allows test -a in a /bin/sh script.
However, this makes many people unhappy, which is why the present bug
is being discussed.
Thomas
Reply to: