Junio C Hamano [off-list ref] writes:
ZheNing Hu [off-list ref] writes:
quoted
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'
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.
Junio C Hamano [off-list ref] 于2021年4月1日周四 上午2:29写道：
Junio C Hamano [off-list ref] writes:
quoted
ZheNing Hu [off-list ref] writes:
quoted
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