Front page | perl.perl5.porters |
Postings from November 2000
Re: PerlIO - what next ?
Thread Previous
|
Thread Next
From:
barries
Date:
November 8, 2000 10:01
Subject:
Re: PerlIO - what next ?
Message ID:
20001108130009.A28543@jester.slaysys.com
> That almost looks cool, if unworkable. But it does give me the idea
> that we could have
>
> open PIPE, "-|", ['cat', '-n', 'file']
This is very close to what IPC::Run does, and I've found it to be very
workable. A few examples adapted from current code, showing that passing the
command line as an ARRAY ref frees you up to do all sorts of nifty
shell-like things using plain scalars.
run( [qw( p4 counter change )], '>', \$max ) ;
chomp $max ;
run(
[ 'p4', 'files', map $self->denormalize_name( $name ) . "\@$_", @$labels],
'>', \$files,
'2>', \$errors,
);
## `p4 print` emits a status line to stdout before emittign the file's text
run(
[ 'p4', 'print', $self->denormalize_name( $fn ) . "#$rev" ],
'|', sub {
@ARGV = () ; ## Make this a STDIN filter.
<> ; ## Throw away the first line, a p4 file header line
while (<>) {
print ;
}
close STDOUT ;
## TODO: Rework this to get rid of dependancy on Unix signals
kill 9, $$ ; ## Exit without running DESTROYs.
},
'>', $wp,
) ;
Now if only I could close all filehandles, I could make subprocesses a little
more isolated from the parent and more reliably daemonizable :).
FWIW, I've found the pipe-to-anonymous-sub construct in that last example
to be less then usable in the face of DESTROY getting called both in the
parent and in the child process: it doesn't behave like exec. Thus the
C<kill 9, $$>.
Just a little experience from the field on that kind of API.
- Barrie
Thread Previous
|
Thread Next