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".
Korn shell had two major versions: ’88 and ’93. Some systems have ksh
installed under the name `ksh93`. A few systems (maybe only Solaris
now) also have a `ksh88`. A few others use the `pdksh` (roughly ’88)
or `mksh` (roughly ’93) implementations, originated before ksh was
open source.
As far as the (very minor) use in rbenv is concerned, these are all
equivalent. This change accepts all of the above.
Tested with `ksh93`, `pdksh`, and `mksh`.
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.
Since fish 3.10 at least, the current way of loading rbenv in `fish` is misbehaving, at least in some environments:
```
source: Error encountered while sourcing file '/var/folders/pj/jn249gcn7ddfrjzj2_9mxjhw0000gp/T//.psub.f0iJSWRByB':
source: No such file or directory
```
This changes the initialization to the method recommended by a `fish` developer here: https://github.com/fish-shell/fish-shell/issues/6613#issuecomment-586679958
The setenv function in fish shell has changed dramatically in
75600b6b53
It now conforms to the csh version, which takes at most two arguments.
In this init script, the form
setenv PATH prepend_something $PATH
had been used, which had too many arguments.
Since setenv isn't a native command in fish, a suitable replacement is
to use the "set -gx" command, which can consume multiple arguments.
When invoked from a shell script, `$(rbenv init -)` did not get the
shell name correct.
It needs to look at the `args` value from `ps`.
Ref: https://github.com/yyuu/pyenv/issues/373
This is for Linux desktop platforms that have Terminal application
configured to start shells in interactive but not login mode. Creating a
`~/.bash_profile` would also cause `~/.profile` to not run, which might
be a problem on Ubuntu which ships with a default `~/.profile`.
In the event that `eval "$(rbenv init -)"` is called from a function named
rbenv (which I do to get rbenv to load lazily in my shell), evaluating the
phrase `rbenv rehash` will cause the outer function to run again (causing an
infinite loop).
This change makes it clear you want the command named rbenv and not a function
which may exist in the environment.
Too many of our users have a shell initialization set up that
inadvertently duplicates some or most of the entries in their PATH,
bringing the system paths again in front of rbenv's shims. If this was a
nested shell (a typical scenario when starting up tmux), `rbenv init`
would get eval'd again but this time, shims won't get added to the front
of the PATH and would only stay and the end of the path, effectively
rendering them useless.
I tried to argue that this is a user problem rather than rbenv's, but I
can't fix everybody shell init when they report bugs. Instead, let's
revert to simpler times in rbenv where we just roll along with the
duplication and don't ask any questions.
This reverts commit 03fa148e81.
Fixes#369
It's slow and not necessary since we expect `$0` to already be expanded.
In tests this change forces us to deal with some relative paths, but
it's not a big deal. The `rbenv init -` output in the most common case
will be the same as before:
source '/home/myuser/.rbenv/libexec/../completions/rbenv.bash'
It seems that "comm" header can't be relied on cross-platform, but that
"ucomm" is more portable. I have no idea whether it's the right value to
use here, but it seems to be doing the job.
Also strip trailing whitespace because OpenBSD 5.4 `ps` output is padded
with spaces for some reason.
Fixes#489
Fish user config file `~/.config/fish/config.fish` loads for every
instance of fish shell, not just interactive ones. Since it's
unnecessary and dangerous to eval `rbenv init -` output in
non-interactive shells, wrap the invocation in a conditional that checks
if the current shell is interactive.
Fixes#501
`$SHELL` variable is a terrible way of detecting the current shell
because it's not even supposed to reflect the current shell; it's meant
for keeping the value of the default shell for programs to start.
If an explicit `<shell>` argument wasn't passed to `rbenv init`, it
tries to detect the shell by getting the name of its parent process. If
this fails, it falls back on the value of `$SHELL` as before.
Furthermore, `rbenv init` will set the RBENV_SHELL variable in the
current shell to the value of the detected shell so that `sh-shell` and
`sh-rehash` commands don't have to repeat the detection.
If `rbenv init -` outputs `.` in place of `source` and that gets eval'd
by the desktop manager via `~/.profile`, it chokes and prevents the user
from logging in.
Fixes#457
ksh syntax becomes:
function rbenv {
typeset command
`typeset` only declares a local variable if there's an explicit
`function` declaration; otherwise the variable leaks.
Other shells use this syntax:
rbenv() {
local command
This is for dash compatibility, which supports neither `function` nor
`typeset`.
references #205, fixes#408
readlink comes from GNU coreutils. On systems without it, rbenv used to
spin out of control when it didn't have readlink or greadlink available
because it would re-exec the frontend script over and over instead of the
worker script in libexec.
Fixes#389
