Allow shell selection in local()

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]

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

[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 ?