using IPC::Open2

acid_kewpie · 09-17-2002, 02:04 PM

hi hi,

i'm trying to suss out IPC::Open2 in order to interactively use mplayer to get information about the film, and as such i need to do two things:

Write to MPlayer's STDIN in realtime
Read to MPlayer's STDOUT in non-realtime

currently my cludge of test code is something like

Code:

use IO::Handle;
use IPC::Open2;

open2(\*R, \*W, 'mplayer /usr/monsters_inc.avi -slave');
for ($t=0;$t<5;$t++)
{
  while ($i=<R>)
  {
    R->autoflush();
    print "$t $i\n";
#    $got=<R>;
#    print $got;
  }
  sleep 1;
  print W "seek 20\n";
  W->autoflush();
print "tttttttttttt $t\n";
}

in this instance i'm trying to use a while loop to empty the stdout, and each time it's empty, send a new input to stdin, but while will only terminate on EOF i think, so it is just sitting waiting for input, hanging.

Can anyone give some useful input on this? it's just that i need to access both in different ways... would forking help? if so i can't really suss out how to fork a little block of perl code...

TheLinuxDuck · 09-18-2002, 08:43 AM

As for the "hanging waiting for user input", you might consider using the Term::ReadKey module. This allows you to control how input is received and output is shown to the console/terminal in a simple manner.

Using ReadKey(-1), you can achieve unbuffered input, and it will effectively return an undef if nothing is waiting in the buffer, so your program won't hang. Here's the cpan link to the module's information:
http://ls6-www.cs.uni-dortmund.de/cg...%2fcpan%7c1474

(yuck, what a nasty looking URL)

Anyway, that should solve at least that part of the problem. (=

TheLinuxDuck · 09-18-2002, 08:47 AM

Also, just an FYI, it's a little more perlesque to do for loops as:

Code:

for my $t(0..4) {

...instead of the C format, as used in the code snippet.. it works just fine either way, but I had a wise perl teacher once tell me "If you're going to code in perl, code in perl..." (=

acid_kewpie · 09-18-2002, 09:17 AM

Well i've currently solved the situation with just a standard IO::Open and a temporary file to hold the output, which i don't really like, but i'm probably being a bit OTT about what i want to do, it would just be nice to be fully interactive... In a perl FAQ i found a lump of information about this form of deadlock and they really said it's not worth the hassle, which i'm tempted to agree with...

and yeah i'm getting the knack of perl style eventually! only been looking at it for a week or so seriously. before that i'd spent a while with python, and the style there is even further from c than perl... i'm getting there!

thanks

TheLinuxDuck · 09-18-2002, 09:27 AM

Quote:

Originally posted by acid_kewpie
and yeah i'm getting the knack of perl style eventually! only been looking at it for a week or so seriously. before that i'd spent a while with python, and the style there is even further from c than perl... i'm getting there!

Word! For a week, you're doing great. I have to be honest.. as much as I love perl... why would you use python first and then get into perl? Most people I know who get into python pretty much stay there.. I also hate to admit it, but python code looks so much nicer and cleaner than perl code..

But, alas, perl is my baby and I really enjoy it. So, my hats off to you, and I wish you the best of coding! (=

acid_kewpie · 09-18-2002, 09:37 AM

heh, well that was a test script... can i show off and show what i HAVE got in a week?

http://thirtythreeandathird.net/mrip/mrip

TheLinuxDuck · 09-18-2002, 10:07 AM

Wow! Looks like you've really made some progress! (=

If I may be so bold as to comment/critique... (=

It is generally a good idea to always use the pragma "use strict;". This causes a more strict ruleset of coding practices to be used, a little more C like.. all variables must be declared before use, etc.. it also helps the coder to find problems and things in the code.. it saves me a lot of time debugging... and it's not a bad idea to use "use warnings;" also.. this provided a little more verbose explanations of problems and warns of things that might not otherwise have been noted.

Also, I noticed that the code piping out to mplayer in "find_crop", but then in "title_info" and "ifo_dump", the code makes shell calls. Why not pipe in with these? It's really easy... especially since you already figured out how to pipe out.. just put the | on the other side, and treat the filehandle as the output of the piped program. Very nice way to handle that sort of thing in a very perlesque manner. (=

Props for using getops...

When I first learned perl, I hated the way that params are passed into functions, because there is really no control on how they are passed and how many there are.. well, there is a solution.. and this is just my personal preference here...

You can give function prototypes to the subs, and use some param slurping inside the sub to make a clean and user-friendly way to use each of them. Here is an example:

Code:

#!/usr/bin/perl
use strict;
use warnings;

sub doStuffThenPrint($$);       #  must receive two scalars

doStuffThenPrint "This is funky", "Scary monkey";
exit;

sub doStuffThenPrint($$)
{
  my($description) = shift ||
      die "doStuffThenPrint: Received no description\n";
  my($title) = shift ||
      die "doStuffThenPrint: Received no title\n";

  print uc(join("", $description, $title)), "\n";
}

Or, if you only require one scalar, but would like two:

Code:

sub doStuffThenPrint($;$)  # anything after ; is optional
{
  my($description) = shift ||
      die "doStuffThenPrint: Received no description\n";
  my($title) = shift || "default title";

  print uc(join("", $description, $title)), "\n";
}

You could even go so far as to check to make sure that they are or are not passing in references to scalars, arrays, or hashes:

Code:

sub doStuffThenPrint($;$)  # anything after ; is optional
{
  my($description) = shift ||
      die "doStuffThenPrint: Received no description\n";
  my($title) = shift || "default title";

  ref($description) eq "" or
      die "doStuffThenPrint: description must not be a reference\n";

  print uc(join("", $description, $title)), "\n";
}

Bear in mind, this is my personal style here.. not everyone will agree with this format.. I find that it works well for me.. one big reason for having the extra checking inside of the sub is because the prototype can be ignored if the sub is called as:

Code:

&doStringThenPrint;

With the extra checks, you just make sure to cover all bases.

Overall, I'm very impressed with your code! (=

acid_kewpie · 09-18-2002, 10:24 AM

well i'm used to hacking java and c, but certainly not to a professional level, and i'm only equipped with Perl In A Nutshell, as i'm feel comfrotable about the principles... This does seem to implicitly leave out things such as style though, but there's plent on perldoc.com about it (or rather on my system already... no idea why i alwys got to a website for it!)

Code:

 Also, I noticed that the code piping out to mplayer in "find_crop", but then in "title_info" and "ifo_dump", the code makes shell calls. Why not pipe in with these? It's really easy... especially since you already figured out how to pipe out.. just put the | on the other side, and treat the filehandle as the output of the piped program. Very nice way to handle that sort of thing in a very perlesque manner.

yeah i'm aware of that, it's something that will be resturctured soon, it was more a case of building from the ground up, and they were the first things, when i hadn't experience of file handles and such... There's certainly a heap of dies and condition check's i'll be adding as and when i get round to it.

I've found that scoping is being something of an issue because it is so vague, everything always seems global wherever an instance variable is created, but that's before i've put in some 'my's. I've certainly got used to the idea of a function always returning something, and i'm kinda resenting not really having to return anything! I'll certainly be going strict and all. thanks for the pointers.