Re: Command line arguments??
On Tue, 17 Nov 2009 23:57:55 +, Rhodri James wrote: 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. 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). -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Mon, 16 Nov 2009 23:30:09 +, Rhodri James wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Nov 17, 2:26 pm, Nobody nob...@nowhere.com wrote: On Mon, 16 Nov 2009 23:30:09 +, Rhodri James wrote: 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. How about this: lastarg = .join(sys.argv[2:]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Tue, 17 Nov 2009 11:47:46 -0800, Gerry wrote: How about this: lastarg = .join(sys.argv[2:]) What about it? IOW, why would you want to do that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Tue, 17 Nov 2009 19:26:46 -, Nobody nob...@nowhere.com wrote: On Mon, 16 Nov 2009 23:30:09 +, Rhodri James wrote: 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. You'll notice I said encouraged, not allowed. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
Nobody wrote: On Tue, 17 Nov 2009 11:47:46 -0800, Gerry wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
Rhodri James wrote: 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. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Mon, Nov 16, 2009 at 6:18 PM, rantingrick rantingr...@gmail.com wrote: 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) -- http://mail.python.org/mailman/listinfo/python-list 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Mon, 16 Nov 2009 23:18:23 -, rantingrick rantingr...@gmail.com wrote: 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) 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. -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments??
On Nov 16, 5:30 pm, Rhodri James rho...@wildebst.demon.co.uk wrote: 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! -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
On Mar 4, 8:38 am, Mike Walker [EMAIL PROTECTED] wrote: If you run a python file, ie. just double clicking it the only argument you will have will be the filename of the script. If you create a shortcut to the script and in the target box add your arguments (if you have quotation marks place them after not inside) you will see your arguments. fwiw you answered yourself in the third paragraph. As I mentioned I am working from the command line, not clicking on the icon. The only difference between it working and not is the python prefix, which is why I was thinking this is some sort of file association problem. I probably wasn't as clear as I could have been in the third paragraph. argtest.py arg1 arg2 arg3 - Does not work only get sys.argv[0] python argtest.py arg1 arg2 arg3 - Works That seems rather wierd, just running argtest.py arg1 arg2 arg3 I get the correct output, Python 2.5.1 from python.org but running on XP though. Potentially an issue with Vista... ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
Chris wrote: On Mar 4, 8:38 am, Mike Walker [EMAIL PROTECTED] wrote: If you run a python file, ie. just double clicking it the only argument you will have will be the filename of the script. If you create a shortcut to the script and in the target box add your arguments (if you have quotation marks place them after not inside) you will see your arguments. fwiw you answered yourself in the third paragraph. As I mentioned I am working from the command line, not clicking on the icon. The only difference between it working and not is the python prefix, which is why I was thinking this is some sort of file association problem. I probably wasn't as clear as I could have been in the third paragraph. argtest.py arg1 arg2 arg3 - Does not work only get sys.argv[0] python argtest.py arg1 arg2 arg3 - Works That seems rather wierd, just running argtest.py arg1 arg2 arg3 I get the correct output, Python 2.5.1 from python.org but running on XP though. Potentially an issue with Vista... ? Strange as it may seem, there have been issues with other Windows command processors, and one in particular (I can never remember which one) messes up IO redirection when the pathext mechanism is used to select the executable that processes the Python file. So I would tend to suspect yet another variation on this familiar theme given your testing results. But I don't intend to tangle with Vaster any sooner than I must. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
If you run a python file, ie. just double clicking it the only argument you will have will be the filename of the script. If you create a shortcut to the script and in the target box add your arguments (if you have quotation marks place them after not inside) you will see your arguments. fwiw you answered yourself in the third paragraph. As I mentioned I am working from the command line, not clicking on the icon. The only difference between it working and not is the python prefix, which is why I was thinking this is some sort of file association problem. I probably wasn't as clear as I could have been in the third paragraph. argtest.py arg1 arg2 arg3 - Does not work only get sys.argv[0] python argtest.py arg1 arg2 arg3 - Works -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
On Mar 4, 7:12 am, Mike Walker [EMAIL PROTECTED] wrote: I am having some problems with command line arguments in Windows. The same code under Linux works fine. In Windows I only get one argument no matter how many arguments are passed on the command line. I think there is some problem with the way the .py files are associated causing this. I'm just not sure how to go about fixing it. If I call the python script using the command python argtest.py arg1 arg2 etc... this also works fine. Its only when run the program using the name only that the problem occurs. Does anyone have any ideas what the problem is here and hopefully how to go about fixing it? import sys if __name__ == __main__: for arg in sys.argv: print arg If you run a python file, ie. just double clicking it the only argument you will have will be the filename of the script. If you create a shortcut to the script and in the target box add your arguments (if you have quotation marks place them after not inside) you will see your arguments. fwiw you answered yourself in the third paragraph. -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
Mike Walker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If you run a python file, ie. just double clicking it the only argument you will have will be the filename of the script. If you create a shortcut to the script and in the target box add your arguments (if you have quotation marks place them after not inside) you will see your arguments. fwiw you answered yourself in the third paragraph. As I mentioned I am working from the command line, not clicking on the icon. The only difference between it working and not is the python prefix, which is why I was thinking this is some sort of file association problem. I probably wasn't as clear as I could have been in the third paragraph. argtest.py arg1 arg2 arg3 - Does not work only get sys.argv[0] python argtest.py arg1 arg2 arg3 - Works From the command line, the 'ftype' and 'assoc' commands can be used view how an extension is handled: C:\assoc .py .py=Python.File C:\ftype Python.File Python.File=C:\Python25\python.exe %1 %* My guess is your command line looks something like this: Python.File=C:\Python25\python.exe %1 The script name is being passed, but not the rest of the arguments. I vaguely remember seeing this on an older version one of ActiveState's ActivePython installers. What version of Python are you running? --Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments in Windows
Mark Tolonen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From the command line, the 'ftype' and 'assoc' commands can be used view how an extension is handled: C:\assoc .py .py=Python.File C:\ftype Python.File Python.File=C:\Python25\python.exe %1 %* My guess is your command line looks something like this: Python.File=C:\Python25\python.exe %1 The script name is being passed, but not the rest of the arguments. I vaguely remember seeing this on an older version one of ActiveState's ActivePython installers. What version of Python are you running? --Mark Here is the output from the commands you listed which looks right to me. C:\assoc .py .py=Python.File C:\ftype python.file python.file=C:\Python25\python.exe %1 %* I am using Python 2.5.2 from http://www.python.org/ running on Windows Vista. Would ActiveState's version be a better choice here? ~Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: command-line arguments in IDLE
it does have one in activepython Thanks and Regards, Ginger - Original Message - From: Russ P. [EMAIL PROTECTED] To: python-list@python.org Sent: Wednesday, November 07, 2007 8:56 AM Subject: command-line arguments in IDLE Is it possible to pass command-line arguments when running a program in IDLE? The Run menu does not seem to provide that option. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: command-line arguments in IDLE
On Nov 7, 6:27 am, Russ P. [EMAIL PROTECTED] wrote: Is it possible to pass command-line arguments when running a program in IDLE? The Run menu does not seem to provide that option. Thanks. Can't you just fake the command line args by setting sys.argv? This isn't too sophisticated, but it appears to work: import sys try: __file__ except: sys.argv = ['scriptname.py', 'this','is','a','test','within','idle'] for arg in sys.argv: print arg Running from within IDLE: scriptname.py this is a test within idle Running from the command prompt: C:\Python24python.exe mystuff/argtest.py this is yet another test mystuff/argtest.py this is yet another test C:\Python24 HTH, Don -- http://mail.python.org/mailman/listinfo/python-list
Re: command-line arguments in IDLE
Russ P. wrote: Is it possible to pass command-line arguments when running a program in IDLE? The Run menu does not seem to provide that option. Thanks. thunderfoot's workaround should work well, but requires changing the script. If you want IDLE environment, but don't mind running IDLE from the command line, you can do the following: idle.py -r scriptname.py this is a test The script will run inside IDLE's shell with sys.argv set as you would expect. The output will go to IDLE's shell, and once the script is done running the shell will become interactive. (idle.py is usually found in your Python installation under Lib/ idlelib/) - Tal Einat reduce(lambda m,x:[m[i]+s[-1] for i,s in enumerate(sorted(m))], [[chr(154-ord(c)) for c in '.-,l.Z95193+179-']]*18)[3] -- http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments using subprocess
En Wed, 14 Mar 2007 16:51:04 -0300, Jim [EMAIL PROTECTED] escribió: I'm trying to use subprocess to drive a Perl script. I'm having some trouble getting it to spot the command line arguments. Basically, if I call subprocess(args).wait() where args has a second item, I can't convince the Perl script to see it. Below is a pretty small example. If someone could get me unstuck, I'd appreciate it. (Python 2.4.4c1, if that helps.) args=['/home/ftpmaint/test.pl','a'] p=subprocess.Popen(args,shell=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE,cwd=os.getcwd()) Try with 'perl' explicitely as first argument, or without shell=True; if cwd is the current dir, there is no need to include it. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments on Vista
Thanks for the answers; that was the problem exactly. --JMike Duncan Booth wrote: It sounds like the registry entry for running Python files is messed up. Can you go to a command line and see what the command 'ftype Python.File' displays? (Assuming that command lines and ftype still work on Vista) The output should be: Python.File=C:\Python25\python.exe %1 %* but if it only says: Python.File=C:\Python25\python.exe %1 then you would get the behaviour you observed (on any version of Windows, not just Vista). -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments on Vista
Duncan Booth [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] It sounds like the registry entry for running Python files is messed up. Can you go to a command line and see what the command 'ftype Python.File' displays? (Assuming that command lines and ftype still work on Vista) The output should be: Python.File=C:\Python25\python.exe %1 %* but if it only says: Python.File=C:\Python25\python.exe %1 then you would get the behaviour you observed (on any version of Windows, not just Vista). That would happen if the association was not made by the Python installer, but by the user selecting Python.exe the first time he tried to execute a Python script by double-clicking on it. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments on Vista
By the way, note that if I say (on Vista) python printargs.py booga -a wooga I get the desired output: there are 4 args arg: printargs.py arg: booga arg: -a arg: wooga So the quesiton still stands, what's up with that? Thanks, --JMike -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments on Vista
Some further information: perl seems to do the same thing (losing arguments). We think it may have something to do with file association. Any ideas anyone? --JMike -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments on Vista
[EMAIL PROTECTED] wrote: But on Windows Vista, when I run that command, I get there are 1 args arg: printargs.py What's up with that? It sounds like the registry entry for running Python files is messed up. Can you go to a command line and see what the command 'ftype Python.File' displays? (Assuming that command lines and ftype still work on Vista) The output should be: Python.File=C:\Python25\python.exe %1 %* but if it only says: Python.File=C:\Python25\python.exe %1 then you would get the behaviour you observed (on any version of Windows, not just Vista). -- http://mail.python.org/mailman/listinfo/python-list
RE: Command line arguments question (Windows XP)
[ezd] | # u.py | import sys | print 'args',sys.argv | | in Command Prompt window, with 2 command lines on 2 PCs: | | # Case (1L): | C:\tmp u.py a b c | args ['C:\\tmp\\u.py'] | | # Case (1D): | C:\tmp u.py a b c | args ['C:\\tmp\\u.py', 'a', 'b', 'c'] Almost certainly means that the association between .py files and the python executable has been set up differently. Try typing (as the command shell): assoc .py = .py=Python.File ftype Python.File = python.file=C:\Python24\python.exe %1 %* Now if they don't look like that, in particular if the second one looks like this: python.file=C:\Python24\python.exe %1 then the extra parameters (everything after the script filename) won'e get passed along to the interpreter. TJG This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments question (Windows XP)
Tim Golden wrote: [ezd] | # u.py | import sys | print 'args',sys.argv | | in Command Prompt window, with 2 command lines on 2 PCs: | | # Case (1L): | C:\tmp u.py a b c | args ['C:\\tmp\\u.py'] | | # Case (1D): | C:\tmp u.py a b c | args ['C:\\tmp\\u.py', 'a', 'b', 'c'] Almost certainly means that the association between .py files and the python executable has been set up differently. Try typing (as the command shell): assoc .py = .py=Python.File ftype Python.File = python.file=C:\Python24\python.exe %1 %* Now if they don't look like that, in particular if the second one looks like this: python.file=C:\Python24\python.exe %1 then the extra parameters (everything after the script filename) won'e get passed along to the interpreter. I checked my computer and saw C:\Python24\userassoc .py .py=Python.File C:\Python24\userftype Python.File Python.File=C:\Python24\python.exe -n -e %1 What's with the -n and -e options? Those aren't legal and python.exe crashes. What the fuck is going on? I've been using command line parameters for years. Is it Python 2.4 (recently installed)? So I used the the FTYPE command to change it to get rid of the -n and -e options and also add the option to include the rest of the arguments (only I used %~2 instead of %*). Nothing changed. Still crashing telling me that -n is an illegal option. Re-booted, still crashed. Checked that my change was still in effect, both from command line and from WindowsExplorer\Tools\FolderOptions\FileType. C:\Python24\userftype Python.File Python.File=C:\Python24\python.exe %1 %~2 What the fuck? Why isn't this working? I tracked the problem to the system registry (don't know if the following applies to XP, mine is Win2k). In HKEY_CLASSES_ROOT\Python.File\shell\open\command the (Default) key does indeed contain the string C:\Python24\python.exe %1 %~2 but there was another key named command that contained the following binary data: 62 00 33 00 36 00 65 00 b.3.6.e. 0008 34 00 53 00 57 00 34 00 4.S.W.4. 0010 28 00 40 00 68 00 58 00 ([EMAIL PROTECTED] 0018 55 00 71 00 71 00 6F 00 U.q.q.o. 0020 41 00 5B 00 43 00 39 00 A.[.C.9. 0028 44 00 65 00 66 00 61 00 D.e.f.a. 0030 75 00 6C 00 74 00 46 00 u.l.t.F. 0038 65 00 61 00 74 00 75 00 e.a.t.u. 0040 72 00 65 00 3E 00 5F 00 r.e.._. 0048 7E 00 65 00 3E 00 5F 00 ~.W.o.2. 0050 70 00 27 00 61 00 38 00 p.'.a.8. 0058 39 00 4A 00 21 00 61 00 9.J.!.a. 0060 61 00 69 00 2C 00 51 00 a.i...Q. 0068 35 00 31 00 78 00 20 00 5.1.x. . 0070 2D 00 6E 00 20 00 2D 00 -.n. .-. 0078 65 00 20 00 22 00 25 00 e. ..%. 0080 31 00 22 00 00 00 00 00 1.. 0088 The -n and -e options are still there, so the system must be ignoring the strings set by FTYPE and uses this binary data instead. A quick edit to get rid of the -n -e and now there's no more crashing. Now I've got the same symptom as the OP C:\python24\useru a b c args ['C:\\python24\\user\\u.py'] Back to the registry editor to add the %* 62 00 33 00 36 00 65 00 b.3.6.e. 0008 34 00 53 00 57 00 34 00 4.S.W.4. 0010 28 00 40 00 68 00 58 00 ([EMAIL PROTECTED] 0018 55 00 71 00 71 00 6F 00 U.q.q.o. 0020 41 00 5B 00 43 00 39 00 A.[.C.9. 0028 44 00 65 00 66 00 61 00 D.e.f.a. 0030 75 00 6C 00 74 00 46 00 u.l.t.F. 0038 65 00 61 00 74 00 75 00 e.a.t.u. 0040 72 00 65 00 3E 00 5F 00 r.e.._. 0048 7E 00 65 00 3E 00 5F 00 ~.W.o.2. 0050 70 00 27 00 61 00 38 00 p.'.a.8. 0058 39 00 4A 00 21 00 61 00 9.J.!.a. 0060 61 00 69 00 2C 00 51 00 a.i...Q. 0068 35 00 31 00 78 00 20 00 5.1.x. . 0070 22 00 25 00 31 00 22 00 .%.1.. 0078 20 00 22 00 25 00 2A 00 ..%.*. 0080 22 00 00 00 00 00 00 00 ... 0088 And now I get all the complete argv. Or do I? C:\python24\useru a b c args ['C:\\python24\\user\\u.py', ' a b c'] Wait a minute, that can't be right. All the aruments are concatenated into a single string. I KNOW my programs that use argv don't have to split the argument string. So I did some experimenting: with %~2 C:\python24\useru a b c args ['C:\\python24\\user\\u.py', ' a b c'] Ok, that didn't help. with %2 %3 C:\python24\useru a b c args ['C:\\python24\\user\\u.py', 'a', 'b'] That's better. But It looks like I got to call out all nine arguments. with %2 %3 %4 %5 %6 %7 %8 %9 C:\python24\useru a b c args ['C:\\python24\\user\\u.py', 'a', 'b', 'c', '', '', '', '', ''] No, no, no! This is STILL wrong. I've got programs that count how many arguments were passed. This would fuck them up. HOW CAN THIS HAVE EVER WORKED? Then the light came on. It has, in fact, NEVER worked. I just realized that in all the years of using the command line, I've always typed C:\Python24\userpython u.py a b c and have never actually used file associations. Sure enough, that gives me C:\Python24\userpython u.py a b c args ['u.py', 'a', 'b', 'c'] Duh. No wonder my programs worked, I was using them incorrectly. So now I got to decide whether the file association should be set to %2 %3 %4 %5 %6 %7 %8 %9 and change the
Re: Command line arguments question (Windows XP)
Tim Golden wrote: python.file=C:\Python24\python.exe %1 %* [EMAIL PROTECTED] wrote: So now I got to decide whether the file association should be set to %2 %3 %4 %5 %6 %7 %8 %9 and change the programs that count the arguments or set it to %* and change the programs do a split on argv[1] to seperate the parameters. Have you tried using %* without quotes? Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Command line arguments question (Windows XP)
Ross Ridge wrote: Tim Golden wrote: python.file=C:\Python24\python.exe %1 %* [EMAIL PROTECTED] wrote: So now I got to decide whether the file association should be set to %2 %3 %4 %5 %6 %7 %8 %9 and change the programs that count the arguments or set it to %* and change the programs do a split on argv[1] to seperate the parameters. Have you tried using %* without quotes? Ah, didn't think of that. Let me try changing it to %* without quotes. C:\python24\useru a b c args ['C:\\python24\\user\\u.py', 'a', 'b', 'c'] Hey, it works like it should. I only quoted it because that's the way I found it in the registry (the %1 is still in quotes). Thanks for the tip. Now I don't have to change any programs. I forgot to mention that there's also a registry entry for Python.CompiledFile. It also is missing the %* and has the invalid -n -e flags. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments
What's the purpose of this utility? Is it to do something with the URL? And the URL must always be specified? What about the name? Also mandatory, or optional? The relationship between the two? its just a simple rss reader. i'm writing it almost purely just to get me using language (i'm learning python) it lets you save rss feeds, and to do this one would specify a name and url (ie you have to specify both), but there are other things it can do (remove a rss feed, view a feed) hence i thought it was best to using command line options You also could opt for the OptionParser in optparse.. Thanks, i'll take a look On 8/31/05, Michael Hoffman [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: pyparser.add_option(-n, --name, dest=name, action=store, py help=enter a name) pyparser.add_option(-u, --url, action=store, dest=url, help = enter an url) It's worth noting that this will have the same effect and involves less repetitive typing: parser.add_option(-n, --name, help=enter a name) parser.add_option(-u, --url, help=enter a url) Discovering this has made optparse usage much more painless for me, and also reduces the incidence of those nasty multiple line option additions. Although I should note for the record that I agree with Peter Hansen that if the arguments are not *optional* then they should not be made options in this manner. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments
Jon Hewer wrote: What's the purpose of this utility? Is it to do something with the URL? And the URL must always be specified? What about the name? Also mandatory, or optional? The relationship between the two? its just a simple rss reader. i'm writing it almost purely just to get me using language (i'm learning python) it lets you save rss feeds, and to do this one would specify a name and url (ie you have to specify both), but there are other things it can do (remove a rss feed, view a feed) hence i thought it was best to using command line options In that case, consider making the URL or the name, or both, an argument *after* the options. The operation you want to perform would be specified with an option, possibly including an argument of its own if that information wasn't normally needed. For example (and keep in mind I really have no idea what RSS is useful for, and my sole exposure to it is to subscribe to the BBC Latest Headlines in Firefox): rssutil --add -nBBC http://fxfeeds.mozilla.org/rss20.xml rssutil --remove -n BBC rssutil --view http://fxfeeds.mozilla.org/rss20.xml or perhaps: rssutil -ahttp://fxfeeds.mozilla.org/rss20.xml BBC rssutil --remove BBC rssutil -v BBC I can't judge which blend of possibilities is more reasonable; I'm just trying to point out some of the thought process behind choosing an appropriate scheme. Making *everything* an option here just feels wrong, from a user interface point of view. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments
Jon Hewer wrote: i am writing a little script and currently implementing command line arguments following the guide by mark pilgrim from dive into python; http://diveintopython.org/scripts_and_streams/command_line_arguments.html thats all fine, however i am not sure of the BEST way to handle multiple command line arguments for my script, i want to be able to accept two arguments, a name and a url, but i am not sure if its best to use one command line option/flag (eg -n to specify name) and then grab the url from the extra data which will be in 'args': opts, args = getopt.getopt(sys.argv[1:], n:, [name=]) or to have two command line options/flags, -n and -u, and checking that these have both been specified and then proceeding (this might be a little messier) any tips would be much appreciated I would approach this as a usability issue for your users, rather than from the point of view of which is a little messier in the code. What's the purpose of this utility? Is it to do something with the URL? And the URL must always be specified? What about the name? Also mandatory, or optional? The relationship between the two? I would guess (without yet knowing what you are doing) that if these things are not really *optional*, making them options is not the best approach and you might be better off just requiring them to be specified on the command line as two arguments. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments
You also could opt for the OptionParser in optparse, it is quiet
powerful, and you can keep your code clean. Your requirements would
translate to something like:
py#!/usr/bin/env python
pyshow OptionParser
py
pyfrom optparse import OptionParser
py
pydef main():
pyparser = OptionParser(usage = __doc__, version = '3.1415926')
pyparser.add_option(-n, --name, dest=name, action=store,
py help=enter a name)
pyparser.add_option(-u, --url, action=store, dest=url,
help = enter an url)
py
py(options, args) = parser.parse_args()
pyif not options.name and not options.url:
py parser.error('specify both name and url')
pyprint options.name
pyprint options.url
py
pyif __name__ == __main__:
pymain()
when called it will print things like:
[EMAIL PROTECTED]:~ $ ./test.py -u www.python.org -n python
{'url': 'www.python.org', 'name': 'python'} []
[EMAIL PROTECTED]:~ $ ./test.py -u www.python.org -n python
python
www.python.org
[EMAIL PROTECTED]:~ $ ./test.py -h
usage: show OptionParser
options:
--version show program's version number and exit
-h, --helpshow this help message and exit
-n NAME, --name=NAME enter a name
-u URL, --url=URL enter an url
[EMAIL PROTECTED]:~ $ ./test.py --version
3.1415926
[EMAIL PROTECTED]:~ $ ./test.py
usage: show OptionParser
test.py: error: specify both name and url
[EMAIL PROTECTED]:~ $
--
http://mail.python.org/mailman/listinfo/python-list
Re: command line arguments
[EMAIL PROTECTED] wrote: pyparser.add_option(-n, --name, dest=name, action=store, py help=enter a name) pyparser.add_option(-u, --url, action=store, dest=url, help = enter an url) It's worth noting that this will have the same effect and involves less repetitive typing: parser.add_option(-n, --name, help=enter a name) parser.add_option(-u, --url, help=enter a url) Discovering this has made optparse usage much more painless for me, and also reduces the incidence of those nasty multiple line option additions. Although I should note for the record that I agree with Peter Hansen that if the arguments are not *optional* then they should not be made options in this manner. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
On Thu, 25 Aug 2005 11:39:48 -0700, Trent Mick wrote: [michael wrote] SOLVED! Thank you. I wonder why this was needed for 2.4 and not 2.2? I don't think it was lingering things from old installs because it happened on a persons computer that had never had any python installed before 2.4. It might be due to a bug in the Python 2.4 installer not setting the proper file associations. What installer package did you use? Trent I used the python2.4.MSI from python.org site (dated 3-6-05). I think this was the first time they went to MSI verses an exe based installer. it says Python 2.4 (#60 November 30th, 2004) when I start it. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
[michael wrote] I wonder why this was needed for 2.4 and not 2.2? I don't think it was lingering things from old installs because it happened on a persons computer that had never had any python installed before 2.4. [Trent] It might be due to a bug in the Python 2.4 installer not setting the proper file associations. What installer package did you use? I used the python2.4.MSI from python.org site (dated 3-6-05). I think this was the first time they went to MSI verses an exe based installer. it says Python 2.4 (#60 November 30th, 2004) when I start it. I think Martin has been doing MSIs for a little bit longer than that, but I'm not sure. Martin, is it possible that there is a bug in setting up the .py/Python.File association in the python2.4.msi? Here is the start of this thread: http://mail.python.org/pipermail/python-list/2005-August/296007.html What association (if any) does your Python MSI setup? Cheers, Trent -- Trent Mick [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
Trent Mick wrote: I used the python2.4.MSI from python.org site (dated 3-6-05). I think this was the first time they went to MSI verses an exe based installer. it says Python 2.4 (#60 November 30th, 2004) when I start it. I think Martin has been doing MSIs for a little bit longer than that, but I'm not sure. I started after 2.3, but MSIs were released for the 2.4 alpha and beta releases, as well. Martin, is it possible that there is a bug in setting up the .py/Python.File association in the python2.4.msi? Here is the start of this thread: http://mail.python.org/pipermail/python-list/2005-August/296007.html I don't think the 2.4 MSI has such a bug. There were various issues in the alpha releases, but they got resolved. There was a bug in the shortcuts (IDLE would not start if TARGETDIR had a space in it), but that is an unrelated issue. Please refer to http://www.python.org/2.4/bugs.html for the most frequently reported bugs in 2.4. What association (if any) does your Python MSI setup? assoc .py gives Python.File, ftype Python.File gives Python.File=C:\Python24\python.exe %1 %* This is all done through registry (i.e. no advertised extensions). Software\Classes\.py is Python.File, Software\Classes\Python.File\shell\open\command is [TARGETDIR]python.exe %1 %* My guess is that the MSI file was installed Just for me, and then a different user tries to find the associations, which fails as they are in the other user's profile. Alternatively, the Register Extensions feature in the Customize Python 2.4 dialog may have been deselected. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
michael [EMAIL PROTECTED] wrote: I have a question about Windows based python (2.4 and later). For example, if I make a script called test.py like so: import sys print sys.argv then run it: python test.py this is a test I see a list with ['test.py', 'this', 'is', 'a', 'test'] All is good! BUT... If i make .py extensions be run as exes (by setting the .py extension to be executable with PATHEXT setting in environment variables, the Python program will run, but NO arguments are passed! For example, after setting .py extension to be executable, i get this: test this is a test I get ['test.py]. NO arguments are passed. NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and earlier works FINE. It is a configuration problem. Bring up a Command Shell and run the assoc and ftype commands like this: C:\Tmpassoc .py .py=Python.File C:\Tmpftype Python.File Python.File=C:\Apps\Python24\python.exe %1 %* C:\Tmp The KEY part of that is the %* at the end of the Python.File defintion. That tells the system to insert the rest of the command line parameters at that point. If you have ONLY the %1, the command will run but no parameters will be forwarded. If so, you can fix this by typing: C:\Tmpftype Python.File=C:\Apps\Python24\python.exe %1 %* Substituting your own path, of course. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
On Thu, 25 Aug 2005 00:46:41 -0700, Tim Roberts wrote: michael [EMAIL PROTECTED] wrote: I have a question about Windows based python (2.4 and later). For example, if I make a script called test.py like so: import sys print sys.argv then run it: python test.py this is a test I see a list with ['test.py', 'this', 'is', 'a', 'test'] All is good! BUT... If i make .py extensions be run as exes (by setting the .py extension to be executable with PATHEXT setting in environment variables, the Python program will run, but NO arguments are passed! For example, after setting .py extension to be executable, i get this: test this is a test I get ['test.py]. NO arguments are passed. NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and earlier works FINE. It is a configuration problem. Bring up a Command Shell and run the assoc and ftype commands like this: C:\Tmpassoc .py .py=Python.File C:\Tmpftype Python.File Python.File=C:\Apps\Python24\python.exe %1 %* C:\Tmp The KEY part of that is the %* at the end of the Python.File defintion. That tells the system to insert the rest of the command line parameters at that point. If you have ONLY the %1, the command will run but no parameters will be forwarded. If so, you can fix this by typing: C:\Tmpftype Python.File=C:\Apps\Python24\python.exe %1 %* Substituting your own path, of course. Tim, I can confirm you were right! Thank you very much. This will get us through the issue. I wonder why this was needed? One way or the other, you taught me something and I thank you. Michael Christopher -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
On Thu, 25 Aug 2005 00:46:41 -0700, Tim Roberts wrote: michael [EMAIL PROTECTED] wrote: I have a question about Windows based python (2.4 and later). For example, if I make a script called test.py like so: import sys print sys.argv then run it: python test.py this is a test I see a list with ['test.py', 'this', 'is', 'a', 'test'] All is good! BUT... If i make .py extensions be run as exes (by setting the .py extension to be executable with PATHEXT setting in environment variables, the Python program will run, but NO arguments are passed! For example, after setting .py extension to be executable, i get this: test this is a test I get ['test.py]. NO arguments are passed. NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and earlier works FINE. It is a configuration problem. Bring up a Command Shell and run the assoc and ftype commands like this: C:\Tmpassoc .py .py=Python.File C:\Tmpftype Python.File Python.File=C:\Apps\Python24\python.exe %1 %* C:\Tmp The KEY part of that is the %* at the end of the Python.File defintion. That tells the system to insert the rest of the command line parameters at that point. If you have ONLY the %1, the command will run but no parameters will be forwarded. If so, you can fix this by typing: C:\Tmpftype Python.File=C:\Apps\Python24\python.exe %1 %* Substituting your own path, of course. SOLVED! Thank you. I wonder why this was needed for 2.4 and not 2.2? I don't think it was lingering things from old installs because it happened on a persons computer that had never had any python installed before 2.4. Anyway, THANKS! Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Command Line arguments
[michael wrote] SOLVED! Thank you. I wonder why this was needed for 2.4 and not 2.2? I don't think it was lingering things from old installs because it happened on a persons computer that had never had any python installed before 2.4. It might be due to a bug in the Python 2.4 installer not setting the proper file associations. What installer package did you use? Trent -- Trent Mick [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
