Re: [PATCH 3/5] run-command: Elaborate execvp error checking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 25 Jan 2012 20:22:22 +0100, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:

Frans Klaver wrote:
Jonathan Nieder wrote:

Could you give an example?

The case that triggered me to work on this. I had an incorrect entry
in my PATH and some aliasing tests failed. The generated command
output was something like

fatal: script: Access Denied

Sorry for the lack of clarity.  I meant that a (precise) "before and
after" example could make the commit message a lot easier to
understand.

Ah I see. I'll add something along those lines.


[...]
What happens on Windows?

I haven't changed anything on the windows side, so that probably
sticks to the old behavior.

This was mostly a comment on the change description --- unless I look
at the patch, if I try this out on Windows after reading the changelog
I would end up utterly confused.  For patch 5/5, it also brings up
worries about consistency --- if systems are going to be relying on a
missing #! interpreter being treated differently from a missing script
for the sake of silent_exec_failure, do the same considerations apply
on Windows, too?

I'm actually not sure if scripts would be relying on this. There is of course a good chance that people actually will rely on it, regardless of what we think. If there are consistency concerns on different platforms I'd probably have to work on that as well. Mentioning that windows isn't affected by these changes would be a start though.

Perhaps it's more along the lines of "this is not supposed to happen
in practice, and when it does, humans will find it easier to debug if
we error out hard instead of falling back to the 'if the command does
not exist' behavior (e.g., by trying an alias next)".  In other words,
maybe this is intended as an optional nicety rather than something
scripts would ever rely on.

Exactly. My concern was primarily the human interaction, so getting at least some pointer to the cause of the error. Would that be nice to have on windows as well? It probably would.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]