Re: Proposed new POSIX sh policy
Manoj Srivastava <srivasta@debian.org> writes:
> So, rather than specifying what /bin/sh is supposed to be,
> with all the issues about shadowing binaries etc, we start with
> specifying what the maintainer scripts must comply with.
I'm not as worried about maintainer scripts as I am about all the other
scripts, particularly init scripts which have gotten a lot of attention
lately.
lintian has been applying the policy described in my initial patch to
maintainer scripts for quite a while and no one is complaining. I think
we've mostly converged in a de facto policy with maintainer scripts,
although certainly we should discuss that and agree to it (or question it)
before turning de facto into de jure. But the situation with all the
other scripts on the system isn't necessarily as clear, or at least I'm
not as sure what we'll find when we start checking them systematically.
Discussing maintainer scripts may be a good way of starting to build a
general consensus, but note that the policy section in question is 10.4,
which applies to every shell script on the system.
> So first, maintainer scripts may continue to use essential
> package4s on the system, namely bash, but we add in a note that one
> should not sue use bash specific things, but instead it is preferred
> that maintainer scripts comply with a minimal set of features, as far
> as possible. Too many RC bugs if we try and disallow bash in
> maintainer scripts even with a proper magic #! line.
I'm not sure how worthwhile it is to even prefer a minimal set of
features, in that I don't personally see a problem with a maintainer
script that explicitly runs under #!/bin/bash and uses the full feature
set of the version of bash in the release of Debian for which the package
is targetted. I only really care what features the script uses if it uses
#!/bin/sh rather than #!/bin/bash.
(Well, I suppose I do care that not everyone just switch to bash for
scripts where performance is noticable, but I think that's a self-solving
problem. People who care about performance will notice slow spots and
report them as bugs, and premature optimization is the root of all evil.)
> So, what features do we settle on? we can either standardize
> on, well, a standard: POSIX/SUSv3, -- but there are things we use
> that come from XSI. I guess we could standardize on SUSv3 +XSI
> shells. Would still make local illegal:). The issue here sems to be
> that we are beginning to see people want to add in various and sundry
> features which are not pure POSIX just because people have been using
> it in their scripts.
This is basically why I think the best approach is to standardize on SUSv3
plus test -a/-o (with a more complete specification) and local. Our
experience with previous rounds of this discussion is that everyone seems
to be able to agree that this is a reasonable feature set, it's already
implemented by the two primary shells we care about, and anything short of
this feature set would probably break enough packages that it's easier to
improve the shell than it would be to change all the packages.
In other words, I think this hits a reasonable sweet spot between having
enough functionality to avoid making a lot of packages buggy and being
limited enough that we aren't de facto requiring bash or some equivalently
heavy-weight shell.
Adding XSI gives us test -a/-o, but it also requires things like $ENV and
test () that have not turned up as issues to date and doesn't give us
local, which is clearly an issue. So that solution doesn't fill me with
enthusiasm, although it's certainly possible that we're already expecting
XSI and I'm just not aware of it because all the shells people have tried
to use already support those features.
> The other way would be to select a bunch of shells that
> scripts must run with. This means we move away from depending on
> standards, and move to depending on implementations, warts and all.
> Suggestions have been to use dash or busybox; which would serve as
> the lowest common denominator. The lowest denominator must not be
> too different from what people are used to, or else they would just
> switch to using bash, which would defeat the purpose.
The biggest problems that I have with this solution is that I think it
leaves us without a good criteria in the future for deciding whether or
not to add a new shell to the supported list and that it's much harder for
programs like lintian to verify that packages are complying. Even with
bash, using $shell -n to check the syntax of scripts has some drawbacks
and doesn't always catch problems.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: