diff --git a/CHANGELOG b/CHANGELOG index 85ebf45f2a..cce447bd8e 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -5,6 +5,9 @@ git-annex (7.20181106) UNRELEASED; urgency=medium two different objects.) * Fixed some other potential hangs in the P2P protocol. * Fix build with persistent-sqlite older than 2.6.3. + * Fix bash completion of "git annex" to propertly handle files with + spaces and other problem characters. (Completion of "git-annex" + already did.) -- Joey Hess Tue, 06 Nov 2018 12:44:27 -0400 diff --git a/bash-completion.bash b/bash-completion.bash index f0c8818e1f..78aef02e1b 100644 --- a/bash-completion.bash +++ b/bash-completion.bash @@ -1,6 +1,6 @@ # Use git-annex's built-in bash completion -# This bash completion is generated by the option parser, so it covers all -# commands, all options, and will never go out of date! +# This is the same code output by git-annex --bash-completion-script git-annex +# This covers all commands, all options, and will never go out of date! _git-annex() { local CMDLINE @@ -17,8 +17,9 @@ _git-annex() complete -o bashdefault -o default -o filenames -F _git-annex git-annex # Called by git's bash completion script when completing "git annex" +# Translate to the "git-annex" completion above. _git_annex() { - local cmdline + local CMDLINE CMDLINE=(--bash-completion-index $(($COMP_CWORD - 1))) local seen_git @@ -34,5 +35,10 @@ _git_annex() { fi done + # This is the same as __gitcomp_file_direct in git-completion.bash; + local IFS=$'\n' COMPREPLY=( $(git-annex "${CMDLINE[@]}") ) + compopt -o filenames +o nospace || + compgen -f /non-existing-dir/ >/dev/null || + true } diff --git a/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn b/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn index 8b24e4c497..48e5f12b9b 100644 --- a/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn +++ b/doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn @@ -51,3 +51,4 @@ However, it doesn't correctly handle escape characters. Typically, a filename co Many times over! I use git-annex to manage my hundreds of pdfs, images, video files etc! It essentially enables *exactly* the work flow I like, since I live in the command line and appreciate fine-grained control over my tools. So, yes, thank you very much for this excellent too! +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment b/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment new file mode 100644 index 0000000000..7c2589d1c3 --- /dev/null +++ b/doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2018-11-12T16:13:26Z" + content=""" +I see this too. Note that it only affects tab +completing "git annex"; tab completing "git-annex" +works correctly for filenames with spaces and AFAICS +other problem characters. + +It used to be that git-annex's tab completion for "git annex" was only used +after the user tab completed "git-annex" which loaded the function. +That has changed; git now loads the git-annex completion. Which is good; +I asked the git devs a long time ago to add that. But the change means this +problem is more visible. I don't think the problem is new though. + +[[!commit 07c108e70e2df354d1478cbbec3630d2409d9d32]] +dealt with the same problem affecting "git-annex" tab completion. +The underlying problem is a bug in optparse-applicative, which +completes filenames without escaping them. +So that commit made the "git-annex" completion use "-o bashdefault -o default" +which bypasses the optparse-applicative completion for filenames and lets +bash handle them. It didn't seem to deal with "git annex" completion. + +I see that git uses `__gitcomp_file_direct` when using eg `git ls-files` +to list filenames. It seems that "compopt -o filenames" along with +IFS=newline fixes it. I'll put the same approach into the git-annex script. +"""]]