For just a handful of people, rbenv init would hang indefinitely. Turning on
debugging output suggested that the `read` expression to split PATH into a bash
array was hanging, but I could never reproduce this myself. Instead, this uses
bash v4+ `readarray` if it's available, or falls back to bash v3 `read` with the
default DELIM being a newline character. This will cause a regression if any PATH
entries contain a literal newline character, but hopefully people are not relying
on such paths.
The new `_rbenv` script will be autoloaded by zsh as long as it's found in $FPATH.
It should be the package manager's responsibility to symlink or move this file
into an appropriate location.
Co-authored-by: Mislav Marohnić <git@mislav.net>
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'.
In systems that use the MAWK interpreter (the default AWK installed with
Ubuntu), the output of `rbenv help <command>` would have no line breaks.
The issue is fixed by changing `gsub` to `sub` in the snippet of awk
commands that are used to extract documentation comments.
I suspect the bug is something to do with the way the '^' and '$'
characters are interpreted by different AWK interpreters (per-line vs
per-string anchors).
If I understand correctly, the purpose of trim() is to remove all line
breaks from the start and end of each sections of a command's
documentation, in which case `sub` should serve the same purpose.
A command doesn't have to specify Usage docs if it doesn't accept any
arguments. The default usage for a command will be printed as:
Usage: rbenv ${command}
Docs are comprised from "Usage", "Summary" and "Help" sections, where
"Help" can span multiple commented lines. If it is missing, "Summary" is
shown in its place.
References #204, references #206
