[Top][All Lists]

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

Re: [Fab-user] Virtualenv Use Case

From: Christian Vest Hansen
Subject: Re: [Fab-user] Virtualenv Use Case
Date: Sat, 2 May 2009 18:23:40 +0200

On Sat, May 2, 2009 at 5:27 PM, s s <address@hidden> wrote:
> On May 2, 2009, at 10:42 AM, Jeff Forcier wrote:
>> The result would then be something like::
>>   $ pre_command && workon foo && easy_install bar && easy_install biz
> Only thing with that is you lose the ability to grab error/status info from
> each command.
>> though I would have to think about whether ``&&`` or ``;`` makes more
>> sense for
>> joining 'lines'.
> I kind of like the idea of a "script runner agent" running the commands in
> sequence and keeping error status for us so we can collect error info from
> each command.

Just a bit of background on why lines are/would-be joined like that:

The SSH protocol is like a wrapper that delegates to some subsystem,
as per a clients request. The most known subsystems are probably
shell, sftp, scp and command. In this discussion the shell and command
subsystems are the most relevant. The shell subsystem opens a complete
login shell, like what happens when you "ssh this-host," and the
command subsystem just executes a single command and then closes the
connection - this is what run() and sudo() does today.

If you open a shell connection through SSH, then you won't be able to
read back the exit code of the commands executed through the shell,
directly through the SSH interface - the exit code returned would be
that of the shell itself. Indeed you won't even be able to accurately
tell when the commands finish running.

So the challenges of using a "real" shell are to know when the
commands terminate, what their exit code is and how to do this in a
way that works with all the shells that we can reasonably expect to
log into. One possibility is to append something like ``;echo "MAGIC
PATTERN $?"`` to all commands sent to the shell, and then look for
lines like that in the output produced. It seems to work in bash, ksh
and csh so it looks pretty compliant (I don't know if these shells are
suppose to implement or follow some defined standard). But, this
doesn't change that our implementation go from accurate and
deterministic handling of exit codes, to a less accurate and
probabilistic one.

On using && or ; for joining lines; I would go with && in the name of fail-fast.

Venlig hilsen / Kind regards,
Christian Vest Hansen.

reply via email to

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