demerphq wrote:
On 28 February 2013 21:12, André Warnier <a...@ice-sa.com> wrote:
I am ranting, and I know it. But the basic fact is that " ", in 99% of
programming languages
I doubt it, considering all the major languages I know of use a "," to
separate arguments.
And if you are in a programming language then the filename will be
stored in a variable, so you generally wont care if it contains
spaces, or whatever.
and OS shells
Here it is maybe true.
is a meta-character that normally acts
as a separator between arguments, keywords, parameters, whatever. So
electing to allow it in paths and filenames was a bad decision, which has
cost so far millions of unproductive hours to be spent, and will cost many
more millions before a reasonable parade is found.
If you accept arbitrary sets of filenames and expect to feed them as
arguments to something like a shell without managing issues like them
having spaces in them then you are opening yourself up to way worse
issues than them having spaces in them.
Whats to stop them giving you a filename that is actually a command,
or a redirect, or whatever?
You do not have to convince us, I think that we all know this already. You may want to
read http://perldoc.perl.org/perlsec.html#SECURITY-MECHANISMS-AND-CONCERNS if you haven't
yet done so. It may give you some additional ideas about things to watch for.
Or take your latest perl program, and remove all spaces from it, just for a
laugh.
But I believe that you are missing the point of this whole disgression entirely, and you
may want to re-read it from the beginning, and take it for what it is. LOL.
