Skip to content

Patch/fzf detection #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 3, 2018
Merged

Patch/fzf detection #3

merged 2 commits into from
Oct 3, 2018

Conversation

SidOfc
Copy link
Owner

@SidOfc SidOfc commented Oct 3, 2018

Based on the changes made in #1.

The system command returns nil when execution fails. Since there is no One True Way(tm) for this I think running system is the safest way and best of all, it abstracts away the exit-code checking in the process.

Damien Robert and others added 2 commits October 3, 2018 10:18
Usually, since 'command' is a builtin, `command -v fzf` will give a
Errno::ENOENT: No such file or directory - command

Add a ';' to force `...` to launch the shell, where 'command' will be a
builtin.

And add a 'chomp' to remove the extra new line.
@SidOfc SidOfc merged commit 1613e20 into master Oct 3, 2018
@SidOfc SidOfc deleted the patch/fzf-detection branch October 3, 2018 18:56
@SidOfc SidOfc self-assigned this Oct 3, 2018
@SidOfc SidOfc added the enhancement New feature or request label Oct 3, 2018
@DamienRobert
Copy link

Yes indeed, since you only want to know if fzf is available and you don't need the full path to the binary, this is more robust since it won't depend on the command builtin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants