When created on Windows, .rbenv-version or .ruby-version files may have CR characters that will prevent rbenv from correctly parsing the Ruby version. Discard those characters when reading the file.
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
On other systems, we expected to find system Ruby in `/usr/bin`, but in
OpenBSD 5.4 it will be found in `/usr/local/bin`.
This replaces the limited USRBIN_ALT hack with a more generic
`path_without` function that will ensure that the given executable is
not present in the resulting PATH even if it's found in multiple
system paths.
The error was "bash: no such file or directory" and it was due to bash
being located in `/usr/local/bin` on OpenBSD 5.4 instead of `/bin` like
on other systems.
Fixed by keeping `/usr/local/bin` in PATH during the test run.
In Travis CI environment, Bats thinks it's outputting to an interactive
terminal, so it switches to "pretty" format and ANSI escape codes which
don't look well in the final output.
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
It was supposed to fix shelling out to Ruby but it in fact broke another
kind of shelling out to Ruby: invoking the `ruby` binary directly with
the `-S` flag.
Fixes#480
This reverts commit db143bb654.
It doesn't exist as a builtin, and it doesn't seem there is a way to
detect support for a shell builtin that is portable. So, just detect
fish and don't the rehash command at all.
Fixes#478
`$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.
Provide an `rbenv install` example and explanation lower down, so that
both folk that are following git install and Homebrew install will
finish at the same section and learn how to use ruby-build.
Also remove step 6 of manual install process: `rbenv rehash`. It's
unnecessary at that point, even if they already did `rbenv install`
(which rehashes automatically).
Fixes#455, closes#456
Don't suggest that they add to their `.profile` anymore because:
1. They would have to restart the desktop session for their change to be
reflected, or source the file manually;
2. An error in `.profile` may prevent logging in;
3. The `rbenv()` shell function and shell completions won't be available
in Terminal since it doesn't start bash in login mode by default.
Therefore, suggest that they use `.bashrc` instead. This will be
immediately reflected in a new Terminal tab. If bash is started in login
mode somehow, the default `.profile` is set up to source `.bashrc` anyway.
Also, don't suggest restarting the shell environment with
`exec $SHELL -l`, since we don't know what was the original mode that
their shell was started in. (OS X Terminal.app will be login mode,
Ubuntu Terminal has non-login mode by default.) Mode can be checked with:
* bash: `shopt -q login_shell`
* zsh: `[[ $options[login] = "on" ]]`
But since this is gnarly, let's just avoid it altogether and go the
easy route.
Closes#305, fixes#373, reverts #286
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
Enables shelling out from a ruby process started with rbenv to a ruby
process with a different RBENV_VERSION. Fixes#121
This removes the workaround created for #15 and solves `ruby -S` support
by setting RUBYPATH. PATH is never changed.
To illustrate how RUBYPATH changes in various configurations:
PATH=~/bin:~/.rbenv/shims:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
RBENV_VERSION=2.0 ruby -S rake
#=> executes ~/.rbenv/versions/2.0/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/2.0/bin:/usr/bin:/bin
RBENV_VERSION=system ruby -S rake
#=> executes /usr/bin/rake
#=> RUBYPATH=~/bin:/rbenv_shims_were_here:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
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
