Re: [PATCH] git-send-email: fix get_maintainer.pl regression

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 21, 2017, 00:30 UTC
Message-ID: <CAPig+cQvjX4MxttytKu=et2tBz5QoaDNtp10oqvynDJGYLxUWQ@mail.gmail.com>
In-Reply-To: <D810DA8B202742B38343EBB44BD54A1D@PhilipOakley>

On Mon, Nov 20, 2017 at 7:07 PM, Philip Oakley <philipoakley@iee.org> wrote:

Show 25 quoted lines

> From: "Eric Sunshine" <sunshine@sunshineco.com>
> On Sat, Nov 18, 2017 at 9:54 PM, Eric Sunshine <sunshine@sunshineco.com>
> 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@iee.org/
> 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...