In particular, the examples given in the very perlintro(1) manpage that you reference indeed recommend that style right at the front:
Considering that those are the only sorts of I/O examples that you’ll find in the perlintro(1) manpage, I don’t understand the misconnect between recommending against it and recommending for it.Files and I/O
You can open a file for input or output using the open function. It’s documented in extravagant detail in perlfunc and perlopentut, but in short:...et cetera...open(INFILE, "input.txt") or die "Can't open input.txt: $!"; open(OUTFILE, ">output.txt") or die "Can't open output.txt: $!"; open(LOGFILE, ">>my.log") or die "Can't open logfile: $!";
The only thing really “wrong” with those cited examples out of perlintro(1) in a modern text-processing environment is that they neglect the encoding, which can be remedied with a use open pragma — amongst several other ways, such as the newish PERLIO envariable or via post-facto binmoding as it has always been done.
People have been programming Perl this way for more than two decades now. There is no need to go all PC-police on people for code that works perfectly well for their purposes. There are millions of lines of working Perl code out there that work in just this way.
Yes, there are times when more dedicated, non-shell-like constructs are more suitable.
But this is not one of them.
In reply to Re^2: unquoted string error??!!
by tchrist
in thread unquoted string error??!!
by aji
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |