On Tue, May 26, 2009 at 1:16 PM, Jeff Forcier <[email protected]> wrote: > On Mon, May 25, 2009 at 9:53 PM, Jorge Vargas <[email protected]> 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/fab-user > -- Venlig hilsen / Kind regards, Christian Vest Hansen. _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
