python 2.7.12 on Linux behaving differently than on Windows

[Steven D'Aprano]

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