[arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests

[Victor Lowther]

"Nathan Wayde" <kumyco at konnichi.com> wrote:

>On 09/09/10 16:19, Victor Lowther wrote:
>>
>>
>> "Thomas Bächler"<thomas at archlinux.org>  wrote:
>>
>>> Am 08.09.2010 06:16, schrieb Victor Lowther:
>>>> On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner<d at falconindy.com>
>>> wrote:
>>>>> Instead of checking for the existance of a file in
>/var/run/daemons
>>> on
>>>>> every iteration, handle the null case by setting nullglob. The
>shopt
>>>>> call is done inside a subshell as to not bother the environment
>>> since we
>>>>> may be going to runlevel 1 only temporarily.
>>>>
>>>> I thought about just enabling nullglobs and extglobs
>unconditionally
>>>> in functions, but decided that was too likely to get objections no
>>>> matter how unlikely breakage was. :)
>>>
>>> As for nullglob, I do think it is useful and enabling it might be
>>> useful
>>> in so many places - I didn't even know this option, it would have
>been
>>> useful for me before. I am in favor of enabling nullglob in function
>>> and
>>> dropping that subshell.
>>
>> Sounds good to me - nullglob is useful in general,  and enabling it
>should not break anything else in the initscripts package.
>>
>>> Do we need extglob anywhere? I don't think so.
>>
>> I will take a look.
>>
>
>I don't see anywhere in the initscripts that has this issue but you 
>might want to take a look at dotglob for the future, because with 
>nullglob you break the behaviour of commands that work like ls. i.e `ls
>
>*.ext` etc. would result in ls being passed an argument '*.ext' in the 
>event that *.ext doesn't match anything. With nullglob set, no argument
>
>gets passed and you end up with just `ls` which is likely to cause 
>subtle bugs.

Sounds like another reason to never parse the output of ls in a shell script ( not that I needed more).
-- 
Sent from my Nexus One with K-9 Mail. Please excuse my brevity.