Junio C Hamano <gitster@xxxxxxxxx> 于2021年4月1日周四 上午2:29写道：
>
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
> > ZheNing Hu <adlternative@xxxxxxxxx> 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
