develooper 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
Glenn Linderman
July 28, 2008 21:48
Re: Creative and *routine* use of so-called "magic" ARGV (was [perl#2783] Security of ARGV using 2-argument open)
Message ID:
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 --
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About