fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] Re: How to handle remote shell prompt for input?


From: Jeff Forcier
Subject: Re: [Fab-user] Re: How to handle remote shell prompt for input?
Date: Tue, 15 Jun 2010 17:02:29 -0400

You can actually just call Fabric code directly instead of invoking it
with subprocess, just import your fabfile and start calling task
functions. Would probably have to tinker with some env vars like
env.hosts or env.host_string, and will need to disconnect the SSH
client objects in fabric.state.connections at the end so everything
cleans up nicely -- but it can be done.

(I still need to write a how-to document on this topic...)

Also, regarding the core need here, I am happy to announce that the
big push I've been making on the interactivity issue this week, has
paid off -- I've got it working! It's still experimental and I am
smoothing out the rough edges now, but it's definitely there and
should work in most cases.

So that's at least one enormous new feature that will be in 1.0 :)

-Jeff

On Tue, Jun 15, 2010 at 4:45 PM, Simon Smith <address@hidden> wrote:
> Ahh, sorry!  I forgot to mention that I'm using python to call fabric
> via a python function I created "run_fab_job", so that I can mix and
> match fabric and other python calls, I just found shell scripts to be
> too limiting.  This does mean that when I'm calling pexpect or
> something like that, I have to handle the SSH connection myself.
> Although it is annoying to have two sets of tools to operate on the
> host, sometimes it can't be avoided...
>
> I show how I call fabric from python below (apologies in advance if
> there is a much cleaner version of this somewhere in the
> examples/contrib or mailing list, I didn't dig very deep).
>
>  (NOTE: I tried to trim out a bunch of distracting stuff I do on the
> fly, so the resulting code may not actually work, but hopefully you
> get the idea).  I defined the run_fab_job at the top and give a sample
> call at the bottom (usually run_fab_job is defined in another file
> altogether and brought in via an import)
>
> #!/usr/bin/env python2.6
>
> def run_fab_job(fabjob, host=None, FAB="fab"):
>        import os, subprocess, sys, time
>
>        FABFILE = None
>        if "FABFILE" in os.environ:
>                FABFILE = os.environ["FABFILE"]
>
>        if FABFILE != None:
>                fabfile_opt = " -f %s " % FABFILE
>        else:
>                fabfile_opt = ""
>
>        if host == None:
>                fabcmd = "%s %s %s" % (FAB,fabfile_opt,fabjob)
>                firstparts = fabjob
>                desc = firstparts
>        else:
>                fabcmd = "%s %s %s:host=%s" % (FAB,fabfile_opt,fabjob,host)
>                desc = host
>
>        print("about to run %s" % fabcmd)
>
>        mydir = os.getcwd()
>
>        p_fab =
> subprocess.Popen(fabcmd,shell=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)
>        time.sleep(1.0)
>        (pout,perr) = p_fab.communicate()
>        return (p_fab.returncode,pout)
>
> # fabjob1 is in the fabfile.py
> (ret,out) = run_fab_job("fabjob1","192.169.3.4")
>
>
>
> On Tue, Jun 15, 2010 at 4:18 PM, Jeff Forcier <address@hidden> wrote:
>> Unfortunately, pexpect only operates on local commands that it
>> launches itself via subprocess, so it can't work with tools like
>> Fabric.
>>
>> There's an experimental "fdpexpect" that can operate on arbitrary file
>> descriptors that I may look into, but as-is the main pexpect module is
>> a no-go unless I've missed something about how it works.
>>
>> -Jeff
>>
>> On Tue, Jun 15, 2010 at 4:11 PM, Simon Smith <address@hidden> wrote:
>>> I've had some luck doing this type of thing with pyexpect - pretty
>>> powerful once you get the hang of it, although it takes some
>>> trial-and-error to get something programmed.
>>>
>



-- 
Jeff Forcier
Unix sysadmin; Python/Ruby developer
http://bitprophet.org



reply via email to

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