Command line arguments??

[rantingrick]

I am currently having "fun" with command line arguments in a windows
environment. If i get a path that has spaces anywhere in it my script
gets the wrong arguments from sys.argv. You guy's probably know what i
am talking about. Heres and example.

'C:\\Python26\\Python.exe C:\\echo.py C:\\New Folder\\text.txt'

inside my script i get the following result from sys.argv

['C:\\Python26\\Python.exe', 'C:\\echo.py', 'C:\\New', 'Folder\
\text.txt']

So i've got a few options
1. have people replace every space in all file paths system wide
(sucks)
2. Create a custom parser, join the argv list, parse it...(maybe)
3. please tell me there is an option 3? (hopefully)

 

[Benjamin Kaplan]

I am currently having "fun" with command line arguments in a windows
environment. If i get a path that has spaces anywhere in it my script
gets the wrong arguments from sys.argv. You guy's probably know what i
am talking about. Heres and example.

'C:\\Python26\\Python.exe C:\\echo.py C:\\New Folder\\text.txt'

inside my script i get the following result from sys.argv

['C:\\Python26\\Python.exe', 'C:\\echo.py', 'C:\\New', 'Folder\
\text.txt']

So i've got a few options
 1. have people replace every space in all file paths system wide
(sucks)
 2. Create a custom parser, join the argv list, parse it...(maybe)
 3. please tell me there is an option 3? (hopefully)

The same thing you have to do with every command line program - wrap
it in quotes.
C:\\Python26\\python.exe C:\\echo.py "C:\\New Folder\\text.txt"

 

[rantingrick]

We've been living with this pain ever since windowed GUIs encouraged users  
to put spaces in their file names (Apple, I'm looking at you!).  
Fundamentally, if people want the pretty they have to live with the  
consequences.

Thanks everyone , problem solved!

 

[Nobody]

Quote the filenames or escape the spaces:

C:\Python26\Python.exe C:\echo.py "C:\New Folder\text.txt"

We've been living with this pain ever since windowed GUIs encouraged users
to put spaces in their file names (Apple, I'm looking at you!).
Fundamentally, if people want the pretty they have to live with the
consequences.

We've been living with much worse ever since Unix allowed users to put
not only spaces but even newlines in their filenames.

At least, those of us who prefer "works" over "sort of works most of the
time" have.

Then Python 3 decides to pretend that argv and environ and stdin contain
text rather than bytes, thereby ensuring that Python 2 will outlive Python
3.

 

[Gerry]

We've been living with much worse ever since Unix allowed users to put
not only spaces but even newlines in their filenames.

At least, those of us who prefer "works" over "sort of works most of the
time" have.

Then Python 3 decides to pretend that argv and environ and stdin contain
text rather than bytes, thereby ensuring that Python 2 will outlive Python
3.

How about this:

lastarg = " ".join(sys.argv[2:])

 

[Nobody]

How about this:

lastarg = " ".join(sys.argv[2:])

What about it?

IOW, why would you want to do that?

 

[Dave Angel]

How about this:

lastarg = " ".join(sys.argv[2:])

What about it?

IOW, why would you want to do that?

Like many tricks, it'd work if several conditions applied:

1) there's exactly two arguments expected on the command line
2) you know that the second argument may have one or more spaces in it,
but not consecutively, and no quotes immediately after any such space.
3) you don't mind fooling the user by making *most* cases work, so he's
not trained for the general case.

This one reminds me of CreateProcess() in Windows, which parses for the
program by looking for each space, and seeing if there's an appropriate
EXE file there. So if you have stuff installed in "C:\Program Files\My
Dir\yyy" directory, you can be blindsided by someone creating a program
in the root called c:\program.exe, or "c:\Program Files\My.exe"
CreateProcess() keeps trying till one works, instead of immediately
giving a diagnosable error.

That was my (correct) diagnosis of an actual customer problem, referred
to me by tech support. Customer described error message, and I studied
what could cause it. Called back and asked whether there was a
program.exe in the root directory. Told him to (temporarily) remove it.
Problem vanished. Customer astounded how we could know about its
existence. Of course it was really a bug in one of the products at my
company, where quotes weren't used. Not usually needed, because of this
"flexibility" on the part of CreateProcess()

DaveA

 

[greg]

We've been living with this pain ever since windowed GUIs encouraged
users to put spaces in their file names (Apple, I'm looking at you!).

It's not really Apple's fault. There was no problem with
spaces in filenames in the classic MacOS environment,
because there was no textual command language (at least
not one that people used in day-to-day work).

There's a slight problem sometimes in MacOSX when you
use the shell, but at least unix passes args to a program
as separate strings, so as long as you exec() something
directly and avoid the shell, you're safe.

Windows, on the other hand, passes all the args as a
single string, whether a shell is involved or not
(due to blindly adopting CP/M's argument passing
mechanism into MSDOS).

Microsoft screwed up by trying to partially implement
Apple's ideas on top of a system that wasn't engineered to
cope with them.

 

[Nobody]

You'll notice I said "encouraged", not "allowed".

You'll notice I said "allowed", not "encouraged".

Code which can't handle spaces in filenames is broken from the outset; it
doesn't suddenly break the first time that someone passes a filename
containing spaces.

I have a suspicion that Win95 put spaces in two of the most important
directory names specifically to force developers to deal with this.

Nowadays, any Windows program which cannot handle spaces in pathnames is
usually a port of a Unix program (and a shoddy one at that).

OTOH, I'm surprised at how much Windows software still cannot handle
filenames outside of the system codepage (i.e. it's using the
byte-oriented API rather than the Unicode API).