On Mon, Nov 20, 2017 at 7:07 PM, Philip Oakley <philipoakley@xxxxxxx> wrote:
> From: "Eric Sunshine" <sunshine@xxxxxxxxxxxxxx>
> On Sat, Nov 18, 2017 at 9:54 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
> wrote:
>> > --- 8< ---
>> > diff --git a/git-send-email.perl b/git-send-email.perl
>> > @@ -1724,7 +1724,7 @@ sub recipients_cmd {
>> > - open my $fh, "-|", "$cmd \Q$file\E"
>> > + open my $fh, "-|", "\Q$cmd\E \Q$file\E"
>> > --- 8< ---
>> >
>> > However, it's possible that might break existing users who rely on
>> > --cc-cmd="myscript --option arg" working. It's not clear which
>> > behavior is correct.
>>
>> The more I think about this, the less I consider this a bug in
>> git-send-email. As noted, people might legitimately use a complex
>> command (--cc-cmd="myscript--option arg"), so changing git-send-email
>> to treat cc-cmd as an atomic string seems like a bad idea.
>
> A while back I proposed some documentation updates
> https://public-inbox.org/git/1437416790-5792-1-git-send-email-philipoakley@xxxxxxx/
> regarding what is (should be) allowed in the cc-cmd etc., and at the time
> Junio suggested that possible existing uses of the current code would be
> abuses. I didn't pursue it further, but it may be useful guidance here as to
> potential real world command lines..
Thanks for the link. I had forgotten that discussion, but re-reading
it brought most of it back. Given how the discussion ended -- with
valid use being that --cc-cmd names a program which accepts a single
argument -- then the above patch to recipients_cmd() might indeed be
desirable.
And, the documentation is still lacking, saying nothing about that
single argument passed to the cc-cmd...
