On Tue, Feb 10, 2009 at 4:17 PM, Jeff Forcier <[email protected]> wrote: > 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
Excellent :) > > -Jeff > > On Tue, Feb 10, 2009 at 7:57 AM, Jeff Forcier <[email protected]> wrote: >> On Tue, Feb 10, 2009 at 3:08 AM, Sverre Johansen >> <[email protected]> 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, Yeah. As long as the stdout output keeps working :D (I actually don't really use capturing) >> 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 >> > -- Venlig hilsen / Kind regards, Christian Vest Hansen. _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
