The print operator takes a list of values and sends each item (as a string, of course) to standard output in turn, one after another. It doesn't add any extra characters before, after, or in between the items;[152] if you want spaces between items and a newline at the end, you have to say so:
[152]Well, it doesn't add anything extra by default, but this default (like so many others in Perl) may be changed. Changing these defaults will likely confuse your maintenance programmer, though, so avoid doing so except in small, quick-and-dirty programs, or (rarely) in a small section of a normal program. See the perlvarmanpage to learn about changing the defaults.
$name = "Larry Wall"; print "Hello there, $name, did you know that 3+4 is ", 3+4, "?\n";
Of course, that means that there's a difference between printing an array and interpolating an array:
print @array; # print a list of items print "@array"; # print a string (containing an interpolated array)
That first print statement will print a list of items, one after another, with no spaces in between. The second one will print exactly one item, which is the string you get by interpolating @array into the empty string -- that is, it prints the contents of @array, separated by spaces.[153] So, if @array holds qw/ fred barney betty /,[154] the first one prints fredbarneybetty, while the second prints fred barney betty separated by spaces.
[153]Yes, the spaces are another default; see the perlvarmanpage again.
[154]You know that we mean a three-element list here, right? This is just Perl notation.
But before you decide to always use the second form, imagine that @array is a list of unchomped lines of input. That is, imagine that each of its strings has a trailing newline character. Now, the first print statement prints fred, barney, and betty on three separate lines. But the second one prints this:
fred barney betty
Do you see where the spaces come from? Perl is interpolating an array, so it puts spaces between the elements. So, we get the first element of the array (fred and a newline character), then a space, then the next element of the array (barney and a newline character), then a space, then the last element of the array (betty and a newline character). The result is that the lines seem to have become indented, except for the first one. Every week or two, a message appears on the newsgroup comp.lang.perl.misc with a subject line something like:
Perl indents everything after the first line
Without even reading the message, we can immediately see that the program used double quotes around an array containing unchomped strings. "Did you perhaps put an array of unchomped strings inside double quotes?" we ask, and the answer is always yes.
Generally, if your strings contain newlines, you simply want to print them, after all:
print @array;
But if they don't contain newlines, you'll generally want to add one at the end:
print "@array\n";
So, if you're using the quote marks, you'll be (generally) adding the \n at the end of the string anyway; this should help you to remember which is which.
It's normal for your program's output to be buffered . That is, instead of sending out every little bit of output at once, it'll be saved until there's enough to bother with. That's because if (for example) the output were going to be saved on disk, it would be (relatively) slow and inefficient to spin the disk every time that one or two characters need to be added to the file. Generally, then, the output will go into a buffer that is flushed (that is, actually written to disk, or wherever) only when the buffer gets full, or when the output is otherwise finished (such as at the end of runtime). Usually, that's what you want.
But if you (or a program) may be waiting impatiently for the output, you may wish to take that performance hit and flush the output buffer each time you print. See the Perl manpages for more information on controlling buffering in that case.
Since print is looking for a list of strings to print, its arguments are evaluated in list context. Since the diamond operator (as a special kind of line-input operator) will return a list of lines in a list context, these can work well together:
print <>; # source code for 'cat' print sort <>; # source code for 'sort'
Well, to be fair, the standard Unix commands cat and sort do have some additional functionality that these replacements lack. But you can't beat them for the price! You can now re-implement all of your standard Unix utilities in Perl, and painlessly port them to any machine that has Perl, whether that machine is running Unix or not. And you can be sure that the programs on every different type of machine will nevertheless have the same behavior.[155]
[155]In fact, there was even an endeavor started, called the PPT (Perl Power Tools) project, whose goal is to implement all of the classic Unix utilities in Perl. They actually completed nearly all the utilities (and most of the games!), but got bogged down when they got to reimplementing the shell. The PPT project has been helpful because it has made these standard utilities available on many non-Unix machines.
What might not be obvious is that print has optional parentheses, which can sometimes cause confusion. Remember the rule that parentheses in Perl may always be omitted, except when doing so would change the meaning of a statement. So, here are two ways to print the same thing:
print("Hello, world!\n"); print "Hello, world!\n";
So far, so good. But another rule in Perl is that if the invocation of print looks like a function call, then it is a function call. It's a simple rule, but what does it mean for something to look like a function call?
In a function call, there's a function name immediately[156] followed by parentheses around the function's arguments, like this:
[156]We say "immediately" here because Perl won't permit a newline character between the function name and the opening parenthesis in this kind of function call. If there is a newline there, Perl sees your code as making a list operator, rather than a function call. This is the kind of piddling technical detail that we mention only for completeness. If you're terminally curious, see the full story in the manpages.
print (2+3);
That looks like a function call, so it is a function call. It prints 5, but then it returns a value like any other function. The return value of print is a true or false value, indicating the success of the print. It nearly always succeeds, unless you get some I/O error, so the $result in the following statement will normally be 1:
$result = print("hello world!\n");
But what if you used the result in some other way? Let's suppose you decide to multiply the return value times four:
print (2+3)*4; # Oops!
When Perl sees this line of code, it prints 5, just as you asked. Then it takes the return value from print, which is 1, and multiplies that times 4. It then throws away the product, wondering why you didn't tell it to do something else with it. And at this point, someone looking over your shoulder says, "Hey, Perl can't do math! That should have printed 20, rather than 5!"
This is the problem with allowing the parentheses to be optional; sometimes we humans forget where the parentheses really belong. When there are no parentheses, print is a list operator, printing all of the items in the following list; that's generally what you'd expect. But when the first thing after print is a left parenthesis, print is a function call, and it will print only what's found inside the parentheses. Since that line had parentheses, it's the same to Perl as if you'd said this:
( print(2+3) ) * 4; # Oops!
Fortunately, Perl itself can almost always help you with this, if you ask for warnings -- so use -w, at least during program development and debugging.
Actually, this rule -- "If it looks like a function call, it is a function call" -- applies to all list functions[157] in Perl, not just to print. It's just that you're most likely to notice it with print. If print (or another function name) is followed by an open parenthesis, make sure that the corresponding close parenthesis comes after all of the arguments to that function.
[157]Functions that take zero or one arguments don't suffer from this problem.
Copyright © 2002 O'Reilly & Associates. All rights reserved.