git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: douglas.fuller@gmail.com
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH] doc: fix quoting bug in credential cache example
Date: Thu, 30 Apr 2020 11:09:02 -0700	[thread overview]
Message-ID: <xmqqr1w4sv5t.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <63f35287c9ced4d674f938bedd439aefa6c46f41.camel@gmail.com> (douglas fuller's message of "Thu, 30 Apr 2020 10:36:47 -0400")

douglas.fuller@gmail.com writes:

> Unquoted semicolons are considered shell argument separators, quote
> them so the example works correctly.

I think what you wanted to do might make sense, but the above
justification is totally incorrect.

>  # or you can specify your own shell snippet
> -!f() { echo "password=`cat $HOME/.secret`"; }; f
> +"!f() { echo password=`cat $HOME/.secret`; }; f"

This is one of the examples shown, each shows possible value that
can be given to credential.helper variable.  Reproducing them fully:

    # run "git credential-foo"
    foo

    # same as above, but pass an argument to the helper
    foo --bar=baz

    # the arguments are parsed by the shell, so use shell
    # quoting if necessary
    foo --bar="whitespace arg"

    # you can also use an absolute path, which will not use the git wrapper
    /path/to/my/helper --with-arguments

    # or you can specify your own shell snippet
    !f() { echo "password=`cat $HOME/.secret`"; }; f

These are examples of values, and how they may have to be quoted in
various environments is not discussed here.  

We will not want a patch that says that the second example is wrong
because "spaces separate arguments in shell and a string with a
space in it must be quoted", i.e.

    $ git -c credential.helper="foo --bar=baz" frotz

and does this

     # same as above, but pass an argument to the helper
    -foo --bar=baz
    +"foo --bar=baz"

because the quoting convention would be different depending on where
it appears.  In a .git/config file, i.e.

    [credential]
	helper = foo --bar=baz

is perfectly fine without quoting.

    $ git -c credential.helper='!f() { echo "password=`cat ...`"; }; f' frotz

would be how you would pass a one-shot config from shell.

Now, the reason why I said what you did is correct but the
justification is wrong is because the semicolon does pose a problem
in the .git/config file.  In fact

    [credential]
	helper = !f() { echo "password=`cat ...`"; }; f

would *NOT* work, because semicolon introduces a comment in the
configuration file.

For this particular case, you can just do

    [credential]
	helper = !echo password=`cat $HOME/.secret`

without any quoting issues, though.

Having said all that, I think we should clarify what these sample
strings are in the introductory text in the examples.  

I've always thought that they are illustrating possible values and
how to express that value in the context the values appear in is up
to the readers who learn what values to write in this document (and
they learn from manual for shell to learn the shell quoting
convention and manual for 'git config' to learn the config quoting
convention).  Hence my initial reaction to your patch was "shell?
Quoting for shell is outside the scope of the explanation here".

On the other hand, for anybody who assumes that these examples are
literally showing what you write after "[credential] helper = " in
the configuration file, the example clearly is wrong and dq may be
needed (but yours is also wrong, in that it loses double quotes
around the argument to echo; if ~/.secret file had a tab in it, the
helper will now yield a wrong password and you won't be able to log
in).


  reply	other threads:[~2020-04-30 18:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 14:36 [PATCH] doc: fix quoting bug in credential cache example douglas.fuller
2020-04-30 18:09 ` Junio C Hamano [this message]
2020-05-01  5:57   ` Jeff King
2020-05-01  6:19     ` Jeff King
2020-05-01  6:20       ` [PATCH 1/2] gitcredentials(7): clarify quoting of helper examples Jeff King
2020-05-01  7:19         ` Andreas Schwab
2020-05-01  7:31           ` Jeff King
2020-05-01  6:23       ` [PATCH 2/2] gitcredentials(7): make shell-snippet example more realistic Jeff King
2020-05-01  6:26         ` Junio C Hamano
2020-05-01  6:32           ` Jeff King
2020-05-01  6:35             ` Jeff King
2020-05-01  7:32               ` Jeff King
2020-05-01  7:33                 ` [PATCH v2 1/2] gitcredentials(7): clarify quoting of helper examples Jeff King
2020-05-01  7:33                 ` [PATCH v2 2/2] gitcredentials(7): make shell-snippet example more realistic Jeff King
2020-05-01 15:11               ` [PATCH " Junio C Hamano
2020-05-01 14:40       ` [PATCH] doc: fix quoting bug in credential cache example douglas.fuller
2020-05-01  6:20     ` Junio C Hamano
2020-05-01  6:25       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr1w4sv5t.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=douglas.fuller@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).