python 2.7.12 on Linux behaving differently than on Windows
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Tue Dec 6 00:17:32 EST 2016
On Tuesday 06 December 2016 14:57, Michael Torrie wrote:
> "-" is perfectly valid in a filename on Linux. Getting apps to recognize
> it as a filename and not an argument is another story. Convention is to
> allow an argument "--" that tells the arg parser that everything
> following that is not an argument but a parameter which may or may not
> be a file
Another useful trick is to use a relative or absolute path to refer to a
filename that begins with a dash:
./-foo
is unambiguously the file called "-foo" in the current directory, not the -f
option.
This doesn't help when it comes to arguments which don't refer to filenames,
hence the -- tradition.
> --BartC seems stuck on this point, but parameters could be
> anything from urls to string messages to numbers. They don't have to be
> files and they in fact could begin with "/" if the program allowed it.
Indeed.
The Unix shells are optimized for a particular use-case: system administration.
For that, the globbing conventions etc are pretty close to optimal, but of
course they're not the only conventions possible. Unix shells recognise this
and allow you to escape metacharacters, and even turn off globbing altogether.
Another alternative would be to eschew the use of a single command line and
build your own scripting mini-language with its own conventions. That's
especially useful if your primary use-case is to invoke your program many
times, rather than just once.
E.g. the Postgresql interactive interpreter allows you to run multiple queries
interactively without worrying about the shell:
https://www.postgresql.org/docs/current/static/tutorial-accessdb.html
There's no doubt that Bart has a legitimate use-case: he wants his input to be
fed directly to his program with no pre-processing. (At least, no globbing: if
he has given his opinion on environment variable expansion, I missed it.) Fair
enough. Its easy to escape wildcards, but perhaps there should be an easy way
to disable *all* pre-processing for a single command.
The fact that there is no easy, well-known way to do so indicates just how
unusual Bart's use-case is. Linux and Unix sys admins are really good at
scratching their own itches, and believe me, if there was widespread wish to
disable pre-processing for a single command, after 40-odd years of Unix the
majority of shells would support it.
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
More information about the Python-list
mailing list