Allow arbitrary shells #67

Closed
brejoc opened this Issue Jun 7, 2013 · 8 comments

Projects

None yet

4 participants

@brejoc
brejoc commented Jun 7, 2013

Make sure users can determine which local shell is used when executing commands.


Was: Only Bash as shell?

I've only had a quick peek at the code, but I think the bash shell is hardcoded in the runner. Would be nice to let the user define the the shell in tasks.py, since some shells don't share the same syntax.

@bitprophet
Member

That's totally on the roadmap, yea. I'll mutate this issue's title/desc to reflect that it's an intended line item, so to speak :) Thanks!

@bitprophet
Member

N.B. this is only hardcoded in one spot, invoke/runner.py; it shows up in our vendorized pexpect but all of those bash mentions are in docstrings, so not a problem.

@brejoc
brejoc commented Jun 17, 2013

Yes, that was the place I saw it. The best place to make this editable would be the tasks.py in my opinion. What do you think? Just like make does it:

SHELL := /bin/bash
@bitprophet
Member

I've been working up to actual config, my general idea is like so:

  • Bottom level is a run kwarg, like echo and friends, so it can be overridden per-execute in any use case.
  • Mid level is a Context object which acts as a config holder & allows one to pass configs around.
    • This is implemented, though the "edit it at the Python level" angle isn't beautiful - it's just dict attributes on Context objects, and I need to figure out how best to 'merge' CLI level settings (below) with in-task-module settings (what you want).
  • Top level is CLI options, i.e. inv --shell=/bin/zsh mytask. These require use of contextualized tasks to take effect - again see echo.

Adding a CLI flag is easy, just follow #32 / #27 re: --echo; having a useful task-module-level way of merging stuff might need more thinking.

@bitprophet bitprophet added the Feature label Aug 25, 2014
@bitprophet
Member

Ran into an internal need for this in #152 (see final comment), so, poking now.

The tl;dr of current state of this issue:

  • Configuration has been in for a long time now (this ticket is old) so not a problem
  • PTY-driven run sets its own shell, which is /bin/bash, so that's easily updated
  • non-PTY-driven run uses subprocess' own hardcoded default, /bin/sh, but that should be overrideable via the executable kwarg
@bitprophet bitprophet added a commit that referenced this issue Mar 20, 2016
@bitprophet bitprophet DDD, TDD re #67 0e5c8c3
@bitprophet bitprophet added a commit that referenced this issue Mar 20, 2016
@bitprophet bitprophet Implement #67 c82872d
@bitprophet
Member

All done. Simply configure run.shell via any config method, or say run('command', shell='/bin/fish') or whatnot at runtime.

@bitprophet bitprophet closed this Mar 20, 2016
@presidento
Contributor

Great, thank you @bitprophet!
(Didn't you want to add it to the 0.12.3 milestone?)

@frol
frol commented Apr 11, 2016

Just for your info, the implementation of this feature breaks Invoke on Windows: #345.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment