Re: [RFC/PATCH] Unify handling of known shell names
On Sat, 2008-09-13 at 22:47 +0200, Frank Lichtenheld wrote:
> Several places search for known shell names. As one can see in the
> code they diverged over time. Move the regex to common_data.pm to
> avoid that happening in the future.
>
> Also add mksh while at it.
[...]
> 1) Is it correct to change $within_another_shell to match /bin/sh?
Looking through the current code, I've been inclined to say both no and
yes, and changed my mind at least twice. I think I've settled on "no",
but wanted to explain my reasoning a little.
$within_another_shell is only used to check whether a script line should
be checked for bashisms. Since we explicitly exclude /bin/sh scripts
from the bashism checks, it seems inconsistent to treat a /bin/sh script
differently from the line "/bin/sh -c foo" inside a script using a
different interpreter.
fwiw, the nearest equivalent test in checkbashisms treats posh as
equivalent to sh when deciding whether to check a script.
> 2) Is it correct to not ignore t?csh in menus/infofiles (this code
> should really be further unified in a follow-up patch BTW)?
Technically Policy doesn't impose any limits on the interpreter that can
be used for a maintainer script. Obviously the package must ensure that
the appropriate {Pre,}Dependencies exist, but that's outside the scope
of what the checks in question need to care about - and we're already
allowing ksh, which won't be installed by default either.
Which is a long-winded way of saying "yes, imho". :)
Adam
Reply to: