Is it really the redirection that is the problem?
The process seeks $fh back to the beginning, reads 5 bytes from
it (to ensure that is 'link '), and then forks to feed $fh to
git-hash-object.
Now what do you really want to hash here? I do not know what
this "file that begins with 'link '" magic is about, but I
suspect that the child may or may not start reading from byte
offset 5 of that file, depending on how the low-level I/O is
tied to Perl.
Here is a little test script to imitate what the part in
close_file sub is doing. What does it output on MacOS (or
whatever systems that are having the same problem)?
On a Linux box, it appears that it reads the remainder of the
file and the test script says "child says: >>12345", so I am
assuming that is what close_file sub wants to do. If my
suspicion is correct, you would get "child says: >>link 12345",
in which case sysseek() commented out below would help,
perhaps.
-- >8 --
#!/usr/bin/perl -w
open F, ">footest";
print F "link 12345\n";
close F;
my ($fh, $buf, $n, $pid, $out);
open $fh, "<footest";
seek($fh, 0, 0);
$n = read($fh, $buf, 5);
print "read[$n]: $buf\n";
$pid = open $out , '-|';
if (!$pid) {
my $at = tell $fh;
print "child: at $at\n";
# We may want to do
#
# sysseek($fh, 5, 0);
#
# here.
open STDIN, '<&', $fh;
exec qw(sed -e s/^/>>/);
}
while (my $read = <$out>) {
print "child says: $read";
}
close ($out);
close ($fh);
-
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