develooper Front page | perl.perl5.porters | Postings from July 2012

todo: readpipe(LIST) -- what does that mean?

Thread Next
From:
Darin McBride
Date:
July 14, 2012 21:00
Subject:
todo: readpipe(LIST) -- what does that mean?
Message ID:
3555741.n6bQuF3bp3@naboo
I see rjbs' wishlist pulled from Porting/todo.pod, and thought the first one 
was interesting:

=head2 readpipe(LIST)

system() accepts a LIST syntax (and a PROGRAM LIST syntax) to avoid
running a shell. readpipe() (the function behind qx//) could be similarly
extended.

Now, for a number of reasons, I don't think it wise to pursue a grant for such 
work myself, largely because that kind of implies a certain amount of 
expertise in producing a result, and I don't have said expertise in the perl 
guts.  In fact, this is interesting to me for exactly the opposite reason: to 
gain some expertise through a focused attempt (*).  Also things like 
"timeline" and "commitment" are a bit optimistic :-)

So, looking at this a bit, I've had a few thoughts:

a) The todo is backwards: it looks like qx is the function behind readpipe :-)  
However, since I don't think we want to complicate qx to take a list (I think 
that "qwx( some list here)" would be of limited use without interpolation, and 
qw doesn't interpolate, so I expect it to get messy just from a UX 
perspective), what this todo effectively means is that qx is now a subset of 
readpipe.  So I'm thinking that a first foray here might be to just switch the 
implementation around such that we have a "readpipe" op that is distinct from 
qx, and then have qx call the readpipe op.  This should not affect any tests.

b) The prototypes confuse me.  Right now, readpipe takes a prototype of _, and 
accepting a list would change the syntax.  For example, there's the code 
example in pod/perl589delta.pod C<print readpipe $x, $y> which deparses today 
to C<print `$x`, $y>, but this change would presumably make it (roughly) 
C<print `"$x" "$y"`>.  I'm not sure if this backwards-incompatibility is 
acceptable or not.  And, I'm not sure what prototype this gets: C<_;>, C<_;@>, 
C<[_@]> or what.  I usually avoid prototypes when possible :-)

c) *Most* of the time that I do use qx, I include a redirection of stderr 
somewhere (either 2>&1 or > /dev/null).  If readpipe(LIST) avoids the shell, 
this won't be quite so trivial to do.  I'm wondering if there should be 
something for this as it seems like a reasonable desire.  Then again, 
system(LIST) doesn't (currently?) provide this, either.

So, I'm going to take a stab at (a) first, see what I learn, etc., and see if I 
can come up with a patch for it.  And then we'll see about the rest :-)  
Hopefully by then I'll understand more.

Or someone else will have stepped up to do it. :-S


(*) Nearly every "new technology" I've learned in programming (C++, STL, Perl, 
AnyEvent/Coro, LWP, CGI, etc.) have been through small-to-medium-sized 
projects.  This just looks like an interesting smallish project and so piqued 
my interest.
Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About