Manoj Srivastava <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
