# [PATCH] contrib/completion: escape the forward slash in __git_match_ctag

2 messages from 2015-03-14 to 2015-03-15. Participants: John Szakmeister, Junio C Hamano.
Thread: https://gitlist.dev/t/38802

## John Szakmeister, 2015-03-14 13:40

Subject: [PATCH] contrib/completion: escape the forward slash in __git_match_ctag
Message-ID: <1426340439-7171-1-git-send-email-john@szakmeister.net>
URL: https://gitlist.dev/e/1426340439-7171-1-git-send-email-john%40szakmeister.net

```
The current definition results in an incorrect expansion of the term under zsh.
For instance "/^${1////\\/}/" under zsh with the argument "hi" results in:
    /^/\/h/\/i/

This results in an output similar to this when trying to complete `git grep
chartab` under zsh:

    :: git grep chartabawk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
    awk: cmd. line:1:    ^ backslash not last character on line
    awk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
    awk: cmd. line:1:    ^ syntax error

Leaving the prompt in a goofy state until the user hits a key.

Escaping the literal / in the parameter expansion (using "/^${1//\//\\/}/")
results in:
    /^chartab/

allowing the completion to work correctly.

This formulation also works under bash.

Signed-off-by: John Szakmeister <john@szakmeister.net>
---

I've been bit by this bug quite a bit, but didn't have time to track it down
until today.  I hope the proposed solution is acceptable.

-John

 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c21190d..a899234 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1305,7 +1305,7 @@ _git_gitk ()
 }
 
 __git_match_ctag() {
-	awk "/^${1////\\/}/ { print \$1 }" "$2"
+	awk "/^${1//\//\\/}/ { print \$1 }" "$2"
 }
 
 _git_grep ()
-- 
2.3.1

```

## Junio C Hamano, 2015-03-15 01:58

Subject: Re: [PATCH] contrib/completion: escape the forward slash in __git_match_ctag
Message-ID: <xmqq7fujvx6l.fsf@gitster.dls.corp.google.com>
URL: https://gitlist.dev/e/xmqq7fujvx6l.fsf%40gitster.dls.corp.google.com
In-Reply-To: <1426340439-7171-1-git-send-email-john@szakmeister.net>

```
John Szakmeister <john@szakmeister.net> writes:

> The current definition results in an incorrect expansion of the term under zsh.
> For instance "/^${1////\\/}/" under zsh with the argument "hi" results in:
>     /^/\/h/\/i/
>
> This results in an output similar to this when trying to complete `git grep
> chartab` under zsh:
>
>     :: git grep chartabawk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
>     awk: cmd. line:1:    ^ backslash not last character on line
>     awk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
>     awk: cmd. line:1:    ^ syntax error
>
> Leaving the prompt in a goofy state until the user hits a key.
>
> Escaping the literal / in the parameter expansion (using "/^${1//\//\\/}/")
> results in:
>     /^chartab/
>
> allowing the completion to work correctly.
>
> This formulation also works under bash.
>
> Signed-off-by: John Szakmeister <john@szakmeister.net>
> ---
>
> I've been bit by this bug quite a bit, but didn't have time to track it down
> until today.  I hope the proposed solution is acceptable.
>
>  contrib/completion/git-completion.bash | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index c21190d..a899234 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1305,7 +1305,7 @@ _git_gitk ()
>  }
>  
>  __git_match_ctag() {
> -	awk "/^${1////\\/}/ { print \$1 }" "$2"
> +	awk "/^${1//\//\\/}/ { print \$1 }" "$2"

The updated pattern look sensible to me. / to start the pattern
part, extra / to say "repeatedly replace all", \/ to say "a single
slash is what is to be replaced, / to say "here is where the pattern
ends", and then \\/ to say "replace with backslash-slash".

In fact, I have to suspect that the original working by pure
accident or a bug.

Thanks.

>  }
>  
>  _git_grep ()

```