Thread (13 messages) flat view 13 messages, 4 authors, 2016-06-15

Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting

From: Ilari Liusvaara <hidden>
Date: 2016-06-15 22:47:57

On Thu, Dec 31, 2009 at 06:48:02PM +0100, Johannes Sixt wrote:
Ilari Liusvaara schrieb:
quoted
On Thu, Dec 31, 2009 at 04:44:37PM +0100, Johannes Sixt wrote:
quoted
Ilari Liusvaara schrieb:
 
And you change this by treating the helper command not as a git
command, but as a normal command that happens to start with 'git-'.
Whether this interpretation is suitable for the transport layer, I
do not want to decide and I will certainly not object. :-)
The transport helpers are special: they shouldn't be built-in.
An alternative solution would be to forward the silent_exec_failure
flag to exec_git_cmd() to unify the treatment of the error condition
with the non-git-command error path.
Won't work. The error in git command case would be noted in another memory
image. And passing that back would be nasty to say the least.
 
In case 3, it is expected that the child process prints a suitable
error message. Therefore, you should start with merely replacing the
unconditional

	exit(127);
by
	if (errno == ENOENT)
		exit(127);
	else
		die_errno("Cannot exec %s", cmd->argv[0]);

And then you can think about how you support the ENOENT case better.
My proposal for this was to do the PATH lookup manually before the
fork(), and then the above conditional would melt down to simply:

	die_errno("Cannot exec %s", cmd->argv[0]);
The child process can't sanely print anything. Stderr would go to
who knows where. Parent process should have much better idea what to
do with errors.


-Ilari
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help