Re: [Fab-user] Bug in multiline append

[Jorge Vargas]

On Sun, May 24, 2009 at 3:07 PM, Jeff Forcier <address@hidden> wrote:
> Hi all,
>
> I've just applied re.escape() to the input string during the call to
> contains() (and only during that call, so the text appended to the
> file is untouched). This seems to work OK for me when passing in
> strings similar to the one that was tripping Jorge up. This change is
> in commit 534fc9f.
>
Just wanted to let you know that worked great for me. Thanks!

> Best,
> Jeff
>
> On Fri, May 22, 2009 at 1:48 PM, Jeff Forcier <address@hidden> wrote:
>> On Fri, May 22, 2009 at 1:37 PM, Jorge Vargas <address@hidden> wrote:
>>
>>> How about making them settings on the environment? is that too magical?
>>
>> Well this particular issue (whether or not to check for existence of a
>> line in a file before appending) is pretty specific to this
>> function/pair of functions, so I don't see a point in having it in the
>> global env. Just either have an option on one function, or have a 2nd
>> function calling the first and also doing the contains check.
>>
>>> well the thing is that I don't see a real usecase for append + regexp
>>> , if there is some substitution it happens before it lands to the
>>> shell, perhaps removing the call to contains and inlining the check
>>> will be best?
>>
>> I think the reason I needed normal grep and not grep -F was because of
>> the BOL anchor (^) -- i.e. calling contains() on "mystring" would,
>> unfortunately, match "# mystring", and then go "oh that line's already
>> there, so not appending". Which is wrong :( hence use of 'grep
>> "^mystring"'.
>>
>> I'll re-examine append() this weekend given all this feedback and
>> figure out what I think the best approach is.
>>
>> -Jeff
>>
>