[Omaha.pm] bad perl - need help - dispatch table

Miller, Scott L (Omaha Networks) scott.l.miller at hp.com
Fri Aug 27 10:21:06 CDT 2004


Jay wrote:
> I suppose you could kludge up something to do files, then wait for STDIN...? 

Hmm, from the documentation you quoted below, unless you do something somewhat
silly like:

	@stinary = <STDIN>;  #slurp up all input from STDIN

which could eat a huge amount of memory, I think you have to process STDIN
before the files.  I think that behavior is what I would expect anyway as
you have to have a process generate some output first before that output
can be piped into this program. Since that output was created first, it
should be processed before any files that might also happen to be on the
command line of this program.

Said another way, you expect the files supplied on the command line to be
processed in order, STDIN is usually on the line before the program even:

	cat somefile.txt | thisprogram.pl process-this-file.too and-this.one

Therefore, the STDIN stuff comes before the first filename listed...
I don't use the backward pipe much (ever?), is it correct to be able to say

	thisprogram.pl < somefile.txt ?

And if so, can you also supply other files for thisprogram.pl to process?
After a few quick tests, I don't think this is valid under UNIX.  I seem
to be remembering DOS's broken version of 'more' many many years ago...

> You'd always *have to* have STDIN, though...

I just tested this, it sucessfully ignores STDIN, and processes the filelist

	close STDIN;
	while(<>) {
		print $_;
	}

-Scott

-----Original Message-----
From: omaha-pm-bounces at mail.pm.org
[mailto:omaha-pm-bounces at mail.pm.org]On Behalf Of Jay Hannah
Sent: Thursday, August 26, 2004 6:01 PM
To: Perl Mongers of Omaha, Nebraska USA
Subject: Re: [Omaha.pm] bad perl - need help - dispatch table



On Aug 26, 2004, at 11:01 AM, Miller, Scott L (Omaha Networks) wrote:
> Otherwise the (<>) will either ignore <STDIN> because there are 
> filename
> on ARGV, or ignore the filenames because it's got stuff to process on
> <STDIN>.  It's been too long since I ran into the problem to remember
> which...

If does one or the other, depending.  -grin-

perldoc perlop:

        The null filehandle <> is special: it can be used to emulate the behav-
        ior of sed and awk.  Input from <> comes either from standard input, or
        from each file listed on the command line.  Here's how it works: the
        first time <> is evaluated, the @ARGV array is checked, and if it is
        empty, $ARGV[0] is set to "-", which when opened gives you standard
        input.  The @ARGV array is then processed as a list of filenames.  The
        loop

            while (<>) {
                ...                     # code for each line
            }

        is equivalent to the following Perl-like pseudo code:

            unshift(@ARGV, '-') unless @ARGV;
            while ($ARGV = shift) {
                open(ARGV, $ARGV);
                while (<ARGV>) {
                    ...         # code for each line
                }
            }

        except that it isn't so cumbersome to say, and will actually work.  It
        really does shift the @ARGV array and put the current filename into the
        $ARGV variable.  It also uses filehandle ARGV internally--<> is just a
        synonym for <ARGV>, which is magical.  (The pseudo code above doesn't
        work because it treats <ARGV> as non-magical.)

        You can modify @ARGV before the first <> as long as the array ends up
        containing the list of filenames you really want.  Line numbers ($.)
        continue as though the input were one big happy file.  See the example
        in "eof" in perlfunc for how to reset line numbers on each file.

I've always wanted what <> does -- files *or* wait for STDIN. I suppose 
you could kludge up something to do files, then wait for STDIN...? 
You'd always *have to* have STDIN, though...

j

_______________________________________________
Omaha-pm mailing list
Omaha-pm at mail.pm.org
http://www.pm.org/mailman/listinfo/omaha-pm



More information about the Omaha-pm mailing list