Hi,

  Thanks for the tip about  

> The book Mastering Perl/Tk has a pretty good Chapter 3 on Geometry
Management.  
> You can probably read it for free with an sign up at
http://safari.oreilly.com/


about the piping question, it's not an either/or situation. It could be
both.
A good example is the unix wc command. First create a small file

echo "hello" > hello.txt             # 6 chars "hello" + "\n"

then do:

# piped input but no command line options (so uses "default" options)
cat hello.txt | wc
        1       1       6

# both piped input and command line options
cat hello.txt | wc -c
6

# only command line options
wc -c hello.txt
6

I have tried similar to your suggestion (many different combinations):

> This will test for a pipe

> #!/usr/bin/perl
> # -t tests if a tty is input, else it's a pipe 
> 
> if (@ARGV == 0 and -t) {
>          die "Usage: $0 INPUT\n";
>      }
> 
> while (<>) {
>          ## process input file(s) here 
>      }
> __END__


The problem(s) with using -t and <> (as above) are:

if you give only command line line options, the program will
hang waiting for input. 

If I change it to if-else type decision making, -t causes the
piped input to be ignored.


As I said, I hacked together a subroutine from examples in the
Perl Cookbook, but it's not very elegant:


sub piper {
    my @_ARGV = @ARGV; @ARGV = ();      # save command line options (if
any)
    my @input = ();

   $SIG{ALRM} = sub { die "timeout" };

   my $pid;
   if ($pid = open(CHILD, "-|")) {                      # parent code
        while(<CHILD>) {                                # gets piped
input from CHILD (if any)
            push @input, $_;
        }
        close CHILD;
        alarm(0);
    }
    else {                                      # child code
        die "cannot fork: $!" unless defined $pid;

        eval {
            alarm(1);
            while(<>) { print; }                        # piped input
goes to parent (if any)
            alarm(0);
        };
        exit;
    }

    @ARGV = @_ARGV;                             # restore so we can
parse any options
    return @input;                              # this is any data which
was piped in
}


any comments/suggestions about this solution are greatly appreciated. As
I said, surely there is
a module out there that does this type of thing better?

regards,

John

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>


Reply via email to