I like having the error messages following the resource in question and a colon; all the rest of the Unix toolkit tends to follow that philosophy, and I don't see any value in bucking the trend.
By force of habit I write my error messages out in longhand, in a vague attempt to make things clearer:
open IN, '<', $file or die "Cannot open $file for input: $!\n"; open OUT, '>>', $file or die "Cannot open $file for append: $!\n"; open P, '|', $cmd or die "Cannot open input pipe from $cmd: $!\n";
I'm in two minds about your idea. If a non-programmer were to read me the message (or a programmer without shell-redirection experience, which is pretty much the same thing) they might omit pronouncing < altogether or describe it uselessly (e.g. "arrow"). That's why I like wordy error messages.
On the other hand, if I were to adopt this idea, I wouid be tempted to push things to extremes, and factor out the redirection into a variable:
my $whence = '<'; open my $fh, $whence, $file or die "$whence $!:$file";
... on the principle that if you change it to <+ or something else you only have to do that in one place. But I'll be the first to say that that's getting silly.
Colour me unconvinced. But I think the 3-arg open is the thing. For all of you who have tuned in recently, here's the canonical thread on the subject: Two-arg open() considered dangerous.
In reply to Re: Perl Style: About error messges opening files
by grinder
in thread Perl Style: About error messges opening files
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |