Re: [Fab-user] Output of local()

[Jeff Forcier]

I'm working on this now; I think the best approach is to update
_start_outputter() to handle *either* Paramiko channels *or* file-like
objects, since almost all of its logic just deals with chunks of text,
and ideally we should (I assume) have the same behavior for both local
and remote commands, in terms of prompt detection, printing/capturing
simultaneously, and printing "as we go" instead of waiting for the
entire process to wrap up.

Will let y'all know if this turns out to be a good idea :D

-Jeff

On Tue, Feb 10, 2009 at 7:57 AM, Jeff Forcier <address@hidden> wrote:
> On Tue, Feb 10, 2009 at 3:08 AM, Sverre Johansen
> <address@hidden> wrote:
>
>> And probably you don't want to capture the output of every command, and 
>> rather
>> make it optional - both for local and run/sudo.
>>
>> What do you think about adding separate functions for setting variables
>> from commands, or having an optional argument that enables this?
>
> I think having an optional argument is the better approach; having a
> 2nd set of functions is just cluttering the namespace and is almost
> never a good idea IMO.
>
> Additionally, I'd argue that capturing is the common case, and that
> the argument should be used for *disabling* the capturing in the few
> cases that it might cause a problem, such as with the subprocess issue
> mentioned. (We should probably also look at trying to handle that
> issue generally, too, since you never really know beforehand if your
> output is going to go over that 64k limit.)
>
> In terms of getting capturing for local() working at all, have you
> looked at how we did it for run()/sudo()? That might give an idea as
> to how to both capture and print with local(). Or I might just take a
> crack at it myself today, if I can find the time.
>
> Best,
> Jeff
>