in reply to Re: External program with large amounts of output
in thread External program with large amounts of output

It might also be reasonable to use the operating system to save the output to a file, and then load the file.

  % extprog >big.data
  % myperl big.data

[download]

Among other benefits, this lets you replay the output at will, allowing you to tweak the script without too much effort. You could also munge the data file to extract the first n records, as an additonal way of testing.

Finally, you can take all these data files you create in the process of testing and use them for regression testing: when you make a substantial change to your code, all those files will come in handy for verifying that you haven't borken anything.

The code you present seems a little odd to me. I would sooner have written it as

  open(CMDREAD, "$program $args |")
    or die "ERROR in executing $program $args: $!\n";

  while (<CMDREAD>){
    # do something with $_
  }
  close (CMDREAD);

[download]

i.e., lose the else. Sort of flatter, I guess. That, and I only use unless as a statement modfier, not for flow control.

  $foo = $bar + 1 unless $moon->phase < 0.2;

[download]


print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'

Replies are listed 'Best First'.
Re: Re:x2 External program with large amounts of output
by strat (Canon) on Apr 15, 2002 at 15:44 UTC
    Hello grinder,

    your way is much shorter and perhaps easier to read.

    The reasons why I wrapped it into an unless-else-block are the following:

    • If I post code for beginners or slightly enhanced perl-programmers, I try to post code that is as easy and flexible as possible; if they want to do something before die, the unless-construct is much easier to enhance (well, you could do e.g. open (CMDREAD, ...) or &DoSomething and die(...); or the like, but there you have to care about the returnvalue of &DoSomething and it becomes more complicated than necessary (seen so on www.perl.de) ).
    • The else-Block is not neccessary with die or return or the like. But if you replace the die with warn, all of a sudden "else" becomes very important. And some scripts are changed very often over the years (because requirements change or whatever), so I try to build full logical blocks whenever possible.
    • I hardly use die in my programs, because with the stuff I usually write it is often not ok to just die with a message; the script should try to solve the error by itself if possible or at least find some additional information about it or do some cleaning up, and so the "open or die" is idiomatic perl, but very often not usable to me. And so, in most of my posted code, die is just a placeholder for doing some better errorhandling.

    I'm very interested what other people think about this issue, so I'd be glad about lots of comments.

    Best regards,
    perl -le "s==*F=e=>y~\*martinF~stronat~=>s~[^\w]~~g=>chop,print"

[reply]
[d/l]

      Since you asked for comments... :)

      Bullet 1: To avoid calling a sub you could use a do {} block after the or. This way you don't have to worry about the return value and you can still add to that section of code (better error-checking, etc.)

      Bullet 2: agreed

      Bullet 3: In part I agree with your reasoning here, and where it applies to what you do, it's certainly a valid approach. I think you'll find, though, that other perl programmers will expect the idiomatic example in place of a more elaborate one. Especially when demonstrating an unrelated construct (reading piped output, in this case) it may be unnecessary to allow for growth of the example, and simplicity might be preferred. At the same time, I don't think your example was at all unclear, so it's really a matter of taste.

      ...what happened to my point? I could've sworn I had one when I started writing this. ;)

      -Bird
[reply]

In Section Seekers of Perl Wisdom