Luke Kanies wrote:
> On Jul 21, 2008, at 2:08 PM, Russell Jackson wrote:
>
>> Luke Kanies wrote:
>>> On Jul 21, 2008, at 1:33 PM, Russell Jackson wrote:
>>>
>>>> Luke Kanies wrote:
>>>>> On Jul 18, 2008, at 4:55 PM, Russell Jackson wrote:
>>>>>
>>>>>> I've had a number of instances where simply doing a grep '$
>>>>>> {service-
>>>>>> name}' winds up giving
>>>>>> a false positive. Example:
>>>>>>
>>>>>> $ ps auxww | grep -v grep | grep acpid
>>>>>> root 15 0.0 0.0 0 0 ? S< Jul11 0:00
>>>>>> [kacpid]
>>>>>>
>>>>>> acpid isn't running, but the kacpid kernel thread makes puppet
>>>>>> think
>>>>>> it is; so, it keeps
>>>>>> running service acpid stop on every run. Of course, to top it off,
>>>>>> the centos4 init script
>>>>>> always returns a zero exit status value.
>>>>>>
>>>>>> Suggested fix: use the pattern '\<${service-name}\>' instead.
>>>>>>
>>>>>> Can anyone think of a case where this wouldn't work as intended?
>>>>> What does that regex do? I'm not familiar enough with grep, I
>>>>> guess.
>>>>>
>>>> '\<' and '\>' match the empty string before and after, respectively,
>>>> a word. For example,
>>>> '\<foo\>' will match 'foo' but not 'foobar' or 'afoo'
>>> I dont think we can safely assume that all of the executables will be
>>> running with whitespace; matching on word boundaries would make more
>>> sense so that, for instance, we matched '/usr/bin/puppetd', not just
>>> 'puppetd'.
>>>
>> It does match word boundaries rather than white space.
>>
>> I was just reading my ruby book. The '\b' anchor in ruby is
>> equivalent to '\<' or '\>' in
>> grep, but it doesn't care if it's the beginning or end of a word
>> like the grep version(s) do.
>
> Ah, that sounds great, then. Sounds like a good patch.
> Sounds like you're ever so subtly asking me to grind out the patch ;-). -- Russell A. Jackson <[EMAIL PROTECTED]> Network Analyst California State University, Bakersfield In a whiskey it's age, in a cigarette it's taste and in a sports car it's impossible.
smime.p7s
Description: S/MIME Cryptographic Signature
