fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] workon


From: Jiri Barton
Subject: Re: [Fab-user] workon
Date: Mon, 14 Mar 2011 10:14:57 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15pre) Gecko/20110207 Shredder/3.1.9pre

Hi,

yes that line with "with" was a typo.

with prefix('workon mymy'):
    run('ls')

with --show=debug gives me

bash: workon: command not found

Which is sort of obvious :-) Next, I tried plain ssh mymachine.com
workon mymy I got the same error. Which means the problem does not have
anything to do with fabric.

The question is what is in your .bash* .* files that makes it work? I
don't know what to put where. Here's what I have at the end of my
.bashrc on the remote machine:

export WORKON_HOME=~/envs
. /usr/local/bin/virtualenvwrapper.sh

I tried to put those two lines to

.profile
.bash_profile
.bash_login
(.bashrc)

all to no avail. I was wondering, what did you do on the remote machine
in order for this 'workon something' to work?

Thanks
Jiri


P.S. I'm using a workaround now but it's very ugly:

    with prefix('export WORKON_HOME=~/envs'):
        with prefix('source /usr/local/bin/virtualenvwrapper.sh'):
            with prefix('workon uvar'):
                run('django-admin.py syncdb')






On 03/14/2011 04:45 AM, Jeff Forcier wrote:
> Hi Jiri,
> 
> Offhand I don't see anything obviously wrong, workon should work as
> long as it's being used as a prefix, and your use of virtualenvwrapper
> seems fine. See below for some ideas on figuring out what's up.
> 
>> with('workon mymy'):
>>    run('ls')
> 
> Did you mean "with prefix(..." instead of "with(..." ? I assume that
> was just a typo in your mail but wanted to double check.
> 
>> Of course, the commands work fine if I log in to the remote system manually
>> with ssh.
> 
> Try calling fab with "--show=debug" and note the commands Fabric
> prints out (e.g. [hostname] run: /bin/bash -l -c "workon mymy && ls").
> Then try copy/pasting them (starting with the /bin/bash!) into your
> real shell session on the server, and see if it still works, or if it
> breaks.
> 
> Chances are the "full" versions will break even on the real shell, and
> then you can try to figure out why (or show us what those commands are
> and maybe we can tell).
> 
> 
> Best,
> Jeff
> 



reply via email to

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