On Tue, Mar 11, 2008 at 06:30:57PM +0100, Jakub Narebski wrote:
> On Tue, 11 March 2008, Frank Lichtenheld wrote:
> > On Sat, Mar 08, 2008 at 05:57:20PM +0100, Jakub Narebski wrote:
> >>
> >> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> >> index a5df2fe..ba97a7b 100755
> >> --- a/gitweb/gitweb.perl
> >> +++ b/gitweb/gitweb.perl
> >> @@ -1455,6 +1455,35 @@ sub git_cmd_str {
> >> return join(' ', git_cmd());
> >> }
> >>
> >> +# my $fh = output_pipeline(['cmd_1', 'option'], ['cmd_2', 'argument']);
> >> +# is equivalent to (is the "list form" of) the following
> >> +# open my $fh, "-|", "cmd_1 option | cmd_2 argument"
> >> +#
> >> +# Based on http://www.perlmonks.org/?node_id=246397
>
> Note that this patch is a bit "cargo cult" (copy'n'paste) programming...
>
> > It might be worthwile to look into how e.g. IPC::Run does this.
>
> Thanks for the pointer. I look at it.
After taking a look at the IPC::Run code myself I'm not really sure it
is really "worthwile", as I put it, to try to understand that.
Creating a less flexible solution that is readable might be better.
> >> +sub output_pipeline {
> >> + my @commands_list = @_;
> >> + exit unless @commands_list;
> >> +
> >> + my $pid = open(my $fh, "-|");
> >> + #die "Couldn't fork: $!" unless defined $pid;
> >
> > Why are all the die's commented out?
>
> The goal is to have gitweb deal with errors gracefully. It should
> generate some kind of '503 Server Error' page, instead of dieing
> without output, or what would be even worse, in the middle of output.
>
> I haven't examined how it should be writen for this RFC patch, so
> I have commented out 'die' just in case. In the final version (if it
> will be decided to go this route) it should be cleaned out.
Ok, I guessed as much, but wanted to make sure ;)
> > Thw whole concept of processing the array backwards might be shorter,
> > I personally find it somewhat confusing though.
>
> I'm not sure if it is not the only possible way, as the (first) parent,
> I think, has to return filehandle. But I might be mistaken.
>
> > What happens to all these child processes anyway if one of them fails to
> > exec?
>
> Original snippet returned in addition to filehandle also list of pids.
> Perhaps I have oversimplified this snipped... or it was to simple to
> begin with.
I'm not really convinced yet that dealing with a shell is much worse
than dealing with IPC ;)
Jokes aside, my idea for implementing something like this would be to
use explicit pipe()'s and fork()'s instead of the open() magic. With
better control over the filehandles and pids you might be able to build
a more robust solution.
Gruesse,
--
Frank Lichtenheld <frank@xxxxxxxxxxxxxx>
www: http://www.djpig.de/
--
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
