Re: [Fab-user] Bug in multiline append

[Jeff Forcier]

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.

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
>