Front page | perl.perl5.porters |
Postings from February 2013
Re: perlopentut modernization
Thread Previous
|
Thread Next
From:
Alexander Hartmaier
Date:
February 14, 2013 08:55
Subject:
Re: perlopentut modernization
Message ID:
CAB49QrauHEXdBmwepDtYeMU6wksrBgx6PY96S=cHZtuKx_XB8w@mail.gmail.com
On Thu, Feb 14, 2013 at 6:29 AM, demerphq <demerphq@gmail.com> wrote:
> 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.
>
Yes, I didn't know that there is a difference and also didn't find it out
from reading the docs.
>
> > "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.
>
I changed all occurrences of or in the doc to be the same and also talked
to people on #p5p which of the two I should use. As far as I remember the
outcome was to use the low-precedence form for exactly this reason.
Furthermore I did change all examples to have the or die on a second,
indented line. I only left the first section of examples untouched, those
where changed by Dave so now all are like that. Which branch/commit did you
review?
>
> 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.
>
This is also something I've asked on #p5p and the agreement was to include
parens to prevent possible parser edge cases.
This matches my personal preference of using parens even if not absolutely
needed to increase readability and avoid precedence errors.
>
> 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.
>
I'm agreeing with you, I do both in all my code. I didn't change it because
I guessed not everybody likes it and that the current form of error
messages was the way it is for a reason.
>
> 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