Re: [PATCH v4] [GSOC]trailer: pass arg as positional parameter

[ZheNing Hu <adlternative@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2021年4月1日周四 上午2:29写道：
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > ZheNing Hu <adlternative@gmail.com> writes:
> >
> >> The configuration is like this:
> >> trailer.bug.key=BUG:
> >> trailer.bug.ifexists=add
> >> trailer.bug.cmd=echo "123"
> >>
> >> And use:
> >>
> >> $ git interpret-trailers --trailer="bug:456" --trailer="bug:789"<<-EOF
> >> EOF
> >>
> >> BUG: 123
> >> BUG: 123 456
> >> BUG: 123 789
> >
> > I think that is quite expected.  You said the command to run is
> > 'echo 123', and that is not "pick a directory $D on $PATH where
> > there is an executable '$D/echo 123' exists, and run that".  It
> > runs the given command with the shell, and in general that is
> > what we want for end-user supplied commands specified in the
> > configuration file [*1*].
> > ...
> > *1* Imagine .editor set to 'emacs -nw' or 'vim -f'; we do not want
> >     Git to find a directory on $PATH that has an executable whose
> >     name is 'emacs -nw' and run that file (i.e. give 'emacs -nw' as
> >     the first argument to execlp()).  Instead, you'd want to behave
> >     as if the user typed "emacs -nw", followed by any arguments we
> >     want to give to it (in .editor's case, the name of the file to
> >     be edited) properly quoted for the shell.
> >
> >     And the way we do so is to form a moral equivalent of
> >
> >       execlp("sh", "-c", "emacs -nw \"$@\"", ...);
> >
> >     and put the arguments at the end where I wrote ... (we actually
> >     do so with execvp(), but illustrating with execlp() is easier to
> >     read and write---hence "a moral equivalent of").
>
> So, learning from that .editor example, what you can do when you do
> not want to take any parameter is to explicitly ignore them.
>
> Let's take the very basic form first.  Imagine you wrote a little
> script and wanted to see three "123", ignoring end-user input after
> "--trailer=bug:".
>
>     .cmd = my-script 123
>
> would run 'my-script "$@"'.  What should you write in my-script to
> cause that happen?  Here is an example solution:
>
>     #!/bin/sh
>     echo 123
>
> Notice that "$1" is completely ignored, even if the machinery that
> drives .cmd makes three calls?
>
>         sh -c 'my-script 123 "$@"'
>         sh -c 'my-script 123 "$@"' 456
>         sh -c 'my-script 123 "$@"' 789
>
> The way to do the same without an extra script on disk is for you to
> use sh-c yourself.
>
>     .cmd = sh -c 'echo 123'
>

This is indeed a viable solution, But the extra "sh -c" seems to put an
unnecessary burden on the user.
Sometimes I wonder, why not recommend using environment variables
like $ARG?

> And if you do want to use $1, you can do the same.  E.g. if you want
> to double them in the output, you'd probably do something like this:
>
>     .cmd = sh -c 'echo "<$1 - $1>"'
>
> You'd need to quote the value appropriately for the config file,
> though.

In fact, In the following example, trailer <value> contains whitespaces ,

$ git interpret-trailers --trailer="bug:the information manager from hell"

which can make it to work properly (But it's a little bit tedious):

$ git config trailer.bug.cmd "sh -c \"echo \\\"\$1\"\\\""
$ git interpret-trailers --trailer="bug:the information manager from hell"

Bug-from:
Bug-from: the information manager from hell

Is there an easier way?
Or can make the user ignore the details of "sh -c"?

Thanks.

--
ZheNing Hu