Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

chruby-exec: bash: no job control in this shell #119

Closed
allanwind opened this Issue Mar 12, 2013 · 12 comments

Comments

Projects
None yet
4 participants

I am trying to run a script via at or crontab and receive the following:

bash: no job control in this shell
stty: standard input: Inappropriate ioctl for device

Here is how to reproduce it:

echo -e "#!/usr/bin/env ruby\nputs RUBY_VERSION" > version
chmod 755 version
./version
1.8.7

echo chruby-exec 1.9.3-p194 -- ./version | at now
(emailed to you)
bash: no job control in this shell
stty: standard input: Inappropriate ioctl for device
1.9.3

@postmodern postmodern added a commit that referenced this issue Mar 13, 2013

@postmodern postmodern Execute chruby-exec under the current shell and load chruby.sh. #119
* This is to avoid running a sub-shell in interactive mode,
  as chruby-exec might be running via cron/at.
3ce9801
Owner

postmodern commented Mar 13, 2013

I changed chruby-exec to run under the current shell and re-load chruby.sh. The no job control in this shell error was probably coming from the last line, where we run $SHELL in interactive mode. Try testing against master and see if the error goes away?

With dash (posix shell) I am now getting a syntax error:

/home/allan/bin/chruby-exec: 15: [[: not found
/home/allan/bin/chruby-exec: 17: Syntax error: "(" unexpected

and if I add #!/usr/bin/env bash back to support the bash syntax it fails with:

/home/allan/bin/chruby-exec: line 34: chruby: command not found

In other words, chruby.sh, has not been run in the current shell.

Owner

postmodern commented Mar 13, 2013

Darn, dash strikes again. Ubuntu/Debian use dash for their system shell, while users use bash. Due to the fact that dash lacks most of the common features, chruby does not support dash. Previously we'd invoke $SHELL in interactive/login mode so chruby would be loaded.

@postmodern postmodern added a commit that referenced this issue Mar 13, 2013

@postmodern postmodern Revert "Execute chruby-exec under the current shell and load chruby.sh.
#119"

This reverts commit 3ce9801.

* We must run chruby-exec under bash, otherwise we risk running under
  dash.
b7154d1

This issue can be fixed by simply not running the shell as an interactive shell (by removing the -i option). I bumped into the same issue and I fixed it for now by copying chruby-exec to ruby-exec and removing the -i option.

Owner

postmodern commented May 5, 2013

I thinking of rewriting chruby-exec as a function, to explicitly force users to run it in their choice of shell.

The problem with rewriting it as a function is that it becomes impossible to use it outside of a user's shell. This in turn means that for example when using a supervisor (these usually require full paths to commands) you have to do something like start program = /usr/bin/bash -l -c "chruby-exec 1.9.3 -- your-command-here". The downside of this approach is that it leads to two login shells being started instead of just one.

darrell commented Aug 16, 2013

I don't understand why chruby-exec is trying to call bash with the '-i' option anyway.

Bash is usually smart enough to figure out if it is/needs to be interactive, and I can't see any scenario under which it's necessary here, unless I'm missing something non-obvious.

Owner

postmodern commented Aug 16, 2013

I believe -i was added to force the sub-shell to load as much of the configuration as possible. Since it's causing problems in non-interactive environments, I think we can remove it and instruct user's to place their chruby configuration where it will be loaded for non-interactive login shells.

Owner

postmodern commented Aug 16, 2013

Note that without the -i, ~/.zshrc will not be loaded unless it is sourced by ~/.zprofile.

Owner

postmodern commented Aug 16, 2013

Removing the -i breaks the zsh chruby-exec tests, since ~/.zprofile does not load ~/.zshrc by default. As a work around, I used [[ -t 0 ]] to determine if we can spawn an interactive shell.

darrell commented Aug 19, 2013

The canonical way to test if you are in an interactive shell or not is to test whether $PS1 is set.

if [[ -z $PS1 ]]; then....

http://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html

Owner

postmodern commented Aug 19, 2013

Actually, checking PS1 will give you false positives. PS1 is always blank once inside of shell scripts or run running under $SHELL -c '...'. The two other canonical ways are [[ "$-" == *i* ]] and [[ -t 0 ]].

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