Re: Yet another patch + how to check for stuff in shell scripts
Russ Allbery wrote:
> 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
Of course, $LEADIN isn't suitable for every check lintian is doing.
My main point was that several checks are actually very prone to false
positives and false negatives.
> 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.)
I've already converted checkbashisms into a perl module, and its interface.
I sent a copy of both today to Adam so he can take a look at them; there are
still two or three TODO's, but all are extras which the original
checkbashisms doesn't have.
I tried to design the module to be lintian friendly and I've even started to
implement it in checks/scripts; but I have to confess that some of the
checks being done right after the bashisms checks in checks/scripts are
painful and require special care.
The idea is to also perform all, or at least most, of the non-bashisms
checks also in Devscripts::Checkbashisms and later separate the results and
emit the necessary tags. That's what the add_hash method is for.
>
>>> 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.
Sure it is :)
>
> 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.
>
Weren't shell scripts supposed to do that? :)
IMHO using yet another command language is *not* the solution.
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Reply to: