The directory /usr/etc is an optional directory and used by
Fedora, RHEL 9, and openSUSE. The purpose of /usr/etc is to store
distribution-provided configuration files that can be overridden
by user-modified files in /etc.
Also used in the sister project pyenv/pyenv#3039
Co-authored-by: Mislav Marohnić <git@mislav.net>
When `rbenv init` is invoked to automatically edit shell startup files,
the generated lines will be invoking `rbenv init - --no-rehash` by default
to help speed up shell startup. Auto-rehashing on every shell startup can
be slow for some users but is not crucial to rbenv operation. Lets assume
that rbenv shims are already healthy and that they will be regenerated as
needed after installing new ruby versions and gems.
When running `rbenv init`, typically during rbenv setup, users expected
their shell environment to be modified permanently. Instead, what the
command would do is print the instructions to the user and expect them
to edit their shell initialization files accordingly. This proved to
be unintuitive.
Now, running `rbenv init <shells>...` will modify the shell initialization
files of the following shells:
- bash: `~/.bash_profile` or `~/.bashrc` if the latter exists but the former does not
- zsh: `~/.zprofile` or `~/.zshrc` if the latter exists and mentions "rbenv"
- fish: `~/.config/fish/config.fish`
If no shells were specified on the command line, rbenv will try to detect
the current shell.
It should be safe to run `rbenv init` multiple times, as the command will
avoid modifying any shell startup file that already mentions "rbenv init".
With zsh `setopt warn_create_global` the "shell" command used to cause
a warning message:
scalar parameter RBENV_VERSION_OLD created globally in function rbenv.
By using `typeset -g` specifically for zsh, this warning goes away.
1. On systems with `readlink -f`, use that to canonicalize the path to libexec directory;
2. Otherwise, resolve symlinks recursively rather than just once.
Considerations:
- `./libexec/rbenv` executable is the entrypoint to the program;
- BASH_SOURCE might be the path to a symlink that has activated `./libexec/rbenv`;
- We must resolve the symlink to learn where rbenv's libexec directory is;
- It's not guaranteed that rbenv commands will always remain directly under their own "libexec" directory, since a package maintainer can change that, e.g. rbenv commands are sometimes placed into `/usr/libexec/rbenv/*`;
- Resolving symlinks might fail and in that case we just assume rbenv project layout.
The rehash process will now discover executables in additional locations:
- `~/.gem/ruby/<version>/bin/*`
- `$GEM_HOME/bin`
The `rbenv which` (and thus `rbenv exec`) command will also search these locations when looking up a command. This enables shims to dispatch calls to executables added by `gem install --user-install`.
Note that this support is limited:
- It will only work with C Ruby, as it's difficult to guess the `~/.gem/<engine>/<version>` directory for other Rubies without actually loading Ruby;
- It will only work for RBENV_VERSION values in the format `X.Y.Z` and not "system".
This speeds up subsequent `rbenv init -` executions for the user who
followed these instructions because the shell will no longer have to be
detected each time.
A malicious `.ruby-version` file in the current directory could inject
`../../../` into the version string and trigger execution of binaries
outside of `RBENV_ROOT/versions/`.
Fixes#977 OVE-20170303-0004
This suppressed any output when using RBENV_DEBUG=1 and does not really
hurt to have in the unlikely case that it should fail; you would get
two error messages now:
rbenv: ruby: command not found
rbenv: system version not found in PATH
Command `rbenv version-name > .ruby-version` will create an empty `.ruby-version` file
before running `rbenv-version-file`. This causes `rbenv-version-file` to return empty
string which in turn causes `rbenv-version-name` to return `system`.
Ensure size of `.ruby-version` is non-zero as a workaround.
Keeping rbenv-controlled variables to RBENV_* "namespace" helps with
discoverability (and tools like rbenv-env) but also consistency and a
very minor degree of safety/isolation from env impact.
This ensures that OLD_RBENV_VERSION is never exported. This makes the
implementation a little bit more complex, since more logic needs to be
pushed down into eval'd code.
`rbenv shell -` allows you to switch to the previously activated ruby
version. Similar to `cd -` or `git checkout -`.
This tries to implement `rbenv shell -` as proposed in #854. However,
adding support seemed to break the "shell change version" test. I'm not
very good at Bash programming, can someone tell me what is wrong with
what I'm doing? I'd like to add a bit more functionality to this, but
I'm really just cargo cult programming Bash.
Thank you!
fix tests
