Russ Allbery wrote: > Raphael Geissert <[EMAIL PROTECTED]> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]