Jakub Narebski wrote:
Well, I'd divert stderr in tests cases (or use simply 'test_external'),
or better filter stderr, only in those cases where there is spurious
but not dangerous thing on stderr.
Since you can only run whole perl scripts with test_external, we'll have
to resort to using those discard_/restore_stderr functions. I doubt
filtering for specific messages is worth the effort.
But again, I think the solution would be either to add feature to
Git.pm, something like command_output_pipe_no_stderr, which would
redirect stderr to /dev/null,
(FYI, Git.pm has such a feature in the command method, though it it
simply closes STDERR and doesn't properly re-open it, I believe.) The
Git::Repo API I'm writing doesn't currently generate any spurious output
on stderr, but if it ever does I'll make sure it gets discarded.
Since you're accessing http://localhost/ URLs, the web server's PATH is
in effect,...
It isn't. http://localhost/ is just access convention,
Yup, I should've read TFM. :) On my system, $PATH is empty in
gitweb.cgi for some strange reason, but since using an absolute path for
$GIT works, I won't track it down for now.
[*1*] it would be nice to have perl_application in WWW::Mechanize::CGI,
which would simply setup %ENV and use do() instead of system() on
provided application.
Gitweb and probably CGI::Carp qw(fatalsToBrowser) use 'exit', so we'd
have to use Test::Trap (or so) to catch those. I think we should defer
this until performance actually becomes an issue.
-- Lea
--
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
