[Top][All Lists]

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

Re: [Fab-user] Shell Command?

From: Christian Vest Hansen
Subject: Re: [Fab-user] Shell Command?
Date: Tue, 26 May 2009 13:41:26 +0200

On Tue, May 26, 2009 at 1:16 PM, Jeff Forcier <address@hidden> wrote:
> On Mon, May 25, 2009 at 9:53 PM, Jorge Vargas <address@hidden> wrote:
>> errr I was actually thinking of something along the lines of
>> <snip>
>> that is run the interperter or shell on the Target machine rather than
>> local. And it will somehow give you back the input/output buffers.
> Ah, well that's not what the old shell used to do, and I don't know
> for sure but I don't think Cap's shell does this either. You can see
> the old 'fab shell' command here:
> http://github.com/bitprophet/fabric/blob/a1ef88bfc80f5cd9b7a225a2c07a11da2d47ff60/fabric.py#L887
> So in other words, all it was was an interactive way to call Fabric
> operations, not a way to get interactivity with the remote commands,
> which is what you seem to be asking for. I do want to get better
> interactivity at some point (largely through improved prompt
> detection) but I believe that's a more ambitious goal involving more
> work.
> Also not convinced that it would be truly *worth* the work given that
> I imagine it to be a bit of an edge case -- in just how many scenarios
> is it *really* necessary to have that feature in order to avoid simply
> making a new terminal window/tab and manually ssh-ing to the system in
> question? Some, of course, but I'm not sure if it's enough to justify
> what could be quite the chore and a rather blatant reinvention of the
> wheel :)

I have on multiple occasions pointed to the difficulties involved in
correctly implementing fully-fledged shell multiplexing. In fact, I
have yet to see the program that actually does this correctly, and
prior to starting Fabric, I really did go looking, and I'd still like
to know about it if a program really has gotten this right.

Jeff may be seeing this differently, but my intent with Fabric was
remote *automation* and having a multiplexing shell, while nice and
convenient, is not about automation. That is my strictly speaking.

So, in brief: I agree with Jeff here.

> (And note that I mean that literally: I'm "not sure". I'd love to have
> a Fabric where you *do* get a nice interactive shell when things go
> wrong, and are still able to interface with the environment set up by
> your Fab tasks; but if it turned out to be a lot of work, I am not
> sure it would be worth it.)
>> this is also nice. but not as good as you will have to do run() around
>> each command.
> I disagree here: the point of having the full Python shell and "having
> to" call run() or whatnot, is that inevitably with a shell that
> translates to "everything gets sent to a run() call", you will want to
> start changing options temporarily, or use sudo() instead of run(), or
> etc. At which point just using iPython or a derivative makes much more
> sense (especially since tab-completion means typing out "run" isn't
> even fully necessary).
> -Jeff
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user

Venlig hilsen / Kind regards,
Christian Vest Hansen.

reply via email to

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