[Top][All Lists]

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

Re: [Fab-user] Bug in multiline append

From: Jorge Vargas
Subject: Re: [Fab-user] Bug in multiline append
Date: Thu, 28 May 2009 22:44:19 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]