[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: Fri, 22 May 2009 13:37:29 -0400

On Fri, May 22, 2009 at 9:21 AM, Jeff Forcier <address@hidden> wrote:
> On Fri, May 22, 2009 at 9:04 AM, Christian Vest Hansen
> <address@hidden> wrote:
>> Why do you make that check in append in the first place?
> The idea was to try and make things "repeatable" such that I could run
> a setup fab task multiple times in a row, and it would not end up
> with, say, 5 of the same line appended to a file. This stuff is taken
> directly from abstracted personal subroutines, so right now it's
> basically "my needs + some minor attempts to make things more
> generic". Hence many of these edge cases coming out.

Totally I find that a very smart approach. And it should be the way to
go. At least I"m trying to make my scripts stateless in this case (ie:
running it twice will render the same as ones). This ss also specially
useful for both testing and not screwing up your environment with
"running the wrong command"

>> "append" sounds like a procedure that does one thing: appending. Not
>> checking if something is already in the file and then maybe adding it
>> to the end. That sounds like something that could be called
>> "ensureContains" or something.
> Or we could simply expose that behavior to the user as an option, e.g.
> append('mystring', check_existence=False) or whatnot.

if you want to make this optional I vote for exist =True

> Whether to do this or make a second function leveraging the first just
> requires a bit of thought about the desired API. (Lately I've been
> waffling on whether to try and minimize things or to allow some extra
> functions that are simply convenience wrappers around existing ones,
> for example.)

How about making them settings on the environment? is that too magical?

>> Also, you could consider using fgrep or grep -F to get fixed-string
>> matching instead of regexp - this is perhaps an extension you could
>> make to "contains".
> This could be another solution to the problem, yea; especially since
> many of these functions are just wrappers around the command line
> tools, the more options we add, the better.
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?

> -Jeff

reply via email to

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