As it seems, JRuby 1.7 complains on stderr every time you invoke `system`:
warning: executable? does not in this environment and will return a dummy value
It doesn't seem to complain when backtics are used. It's safe to use
backticks here because `rbenv rehash` doesn't output anything on stdout,
and the exit status of the command is irrelevant.
This bakes in the functionality of rbenv-gem-rehash plugin.
The Rubygems hook is improved:
- It will not rehash for gems installed in locations that rbenv otherwise
doesn't search for binstubs; for instance in case of
`bundle --path vendor/bundle`.
- It rescues exceptions and makes them non-lethal by warning on stderr.
It doesn't need to be a bash array and we don't need a separate index of
shims registered. Simply keep everything in a space-separated string and
use that as an index as well.
This assumes that executable names *never* have spaces in them.
On my system that has 25 versions under rbenv, this speeds up rehash
almost 3-fold:
- before: 391 ms
- after: 134 ms
This is achieved by removing duplicate names of executables before
registering them as shims. Since most Rubies will share a lot of the
same executable names ("ruby", "rake", "bundle", ...), this is a
considerable reduction in number of shims registered.
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
