[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Yet another patch + how to check for stuff in shell scripts



Russ Allbery wrote:

> Raphael Geissert <atomo64+debian@gmail.com>
> writes:
> 
>> Besides that patch, I'd like to know the opinion of others about how
>> shell scripts should be checked. At the moment checks/scripts now makes
>> use of $LEADIN as a separator/command identifier, but other checks also
>> checking for stuff in shell script don't.
>>
>> This caused me troubles when I prefixed the invoke-rc.d calls in
>> testset/scripts/debian/postinst with 'time'. Doing that caused most, if
>> not all, of checks/init.d results to be completely incorrect because it
>> failed to detect the invoke-rc.d calls.
> 
> 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.

> 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.

> 
>> Although that problem could not be avoided just by using $LEADIN
>> (because 'time' is not in the list of separators, so someone please add
>> it) similar problems can.
> 
> I don't think it makes sense to add time to $LEADIN in general, since time
> changes the nature of the command similar to adding env in front of
> something; it forces the command to be external rather than a built-in,

It depends on whether the built-in time is used or not. If the built-in is
used:

$ time [ 1 == 1 ]; echo $?

real    0m0.000s
user    0m0.000s
sys     0m0.000s
0

If not:

$ /usr/bin/time [ 1 == 1 ]; echo $?
[: ==: binary operator expected
Command exited with non-zero status 2
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+190minor)pagefaults 0swaps
2

> which means that many of the things we check for become okay, such as echo
> with flags or the full syntax of kill.
> 

It again depends, but I see your point.

Cheers,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


Reply to: