Hi, Junio, ZheNing Hu <adlternative@xxxxxxxxx> 于2021年3月30日周二 下午7:22写道： > > In addition, I now found a small bug in ".cmd", > > git config -l |grep bug > trailer.bug.key=bug-descibe: > trailer.bug.ifexists=replace > trailer.bug.cmd=echo 123 > > see what will happen: > > git interpret-trailers --trailer="bug:text" <<-EOF > `heredocd> EOF > > bug-descibe:123 text > > "text" seem print to stdout. > > I'm looking at what's going on here. > Here I may need to think with you whether it is reasonable to pass "$1". I found that we passed the parameters in the above situation like this: (gdb) print cp.args.v[0] $7 = 0x5555558f4e20 "echo \"123\"" (gdb) print cp.args.v[1] $8 = 0x5555558ee150 "text" At this time, our idea is base on that v[0] will be the content of the shell, and v[1] will be the $1 of the shell. But in fact, git handles shell subprocesses in a special way: The `prepare_shell_cmd()` in "run-command.c" seem to use "$@" to pass shell args. Before exec: (gdb) print argv.v[1] $22 = 0x5555558edfd0 "/bin/sh" (gdb) print argv.v[2] $23 = 0x5555558f4c80 "-c" (gdb) print argv.v[3] $24 = 0x5555558ed4b0 "echo \"123\" \"$@\"" (gdb) print argv.v[4] $25 = 0x5555558f5980 "echo \"123\"" (gdb) print argv.v[5] $26 = 0x5555558edab0 "abc" (gdb) print argv.v[6] $27 = 0x0 Some unexpected things happened here. Maybe "abc" was wrongly used as the parameter of "echo"? Looking forward to your reply. -- ZheNing Hu
