Allow shell selection in local()

[bitprophet]

Description

According to the Popen docs (see 1st para after 2nd note block) one can force subprocess to use a specific shell instead of the system default (which may vary) by use of the executable kwarg.

First, verify that this is true and works on various platforms.

Then add an analogue to env.shell (probably env.lshell to mirror lcd, or env.local_shell to be nicer looking) allowing optional override of that behavior.

Finally, maybe update local to force use of bash by default so it's in line with the remote calls. Yes, this will cause it to blow up on bashless systems, but users already encounter this on bashless target systems, and it would avoid issues (such as on Ubuntu) where folks' user account login shells are bash but subprocess is still using a limited shell like sh (when /bin/sh is not a symlink to /bin/bash).

However, that would technically be a backwards incompatible change, so it comes down to whether we consider people relying on local using sh to be making use of a bug or not.

Would be ideal if we could detect what shell subprocess wants to use and only change this setting if we detect the e.g. Ubuntu setup. OTOH this feels kind of gross and prone to error.

---

Originally submitted by Jeff Forcier (bitprophet) on 2010-06-14 at 11:28am EDT

Attachments

• local_shell_selection.diff

[bitprophet]

Vaughn Draughon (vfd) posted:

---

Here's a patch for this, works for me, at least it doesn't seem to break anything :)

Have a look and see how it strikes you... thoughts on other improvements, pitfalls, etc?

Implementing "smart" shell selection is not included here, just manual shell selection via the environment vars:

env.local_shell
env.local_login_shell

Where the local_shell is the actual name/path of the shell like "/bin/bash" and local_login_shell is a simple boolean True/False flag to determine whether or not to run a login shell with -l (aka whether or not to source e.g. the .bashrc or .profile or whatever)

---

on 2011-03-14 at 10:04pm EDT

[poswald]

The big reason this is a problem for us is that it breaks with virtualenv. Virtualenv doesn't set environment variables in non-bash shells. There is a patch to fix that but it looks like it is stalled.

[bittner]

@poswald I don't understand "this is a problem for us is that it breaks with virtualenv".
The problem we're currently facing is that local() calls /bin/sh when our fabric script is executed in a Vagrant-powered setup call on a Debian/Ubuntu VM. (This is in perfect accordance with the Python docs that state "On Unix with shell=True, the shell defaults to /bin/sh.", by the way.)
And the best of all, our call failing is: local("mkproject --help"), a virtualenvrapper command (*). Forcing local() to use /bin/bash as proposed above would be the solution.
I suggest to re-open this issue and apply the patch, or be inspired from it for a very similar enhancement.

(*) BTW, a side-effect of using prefix("/bin/bash ~/.bashrc") instead of prefix(". ~/.bashrc") as a pre-block instruction.

[ppawlak]

+1 on fixing this issue. I am on Ubuntu (with /bin/sh pointing to dash) and using virtualenv with fabric doesn't work.
Does anyone have a workaround ?

[bitprophet]

2.0 now has a shell option in all command-running functions/methods