eval fzf --bash completion arguments result in "invalid option name"

JonathanDoughty commented 4 months ago

Checklist

[X] I have read through the manual page (man fzf)
[X] I have searched through the existing issues
[X] For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of `fzf --version`

0.49.0 (brew)

OS

[ ] Linux
[X] macOS
[ ] Windows
[ ] Etc.

Shell

[X] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce

with fzf --version: 0.49.0 (brew), and GNU bash, version 5.2.26(1)-release (aarch64-apple-darwin22.6.0) (also via HomeBrew) and eval "$(fzf --bash)" in .bashrc I get:

   bash: complete:  default -o bashdefault: invalid option name
   bash: complete:  bashdefault -o nospace -o dirnames: invalid option name
   bash: complete:  default -o bashdefault: invalid option name
   bash: complete:  default -o nospace -v: invalid option name
   bash: complete:  default -o nospace -v: invalid option name
   bash: complete:  default -o nospace -v: invalid option name
   bash: complete:  default -o bashdefault: invalid option name

on every bash shell startup in Terminal.

It appears this is related to the way arguments are passed to __fzf_defc in shell/completion.bash as quoted strings and then are not expanded as separate arguments as part of complete -F "$func" $opts "$cmd"

I've got a fix I can submit as a PR but since it looks like there has been recent activity in that file perhaps just pasting my patch here would be preferred?

junegunn commented 4 months ago

I can't reproduce the problem. Any idea why?

$ command -v bash
/opt/homebrew/bin/bash

$ /opt/homebrew/bin/bash --version
GNU bash, version 5.2.26(1)-release (aarch64-apple-darwin21.6.0)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ /opt/homebrew/bin/bash

$ eval "$(fzf --bash)"

$ echo $?
0

JonathanDoughty commented 4 months ago

This was caused by something earlier in my .bashrc sequence that had me mystified after I got the same result as you with a minimal .bashrc:

I had IFS=: in a PATH setting function defined/used earlier in that sequence that I had neglected to unset or restore to its original value on function exit. Worth insuring that fzf --bash has the necessary IFS? Only to preclude wastes of time like this. Apologies for the distraction.

junegunn commented 4 months ago

No problem, thanks for the clarification.

Worth insuring that fzf --bash has the necessary IFS?

I'm not sure. IFS=: will likely break other scripts as well, so preventing it here won't help that much and the user will figure it out anyway one way or the other. And from now on, anyone who runs into the same problem will find the answer here.

junegunn / fzf