Re: [PATCH] Don't try to reclose in command_close_bidi_pipe
- From
Yuval Kogman <nothingmuch@woobling.org>
- Date
- Jan 30, 2009, 15:06 UTC
- Message-ID
- <a891e1bd0901300706h4fdffe24m78c418f8c1ae7cd8@mail.gmail.com>
- In-Reply-To
- <be6fef0d0901300635v4e6009f1n7da405ebc4c8dd68@mail.gmail.com>
Resending, forgot to CC
2009/1/30 Tay Ray Chuan <rctay89@gmail.com>
> From this message, you seem to intend this as a fix. Can you tell us > how one might go about to reproduce this issue?
Here is an example: http://github.com/yanick/git-cpan-patch/blob/ed67d3f86f371764935fd0da3e7f08536c95b606/git-cpan-import#L190
Since git-commit-tree requires the message to be written before it can write the sha1 of the new commit object, the handle has to be closed already, which makes command_close_bidi_pipe die with an error. The workaround in the linked code reopens a fake handle so that close() will not error. For what it's worth, I've been poking at t/t9700/test.pl but since it's pretty sparse I figured I should contribute this fix independently.
> Is "unless defined(fileno($fh))" a reliable way to check if the handle > is closed?
Yes, since the handle is expected to be the result of a pipe open. The documentation refers to this case:
open my $fh, "<", \$buffer;
in which case the filehandle $fh has no associated file descriptor.
fileno() is not a universal check, but it is applicable in this situation.