-
-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix chruby-exec sourcing chruby.sh #250
Conversation
chruby-exec works as follows: 1. source chruby.sh 2. check arguments 3. execute 'chruby {target_ruby} && $command' in a subshell The problem is that sourced functions unlike environmental variables are not 'inherited' by subshells. (It is true at least in Ubuntu 12.04 LTS, where I tested this) With "basic setup" you copy chruby.sh to /etc/profile.d, and this chruby.sh sources /usr/share/local/chruby/chruby.sh Then, when you invoke chruby_exec it works just fine, because /usr/share/local/chruby/chruby.sh is sourced automaticaly by bash through /etc/profile initialization script (which sources /etc/profile.d/chruby.sh) It would be great if you consider moving the process of sourcing /usr/share/local/chruby/chruby.sh from the top of `chruby_exec` to a command executed by a subshell. It would allow to use `chruby_exec` without needing to source /usr/local/chruby/chruby.sh with shell init scripts (/etc/profile.d/chruby.sh) About function inheritance in a subshells You could check it with the following setup: - file set_func.sh: ==================== function test_func() { 0 } ==================== - file get_func.sh: =================== source ./set_func.sh type test_func | head -1 exec "$SHELL" -i -l -c "type test_func | head -1" ================== and then: $ ./get_func.sh test_func is a function bash: type: test_func: not found
There is one problem here. What if the user has custom configuration for |
Oh, I see. Then, the original What would you say, if I add a check before sourcing chruby.sh? I could check if |
We don't want to mess with user custom chruby config, so we'll source chruby.sh only if it wasn't sourced before.
@postmodern could you, please, provide some feedback on the proposed solution? |
👍 I have been seeing the same issue if |
👍 If you don't have @postmodern can you take another look at this? |
@mxhold that makes sense for non-login non-interactive shells. @artempyanykh update the command to use |
@postmodern OK, I'll do it. |
Conflicts: bin/chruby-exec
I updated the PR. Is it OK? |
I manually rebased and then squashed ( |
On commit
If I got it right,
chruby-exec
works as follows:chruby.sh
chruby {target_ruby} && $command
in a subshellThe problem is that sourced functions unlike environmental variables
are not 'inherited' by subshells.
(It is true at least in Ubuntu 12.04 LTS, where I tested this)
With "basic setup" you create
/etc/profile.d/chruby.sh
which sources/usr/share/local/chruby/chruby.sh
Then, when you invoke
chruby_exec
it works just fine, because/usr/share/local/chruby/chruby.sh
is sourced automaticaly by bashthrough /etc/profile initialization script.
It would be great if you consider moving the process of sourcing
/usr/share/local/chruby/chruby.sh
from the top ofchruby_exec
to acommand executed by a subshell. It would allow to use
chruby_exec
without needing to source
/usr/local/chruby/chruby.sh
with shell initscripts (
/etc/profile.d/chruby.sh
)About sourced functions in subshells
You could check it with the following setup:
set_func.sh:
get_func.sh:
and then: