* [PATCH] Don't try to reclose in command_close_bidi_pipe
@ 2009-01-30 4:59 Yuval Kogman
2009-01-30 14:35 ` Tay Ray Chuan
0 siblings, 1 reply; 4+ messages in thread
From: Yuval Kogman @ 2009-01-30 4:59 UTC (permalink / raw)
To: git; +Cc: Yuval Kogman
Some commands require their standard input to be closed (like
git-commit-tree). This patch changes command_close_bidi_pipe so no
longer tries to close already closed handles, resulting in an error.
---
perl/Git.pm | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 7d7f2b1..283bba8 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -422,6 +422,7 @@ sub command_close_bidi_pipe {
local $?;
my ($pid, $in, $out, $ctx) = @_;
foreach my $fh ($in, $out) {
+ next unless defined(fileno($fh));
unless (close $fh) {
if ($!) {
carp "error closing pipe: $!";
--
1.6.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] Don't try to reclose in command_close_bidi_pipe
2009-01-30 4:59 [PATCH] Don't try to reclose in command_close_bidi_pipe Yuval Kogman
@ 2009-01-30 14:35 ` Tay Ray Chuan
2009-01-30 15:06 ` Yuval Kogman
0 siblings, 1 reply; 4+ messages in thread
From: Tay Ray Chuan @ 2009-01-30 14:35 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
Hi,
On Fri, Jan 30, 2009 at 12:59 PM, Yuval Kogman <nothingmuch@woobling.org> wrote:
> Some commands require their standard input to be closed (like
> git-commit-tree). This patch changes command_close_bidi_pipe so no
> longer tries to close already closed handles, resulting in an error.
>From this message, you seem to intend this as a fix. Can you tell us
how one might go about to reproduce this issue?
> ---
> perl/Git.pm | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/perl/Git.pm b/perl/Git.pm
> index 7d7f2b1..283bba8 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -422,6 +422,7 @@ sub command_close_bidi_pipe {
> local $?;
> my ($pid, $in, $out, $ctx) = @_;
> foreach my $fh ($in, $out) {
> + next unless defined(fileno($fh));
Quoting the perldoc for fileno at http://perldoc.perl.org/functions/fileno.html
"(Filehandles connected to memory objects via new features of open may
return undefined even though they are open.)"
Is "unless defined(fileno($fh))" a reliable way to check if the handle
is closed?
--
Cheers,
Ray Chuan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Don't try to reclose in command_close_bidi_pipe
2009-01-30 14:35 ` Tay Ray Chuan
@ 2009-01-30 15:06 ` Yuval Kogman
2009-01-31 0:03 ` Tay Ray Chuan
0 siblings, 1 reply; 4+ messages in thread
From: Yuval Kogman @ 2009-01-30 15:06 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Don't try to reclose in command_close_bidi_pipe
2009-01-30 15:06 ` Yuval Kogman
@ 2009-01-31 0:03 ` Tay Ray Chuan
0 siblings, 0 replies; 4+ messages in thread
From: Tay Ray Chuan @ 2009-01-31 0:03 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
Hi,
On Fri, Jan 30, 2009 at 11:06 PM, Yuval Kogman <nothingmuch@woobling.org> wrote:
> 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.
Your usage seems to a very special case. You're closing the handle,
and then invoking the method "command_close_bidi_pipe", whose job is
to close the pipe handles passed to it (among other things). So, it
doesn't seem very good to make "command_close_bidi_pipe" to take into
account that you closed your handle independently.
Maybe you could write a pair of new functions for the commit-tree
command in the Git package, something like the
"_open_hash_and_insert_object_if_needed" and "hash_and_insert_object"
pair.
--
Cheers,
Ray Chuan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-31 0:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-30 4:59 [PATCH] Don't try to reclose in command_close_bidi_pipe Yuval Kogman
2009-01-30 14:35 ` Tay Ray Chuan
2009-01-30 15:06 ` Yuval Kogman
2009-01-31 0:03 ` Tay Ray Chuan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).