Re: Yet another patch + how to check for stuff in shell scripts
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Russ Allbery wrote:
>> Given that running invoke-rc.d under time in a Debian maintainer script
>> doesn't seem like sane behavior, I don't think I have a problem with
>> that specific case. However, in general, there are a lot of shell script
>> checks in Lintian that try to figure out what's being run, some of which
>> dealing with conditionals, and they're not done in a consistent way.
>> I would really like to see this solved by taking a higher-level look at
>> shell parsing and writing a module that has some deeper understanding
>> of conditionals or at least a structure where we can apply that. Just
>> applying $LEADIN is going to be wrong in a lot of cases. I think we
>> need
> At least on checkbashisms it has not only reduced the number of false
> positives, but even reduced the number of false negatives; because it
> knows where to start looking for a command.
Sorry, I wasn't clear. Adding $LEADIN to all the other shell parsing code
in Lintian is something that I think we want to think about very
carefully, and I wish we had a higher-level approach. It's certainly fine
for the bashism code. I'm nervous about it as a general approach to all
of the shell parsing code in lintian, such as the invoke-rc.d check and
the whole ton of other checks that look at what maintainer scripts do or
don't run.
Regardless of which way we do this, it really does need to be in a module
rather than embedded direction in the checks/* scripts, so that we have
one place that does the work consistently and which we can change if we
need to in order to cope with additional cases. (We need that anyway in
order to do bashism checks on debian/rules and on other scripts than
maintainer scripts.)
>> a documented module with a clearer picture of what it can and can't do
>> which understands some of the common conditional constructs, such as
>> checking whether a command exists, and tracks things like if/fi
>> nesting.
> Well, that would be even more complex and complicated; and if it were so
> easy I can be sure that someone would have already written such a
> module.
Well, what I'm trying to get at is that the current situation is fragile,
and making it more fragile is not appealing. From a maintainability
standpoint, the current shell parsing in Lintian is some of the hardest
code to both understand and keep working.
Parsing shell scripts with regexes is extremely painful.
The best solution for Debian as a whole, IMO, would be to develop a mini
command language that could do 90% of what maintainer scripts do and leave
shell in the same bucket that Perl is in now: only necessary for weird
cases where the maintainer can then be presumed to know what they're
doing. But that's obviously outside the scope of what Lintian can do.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: