Front page | perl.perl5.porters |
Postings from July 2008
Re: Creative and *routine* use of so-called "magic" ARGV (was [perl#2783] Security of ARGV using 2-argument open)
Thread Previous
From:
Glenn Linderman
Date:
July 28, 2008 21:48
Subject:
Re: Creative and *routine* use of so-called "magic" ARGV (was [perl#2783] Security of ARGV using 2-argument open)
Message ID:
488EA11B.3020907@NevCal.com
What is troubling is when conciseness loses correctness.
I note a common thread in all your examples: that the magic is added
programmatically, rather than being (expected to be) typed on the
command line.
I notice that none of your examples would work if passed a file
containing leading spaces or redirection characters; I'm quite sure you
don't use such things.
So it seems that your vision of Perl is a Perl in which you can write
beautiful code that works well in your controlled and protected
environment, but which contains traps for the unwary who actually write
scripts for distribution to people who are less controlled, and don't
understand as well how to protect themselves.
Seems to me that it would be better, rather than adding magic to the
filename, to add the magic in a side array, and use the side array as
the mode argument to a three arg open call. This would allow all files
to be appropriately processed, without restriction on their leading and
trailing characters.
The code gets slightly more complex, but more robust in handling of
names you forbid to enter your environment, if @ARGV were transformed into
@ARGV = map {['<', $_]} @ARGV;
Then the first of your examples must be recoded as:
@ARGV = map { $_[1] =~ /^\.(gz|Z)$/
? ['-|', qq{gzip -dc "$_[1]"}]
: $_
} @ARGV;
and while(<>) can't be used directly either, in its present form. But
while(<>) could be enhanced to handle lists of 2-entry lists, and
perform three arg opens using the contents of each sublist in turn.
Allowing the user to specify such bundled open modes on the command line
is no problem: just have program option that takes pairs of mode,
filename, for the cognoscenti, and defaults to a list of files or glob
for the ignorant and uninformed. glob doesn't permit specification of
bundled open modes on the command line anyway.
On approximately 7/28/2008 8:35 PM, came the following characters from
the keyboard of Tom Christiansen:
Lots of nice examples elided.
> Breaking people's programs is a good way to drive them away, and
> that is never a good thing.
Having a feature that does surprising things when given surprising
filenames is a way to drive them away also.
> The thought of updating triple-digit numbers of my happily running scripts
> that certain individuals would just as well see broken is really beyond
> the conscionable--or its promulgators, conscientiousness.
You are welcome to keep using Perl 5.8 or 5.10 for each of your "works
only in your protected environment" scripts, until such a script needs a
feature from the newer Perl. To use the newer feature, you would have
to recode anyway, so another minor update to better handle @ARGV
processing is not onerous.
> The only thing I long for right now is Rafael's currently nonworking
> inspiration of "<:utf8 someutf8file" or "<:crlf winfile.txt" and the like.
> I sure would like that a lot, because it's a bit of a pain otherwise.
> Running `file` on the input filename to figure out its flavor for
> processing isn't always as nice as letting the user specify it directly and
> individually. DWIM may be one thing, but DWIS should always overrule it.
Yes, some syntax along that line would be nice. You've helped convince
me that it should be more along the lines of:
script --mf '<:utf8' ' some utf8 file' '<:crlf' '>winfile.txt'
instead of bundling the mode with the file name. Just as 3-arg open is
less surprising and more functional than 2-arg open, so are separate
parameters on the command line less surprising and more functional.
> I wonder whether we shouldn't have some ARGV:: modules or dwimmer::
> pragmata that help run, or not run, these convenient transforms on @ARGV,
> the way we already have for Getopt::this_and_that, which all update @ARGV
> per expectation. The anaylsayers can have their "no dwimmer::ARGV;" if
> they want thent to dispell the dweomer, and then blissfully leave the rest
> of us--and our code!--in peace.
Those could be extremely useful to the less inspired than yourself. I
was heading that way with the "use magic_open" pragma. A collection of
such snippets could be gathered within that to be called forth with a
single extra parameter.
A function to convert pairs of mode and filename arguments to a list of
doublets, and a function to convert a list of names to a list of
doublets using mode '<', would be handy too.
> Yes, I know I yet owe a cogent explanation detailing why the sound and fury
> of the alarmicists is both uncalled for and unrealistic. Even worse,
> coddling to their demands through appeasement may even seduce them into a
> dangerously unmerited sense of complacency, an illusion of false security
> where none such exists. I *do* have that argument ready for elaboration
> and exposition, but while it is shorter than this missive, that's really
> quite enough for tonight.
Indeed; I hope that it includes an explanation for why such a commonly
needed function as open should require such long explanation in the
documentation, and why users should be required to learn what characters
not to use in their filenames if they expect their perl scripts to work
as documented (since it is the perception that most scripts that use
"while(<>)" are documented to take a list of filenames, not a list of
filenames that don't start or end with spaces or redirection characters.
> Good night.
Yes, I hope you have a restful sleep.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
Thread Previous