Skip to content
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

rbenv-exec only allows executables found by rbenv-which #865

Open
jasonkarns opened this issue Feb 2, 2016 · 4 comments · May be fixed by #1082, #1110 or #1446
Open

rbenv-exec only allows executables found by rbenv-which #865

jasonkarns opened this issue Feb 2, 2016 · 4 comments · May be fixed by #1082, #1110 or #1446
Labels

Comments

@jasonkarns
Copy link
Member

I don't think this is really a bug but more of a feature request. Presently, rbenv exec doesn't do what is advertised on the cover. Per the help:

Runs an executable by first preparing PATH so that the selected Ruby
version's `bin' directory is at the front.

For example, if the currently selected Ruby version is 1.9.3-p327:
  rbenv exec bundle install

is equivalent to:
  PATH="$RBENV_ROOT/versions/1.9.3-p327/bin:$PATH" bundle install

To me, this means that rbenv exec foo should be the same as PATH="$RBENV_ROOT/versions/1.9.3-p327/bin:$PATH" foo. But instead, rbenv-exec checks rbenv-which first. So if the provided command doesn't exist under the currently selected ruby, then we get an error rather than simply invoking the command.

I'm not sure if this behavior belongs in rbenv-exec (though that's my inclination). But it should be possible to simply execute a command while letting rbenv set up the correct PATH for me first.

@mislav
Copy link
Member

mislav commented Feb 3, 2016

rbenv-exec was solely designed for powering the shims mechanism, and for that purpose it makes sense to focus only on executables that are in ruby bin directory. However I see your point re: manual usage. Maybe rbenv-exec should have 2 operation modes?

@jasonkarns
Copy link
Member Author

I just ran into this issue again. the rbenv-env plugin is intended to print out useful env vars relevant to rbenv (that is, env vars such as GEM*, RUBY*, RAILS*, RBENV_*, etc). However, in order to print the PATH as it exists in the context of rbenv; it has to manually do all of the PATH setup that rbenv-exec does. It essentially re-implements rbenv-exec, including running any exec hooks such that any environment variable modifications done by exec hooks are respected. (In addition to manually modifying PATH such that PATH is printed as it would exist under rbenv.)

This is clearly suboptimal. In reality, the ideal implementation of rbenv-env would simply be rbenv exec env (Run env in the context of rbenv) but of course that fails because env is not a ruby command.

Do you have any thoughts on how this should operate?

jasonkarns added a commit to jasonkarns/rbenv-env that referenced this issue Aug 31, 2016
When testing the nodenv-env fork of this, I discovered that the rbenv-which command fails when a ruby version isn't set. Since the result of that command is only used when a ruby version is explicitly set, it doesn't make sense to attempt the command in all cases (especially when it fails in the negative case).

Related to rbenv/rbenv#865
@jasonkarns
Copy link
Member Author

Related: #187

@hurricup
Copy link

hurricup commented May 25, 2018

Any updates on this? Would be really nice to attempt to execute as is if no shim exists.
Or, even make some thing like rbenv 2.5.1 run arbitrary_command. This expected to work as rbenv shell 2.5.1 && rbenv exec arbitrary_command

hurricup added a commit to hurricup/rbenv that referenced this issue May 26, 2018
Allows to execute arbitrary command in the context of selected ruby.
rbenv#865
@hurricup hurricup linked a pull request May 26, 2018 that will close this issue
@mislav mislav added the feature label Jun 4, 2018
marcthe12 pushed a commit to marcthe12/rbenv that referenced this issue Aug 9, 2018
@marcthe12 marcthe12 linked a pull request Aug 9, 2018 that will close this issue
@mislav mislav linked a pull request Oct 7, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants