Re: [PATCH] git-send-email: honor $PATH

[Florian Klink <flokli@flokli.de>]

On 17-11-19 10:04:58, Junio C Hamano wrote:
>"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> This patch adds support for PATH, but it also removes the fixed paths.
>> On many systems, unprivileged users don't have /usr/sbin in their PATH,
>> and I know of no systems which provide /usr/lib as a PATH value.
>> Therefore, it's possible that this change will break automatic detection
>> of sendmail for many users.
>
>It is more than possible ;-) that this change alone is a regression.
>
>> I think what you probably want to do is use entries in PATH first, and
>> leave the two old values as backups at the end.
>
>I do not think it would make things worse if the change were to do
>the two standard places first and then try elements on the $PATH;
>split of $PATH needs to be done carefully (Windows?), though.

Support to detect sendmail binaries in windows' PATH seems a bit more complex.
The separator is different, and PATHEXT would need to be considered too.  I'm
not even sure if having a sendmail binary in PATH on windows is something usual
or if defaulting to smtp to localhost (what we currently do) is good enough (tm).
If we want to start parsing PATH under windows too, I'd suggest to use
File::Which instead of implementing it on our own.

>I would feel a lot more worried about trying elements on the $PATH
>first and then using the two standard places as fallback.  If the
>order of addition matters at all, that would mean that trying
>elements on $PATH first and then falling back to the two standard
>places *will* change the behaviour---for the affected users, we used
>to pick one of these two, but now we would pick something different.
>sendmail is usually installed out of the way of $PATH for regular
>users for a reason, so picking anything whose name happens to be
>sendmail that is on $PATH does not sound right.
>
>Of course, for users who do not have sendmail at one of the two
>standard places _and_ has one on one of the directories on $PATH,
>the order in which we check would not make a difference, so my
>suggestion would be to do the other way around.

I could happily provide a patch that does it the other way round, too. But let's
first decide on what to do with windows ;-)

Cheers,
Florian