Is there a way to count the size of what's in the STDIN (all lines and not just one) other than saving it to a variable and using length()?

If you mean without reading until EOF, then no.

If STDIN is connected to the terminal, then there is no way to predetermine how much the user may type before hitting ^Z/^D.

If STDIN is connected to a pipe, there is no way to guess how much output the program on the other end might output. It might produce nothing, or never stop producing.

If you just mean without storing all of the content, but you are happy to read it all, then you can accumulate the lengths of all the lines without storing them:

my $count = 0;
$count += length while <STDIN>;
print $count;
[download]

That's covered in perlfaq5 under How can I tell whether there is a character waiting on a filehandle. Yes... it also covers determining how many bytes are available from the filehandle. The gist of it, however, seems to be that there isn't a very portable way, and that solutions may have to be tailored to your specific environment.

It seems like "There ought to be a module for that.", and there probably is.

I'm going to follow up a second time here...

I was thinking a little more about your question. I remember back to the days of my Econ classes, where the professor could answer just about any question with "It depends." How are you reading STDIN, and where is it getting its stream from? Let's say, for example, you've got a bunch of files listed on the command line, and you're reading them via the empty diamond operator: <> (see perlop). Before you start reading from them, @ARGV is going to have a list of filenames that were present on the command line when the script was invoked. It would be easy enough to use the -s function (perldoc -f -X) to check the file size.

my %sizes;

die "Can't pre-measure a TTY stream\n" if -t;

foreach( @ARGV ) {
    if( my $size == -s ) {
        $sizes{ $_ } = $size;
    }
}
[download]

The -t test checks whether your input is coming from a terminal. If it is, as BrowserUk pointed out, you can't measure it, just as you can't tell me today what date I should mark in my calendar as the end of time as we know it.

However, even -t is not getting you the whole story. Probably the best thing to do would be to fail unless -f (unless you're looking at a file). That's because your stream could be coming from a socket or a named pipe, and rather than test each of those cases individually, you may as well just fail if you're not looking at a file.

You also can’t size sockets, pipes, and a whole bunch of devices.

It's going to be data piped in from the terminal. I guess I will have to count using length. It's not the end of the world. I was just checking :D.

The traditional way that I would find the size of a file (apart from an existing function that would do it for me) is to:

1. Move “zero bytes away from here” on a filehandle to obtain my present location in bytes. (“n”)
2. Move “zero bytes back from end-of-file” to obtain the file’s present length.
3. Move “n bytes away from start-of-file” to go back to where I was.

The trouble with this, in the particular case of STDIN, is that such a filestream is usually a stream, and therefore not “positionable.”   If it is a pipe (and you don’t know that until runtime), it has no set “size” at all.   You just pump from it until the well eventually runs dry.