How do I chdir in an exec?

[Michael G Schwern]

Nicholas Clark wrote:
> On Sun, Mar 08, 2009 at 09:10:46PM -0400, David Golden wrote:
>> On Sun, Mar 8, 2009 at 4:21 PM, Michael G Schwern <schwern at pobox.com> wrote:
>>> A simple solution to this problem would seem to be allowing exec (or a new
>>> option) to return a filehandle in place of a command to run.
>>>
>>>  exec => sub {
>>>      ...derive $sub_module, $command and $file...
>>>
>>>      chdir "ext/$sub_module";
>>>      open my $fh, "-|", $command, $file;
>>>      chdir "../..";
>>>
>>>      return $fh;
>>>  }
>>>
>>> This gives the user complete control over the running of the test without
>>> having to bail out to a separate script.
>>
>> Unfortunately, not portable.  See perlport and open.

Thank you, by entirely missing the point you have illustrated the point.

The point is not the details of the code, whether its portable, using strict
or checking open.  As a TAP::Harness user maybe I care about that, and maybe I
don't.  Maybe I'm writing something that only runs on Unix machines.

By giving the user total control over how each test is executed we allow them
to care about what they care about rather than what WE care about.  You can't
do that right now without writing a separate exec file.  That doesn't make it
any safer, just more annoying.

Here's one to read URLs out of the test files and fetch the test results from
the web.

exec => sub {
    my($harness, $file) = @_;

    open my $fh, $file or die $!;
    my $url = <$fh>;
    chomp $url;

    # get_url() being some function that returns a filehandle to
    # a web get
    my $web_fh = get_url($url);
    return $web_fh;
}


> I think the solution to the portability issue is to subclass
> TAP::Parser::Iterator::Process and provide setup() and teardown() methods to
> do the directory changing.

setup and teardown is handy.  It only solves a subset of problems.  It won't,
for example, give you control over which perl is executed (let's say you want
to run each test against N different perl versions) or what switches it gets.

It would be nice to expose more TAP::Parser::Source::Perl methods.
Particularly those which generate a command to run and also the code which
runs it.  I found that the code to scan #! for taint is available, but not the
rest.  This would allow one to reproduce some of what
TAP::Parser::Source::Perl does without reinventing too much of the wheel.


> As to the file handle proposal - that seems a useful addition to me, because
> it's cleanly defined, and extensible in ways we've not yet thought of.
> What am I missing?

The idea of a callback doing different things depending on its return value is
a little odious.  I was trying to figure some way to separate it out into its
own callback, but then what happens when you want to use a filehandle for some
but execute a program for others?


-- 
The mind is a terrible thing,
and it must be stopped.