"Nathan Wayde" <kumyco@xxxxxxxxxxxx> wrote: >On 09/09/10 16:19, Victor Lowther wrote: >> >> >> "Thomas Bächler"<thomas@xxxxxxxxxxxxx> wrote: >> >>> Am 08.09.2010 06:16, schrieb Victor Lowther: >>>> On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner<d@xxxxxxxxxxxxxx> >>> 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.
