Q: PIO_unix_pipe
Leopold Toetsch
program and capture the program's output (or send something to the
program). I've hacked together a PIR script with some NCI code to use
this function - works fine - but the interface of PIO_unix_pipe() is a
bit clumsy to use:
* program arguments: currently not supported - use an Array PMC?
* return value: should probably be a ParrotIO PMC* instead of a ParrotIO*
* there is no opcode to use it, e.g.:
Pio = backtick Scmd, Pargv, Iflags
IFlags == 1 ... execvp (search path)
IFlags == 0 ... execv
or such.
Finally the code should probably be moved to config/gen/platform/.
Comments welcome
leo
Leopold Toetsch
> * there is no opcode to use it, e.g.:
> Pio = backtick Scmd, Pargv, Iflags
I've now integrated that into the C<open> opcode:
.local pmc pipe
pipe = open "/bin/cat -n", "|-"
# or
pipe = open "/bin/ls -l", "-|"
There is still no good way to pass arguments to commands - currently the
given command gets split at spaces, which is of course broken with
respect to quoted args.
examples/io/pipe{2,3}.imc shows both kind of usage.
leo
Dan Sugalski
> Leopold Toetsch <l...@toetsch.at> wrote:
> > * there is no opcode to use it, e.g.:
>
> > Pio = backtick Scmd, Pargv, Iflags
>
> I've now integrated that into the C<open> opcode:
>
> .local pmc pipe
> pipe = open "/bin/cat -n", "|-"
>
> # or
>
> pipe = open "/bin/ls -l", "-|"
>
> There is still no good way to pass arguments to commands - currently the
> given command gets split at spaces, which is of course broken with
> respect to quoted args.
Then lets add:
backtick Pfilehandle, Scommand, Imode
backtick Pfilehandle, Scommand, Imode, Pargarray
to the ops list. The first form just creates a new shell and passes in the
command as one big lump (quoting issues and all), while the second takes
an array of parameters and execs the command with those passed-in
parameters. Mode can be a bitmask:
bit 0: handle ties command's stdin
bit 1: Handle ties command's stdout
bit 2: handle ties command's stderr
bit 3: Fork the process
And yes, I know that Unices can't all tie multiple filehandles to child
processes well. That's fine, no reason to penalize the OSes that can...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
> "Dan Sugalski" <d...@sidhe.org> wrote:
> > On Mon, 7 Jun 2004, Leopold Toetsch wrote:
> >
> > > Leopold Toetsch <l...@toetsch.at> wrote:
> > > > * there is no opcode to use it, e.g.:
> > >
> > > > Pio = backtick Scmd, Pargv, Iflags
> > >
> > > I've now integrated that into the C<open> opcode:
> > >
> > > .local pmc pipe
> > > pipe = open "/bin/cat -n", "|-"
> > >
> > > # or
> > >
> > > pipe = open "/bin/ls -l", "-|"
> > >
> > > There is still no good way to pass arguments to commands - currently the
> > > given command gets split at spaces, which is of course broken with
> > > respect to quoted args.
> >
> > Then lets add:
> >
> > backtick Pfilehandle, Scommand, Imode
> > backtick Pfilehandle, Scommand, Imode, Pargarray
> >
> > to the ops list.
> Might there be a better name for this op? I know backtick isn't just
> Perl-ish; it's used in UNIX shells too. But for someone from a non-UNIX,
> non-Perl background, backtick may not mean a lot. That said, I'm not sure I
> can think of a metter name.
Yeah, good point. pipeopen maybe? (Though then that gets confused with
regular pipes) childproc? If it weren't so darned fundamental to the
languages we care about I'd just throw the thing into the standard library
and punt on it entirely...
Bernhard Schmalhofer
> On Mon, 7 Jun 2004, Jonathan Worthington wrote:
>>>Then lets add:
>>>
>>> backtick Pfilehandle, Scommand, Imode
>>> backtick Pfilehandle, Scommand, Imode, Pargarray
>>>
>>>to the ops list.
>>
>>Might there be a better name for this op? I know backtick isn't just
>>Perl-ish; it's used in UNIX shells too. But for someone from a non-UNIX,
>>non-Perl background, backtick may not mean a lot. That said, I'm not sure I
>>can think of a metter name.
>
>
> Yeah, good point. pipeopen maybe? (Though then that gets confused with
> regular pipes) childproc? If it weren't so darned fundamental to the
> languages we care about I'd just throw the thing into the standard library
> and punt on it entirely...
Hi,
in 'GNU m4' this is called 'esyscmd'. But I doubt that this is more
inuitive than 'pipeopen' or 'backtick'.
CU, Bernhard
--
**************************************************
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
Robert Spier
> regular pipes) childproc? If it weren't so darned fundamental to the
> languages we care about I'd just throw the thing into the standard library
> and punt on it entirely...
It seems like an example of opcode bloat to me.
Especially as it should be possible to implement this with a piping
open, or an equivalent of IPC::Open3, and a handful of other opcodes.
The whole thing would take fewer lines than this email.
-R
Leopold Toetsch
> It seems like an example of opcode bloat to me.
That's always the question: opcode or not.
> Especially as it should be possible to implement this with a piping
> open,
Yes. But C<open> needs another variant that takes an argv array.
open Ppipe, Scmd, SFlags, Pargv
and e.g.:
Scmd: "-|" # open pipe for reading (stdout, stderr)
"-1" # read stdout only
"-2" # read stderr only
"|-" # open pipe for writing
"-|-" # Open2, Open3 variants like above
> -R
leo
Larry Wall
: Yeah, good point. pipeopen maybe? (Though then that gets confused with
: regular pipes) childproc?
In Perl 5 backticks actually call the "readpipe" function, which is
even documented, will wonders never cease.
: If it weren't so darned fundamental to the
: languages we care about I'd just throw the thing into the standard library
: and punt on it entirely...
I don't see it as all that fundamental. It's more of a convenience
function. So punt away, as far as I'm concerned.
Larry