GitHub's expected filename is CODE_OF_CONDUCT.md. Whether that is the best name or even the current de facto standard is to be debated. But moving forward, this is likely the filename that will become the most common within the community, as that is the name GitHub expects and suggests.
This simply renames the existing code of conduct file from CONDUCT.md to CODE_OF_CONDUCT.md to conform to GitHub's preference.
Silver Searcher respects .gitignore, so having an .agignore file is
redundant. (Both patterns present in .agignore are already present in
.gitignore.)
It's also worth noting that silver searcher uses .agignore _in addition
to_ .gitignore, so removing this file will not cause ag to start
ignoring _additional_ patterns from .gitignore (it's already respecting
those patterns).
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
Sometimes the command fails with a 'type: write error: Broken pipe'.
This is because 'head -1' only reads the first line, then exits.
If 'type' writes the second line after 'head -1' has already exited,
then the aforementioned error is triggered.
We fix this by buffering the entire output of 'type' before
invoking 'head -1'.
It wasn't clear how to update the list of installable Ruby versions after installing rbenv from Git. This is a bit confusing for people who use rbenv to run third party Ruby apps rather than write their own and are less likely to know/care about the distinction between `rbenv` and `ruby-build`. I hadn't touched it for about 2 years and totally forgot that I'd need to manually update ruby-build.
Alternatively, it might be better to make ruby-build a git submodule.
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