Front page | perl.perl5.porters |
Postings from February 2013
Re: perlopentut modernization
Thread Previous
|
Thread Next
From:
demerphq
Date:
February 14, 2013 05:29
Subject:
Re: perlopentut modernization
Message ID:
CANgJU+Wkr0-NrTagbNnd_+7eaAA-6Ay1sOWOA5R-20mwgmYapw@mail.gmail.com
On 14 February 2013 03:51, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> * Alexander Hartmaier <alex.hartmaier@gmail.com> [2013-01-19T06:54:56]
>> ...
>
> Sorry for the delay. I'm finally reviewing!
>
> This is a sort of random collection of reactions. Sorry for any confusion to
> my thoughts.
>
> special variable C<$!> -- should link to perlvar, since $! is a bit weird
>
> You write:
No no. Alex didnt write that. Its been in perlopentut for a long time.
This from 5.12.2:
The other important thing to notice is that, just as in the
shell, any whitespace before or after the filename is ignored. This
is good,
because you wouldn't want these to do different things:
open INFO, "<datafile"
open INFO, "< datafile"
open INFO, "< datafile"
Ignoring surrounding whitespace also helps for when you read a
filename in from a different file, and forget to trim it before
opening:
$filename = <INFO>; # oops, \n still there
open(EXTRA, "< $filename") || die "can't open $filename: $!";
This is not a bug, but a feature. Because "open" mimics the
shell in its style of using redirection arrows to specify how to open
the
file, it also does so with respect to extra whitespace around
the filename itself as well. For accessing files with naughty names,
see
"Dispelling the Dweomer".
There is also a 3-argument version of "open", which lets you
put the special redirection characters into their own argument:
open( INFO, ">", $datafile ) || die "Can't create $datafile: $!";
In this case, the filename to open is the actual string in
$datafile, so you don't have to worry about $datafile containing
characters
that might influence the open mode, or whitespace at the
beginning of the filename that would be absorbed in the 2-argument
version.
Also, any reduction of unnecessary string interpolation is a good thing.
The problem is that Alexander overlooked the subtly in the docs that
the comment about whitespace affects only the two argument form.
> "The other important thing to notice is that, just as in the shell, any
> whitespace before or after the filename is ignored."
>
> But:
>
> ~$ perl -E "open( my \$fh, '>', 'foo '); print {\$fh} 'hi'; close \$fh; say
> -e 'foo ' ? 1 : 0; say -e 'foo' ? 1 : 0"
> 1
> 0
>
> ...which indicates that you are wrong. I believe this is only true of two-arg
> open. I am concerned by this inaccuracy, as it may foretell more to come on
> subtler points.
>
> For example, again:
>
> ~$ head -1 dupes
> use 5.16.0;
> ~$ perl -E 'my $x = "dupes\n"; open my $fh, "<", $x or die "cannot open $x:
> $!"'
> cannot open dupes
> : No such file or directory at -e line 1.
>
> Or:
>
> ~$ cat files.txt
> dupes
> ~$ perl -E 'while (<>) { open my $fh, "<", $_ or die "cannot open $_: $!";
> print <$fh>; }' files.txt
> cannot open dupes
> : No such file or directory at -e line 1, <> line 1.
>
> I think at this point I'm going to stop. The whole document needs to be
> checked for accuracy of these kind of claims before it is possible to even
> consider merging.
I think this is a bit too strong. As far as I can tell this is the
only real error in documentation that Alexander made, and if you look
closely at the patch was almost definitely the result of an overly
hasty restructuring of the first section of the doc.
Personally what I would like to see Alexander do to improve this patch
is to fix the examples like this:
open(my $fh, "<", $filename) || die "can't open $filename: $!";
so they look like this:
open my $fh, "<", $filename
or die "Can't open '$filename' for read: $!";
IOW, so they use the low precedence "or" and not the high precedence
|| (which dictates the use of parens on the open), and then eliminate
the parens on the open statement, quote the filename in the error
message, and show the open mode in the error message.
In practice I almost _never_ see parens on an open statement. And if
parens are going to be used they should be used on BOTH the open and
the die so that the form is consistent. But I would really prefer that
the standard idiom be used and see the pares omitted from both.
Making sure the errors message shows the mode, and quotes the filename
is IMO invaluable for tracking down issues (unquoted filenames become
problematic when for instance the filename being opened is called "\n"
or "" or " " or whatnot), and knowing if you failed to write or read a
file can make a big difference to debugging.
But as for accuracy I think the only real issue Alexander needs to
address is the bit about whitespace being applicable only to two arg
open.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next