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

Re: [PATCH] be paranoid about closed stdin/stdout/stderr

From: Stephen R. van den Berg <hidden>
Date: 2016-06-15 22:45:14

Karl Chen wrote:
Yes, I can work around this issue with sh -c 'git fetch
0</dev/null', and maybe it shouldn't close(0) in the first place.
But I don't see the harm in being safe.  It's one less potential
surprise for users.  This is the first program I've encountered
that broke due to stdin being closed, and it took debugging to
figure out that was the reason.
I understand the reasoning, and there sure is a valid point in here
(principle of least surprise), but there is also the case of hiding
problems.
It's a bit unclear which should prevail here.
The point is that if you actually make git detect and correct
closed descriptors which should have been open, then you are merely
passing the buck to all other programs the user is starting which might
or might not break.

Maybe the breakage of other programs is only in conjunction with
full-moon and FD 0 closed, in that case you make the problems/bugs even
*harder* to find for the user by making git "fix it for you".
-- 
Sincerely,
           Stephen R. van den Berg.
"First, God created idiots.  That was just for practice.
 Then he created school boards."  --  Mark Twain
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help