Re: Bug#19048: cvs-buildpackage: they should use /bin/sh and not bash
Hi,
>>"Santiago" == Santiago Vila <sanvila@unex.es> writes:
Santiago> -----BEGIN PGP SIGNED MESSAGE----- On 6 Mar 1998, Manoj
Santiago> Srivastava wrote:
Herbert> Yes but unless you actually require any non-POSIX features,
Herbert> you should use /bin/sh (this is specified by the policy). And
Herbert> currently I don't see anything like that in your scripts.
>> Where? I do not see this in
>> policy.
>>______________________________________________________________________
>> The standard shell interpreter ``/bin/sh'' may be a symbolic link
>> to any POSIX compatible shell. Thus, shell scripts specifying
>> ``/bin/sh'' as interpreter may only use POSIX features. If a script
>> requires non-POSIX features from the shell interpreter, the
>> appropriate shell has to be specified in the first line of the
>> script (e.g., ``#!/bin/bash'') and the package has to depend on the
>> package providing the shell (unless the shell package is marked
>> `Essential', e.g., in the case of bash).
>>
>> Restrict your script to POSIX features when possible so that it may
>> use `/bin/sh' as its interpreter. If your script works with ash,
>> it's probably POSIX compliant, but if you are in doubt, use
>> `/bin/bash'.
>> ______________________________________________________________________
>>
>> Where does it say I *have* to use /bin/sh? It tells me to stick to
>> POSIX features so it _could_ be used with /bin/sh. Nothing says I
>> have to use /bin/sh.
Santiago> As far as I know, "Restrict" in the above paragraph is a
Santiago> verb in imperative form.
"Restrict" ... "when possible".
Santiago> There is no point in trying to make a script POSIX compliant
Santiago> "so that it may use `/bin/sh' as its interpreter" if you do
Santiago> not end up actually setting /bin/sh as its interpreter when
Santiago> it is possible to do so.
Correct.
Santiago> I think the policy is very clear about this, since it says
Santiago> at the very beginning: "The *standard* shell interpreter
Santiago> ``/bin/sh'' ..."
All that says is that most shell scripts use /bin/sh as the
command shell. In other words, on most unices. /bin/sh is the
commonly used bourne shell.
Santiago> This means /bin/sh is the rule and /bin/bash should be the
Santiago> exception.
Nope. Non as I see it. You are extrapolating from your
interpretation of why /bin/sh is standard.
Santiago> The policy also says when you have to use the exception:
Santiago> Only when the script uses non-POSIX features.
All the policy is saying is: /bin/sh can be any of a number of
shells, so *DO NOT USE* /bin/sh unless you are sure that you
only use POSIX features. Use /bin/bash if in any doubt at all.
The policy is trying to prevent everyone from using /bin/sh
even when they use features specific to a particular implementation
POLICY is restricting the use of /bin/sh, rahter than
promoting it!
Santiago> It is true that policy says "in doubt, use /bin/bash", but
Santiago> if somebody tells you it works with ash, I think you should
Santiago> believe him at least.
Why? Why does another person know more about the future of a
script than the author? What makes them more right than me,
automatically?
The code is not done yet. When I deem it finished, and if it
still does not use bashisms, I shall think about changing it.
>> I have no idea why you are on this crusade; but leave my packages
>> out of the /bin/sh politics. Or change policy.
Santiago> The policy have already been changed to encourage /bin/sh
Santiago> over /bin/bash.
I think this is not the case. My interpretation of policy is
directly opposite yours.
Anyway, bash is essential, /bin/bash shall always be there,
using /bin/bash shall never cause any problems, using /bin/sh is just
waiting for a problem to occur, if /bin/sh is changed to another
shell which is incompatible.
My interpretation of policy minimizes potential points of
failure. Yours does not.
manoj
--
"You show me an American who can keep his mouth shut and I'll eat
him." Newspaperman from Frank Capra's _Meet_John_Doe_
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: