Python sys.argv [1:] does not select command line options

Question

Update / solution: answer below from Zack . The problem was that the end of the DOS lines in the script file itself, clenotes.cmd. Since I was so much futzed with various files, I deleted the whole directory and then reloaded the new copy from HERE . I ran the Zack perl script in the file in the same way:

perl -pi.bak -e 's/[ \t\r]+$//' clenotes.cmd 

Then I changed the execution of the command a bit so that the final script becomes:

 CWD=`dirname $0` JYTHON_HOME="$CWD" LIB_DIR="$JYTHON_HOME/lib" NOTES_HOME="/opt/ibm/lotus/notes/" export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$NOTES_HOME java -cp "$LIB_DIR" -jar "$LIB_DIR/jython.jar" -Djython.home="$CWD/" -Dpython.path="$LIB_DIR:$CWD/ext" -Djava.library.path="$NOTES_HOME" "$LIB_DIR/clenotes/cletes/clenotes.py" " $@ " 

So it was - everything else worked. No changes are required for clenotes.py or clenotes.cfg. Thank you very much for sticking to a question which, I think, turned out to be quite simple.

---

Update: I am shortening some of the code to make it more readable and remove unnecessary information from the message.

---

I am trying to get the Lotus Notes command line to work on Linux, and I am having a problem with something related to sys.argv [1:] in the python file. The windows script is here:

 @echo off @setlocal set CWD=%~dp0 set JYTHON_HOME=%CWD% set LIB_DIR=%JYTHON_HOME%/lib java -cp %LIB_DIR% -jar %LIB_DIR%/jython.jar -Djython.home=%CWD% -python.path=%LIB_DIR%;%CWD%/ext %LIB_DIR%/clenotes/clenotes.py %* @endlocal 

I had a hard time with variables, so for Linux it looks something like this:

 java -cp ./lib/ -jar ./lib/jython.jar -Djython.home=./ -Dpython.path=./lib:./ext -Djava.library.path=/opt/ibm/lotus/notes/ ./lib/clenotes/clenotes.py $* 

I run it from a directory. In any case, it puzzles me that he does not select any parameters that I pass from the command line. clenotes.cmd --help results in

 No commands specified. Use --help option for usage. 

Here is the section where command line arguments should be parsed:

 def main(): Output.log("Entering %sv%s" % (PROGRAM_NAME,VERSION),Output.LOGTYPE_DEBUG) cliOptions2=[] for opt in cliOptions: opt2=opt.replace('--','') opt2=opt2.replace('!','=') cliOptions2.append(opt2) opts=[] args=[] try: opts, args = getopt.getopt(sys.argv[1:], '', cliOptions2) 

I am using Python 3.1.3 on Arch Linux 64bit in a 32bit chroot environment. Can I provide anything else?

Just in case, this is necessary ... HERE is the entire clenotes.py file.

In addition, as indicated in the comments, the configuration file (containing the help message and viable parameters / arguments, HERE

---

Update

After many attempts, the best progress I made was to study what it sets up as options and arguments in the (main) method. The most surprising thing was that when passing the argument, and then looking at the result of the analysis using print sys.argv , in this case the option will have a final \r . For instance:

 clenotes.cmd appointments args is ['appointments\r'] 

On Windows, I did the same, and args was listed as ['appointments'] . Also, manually setting args=['appointments'] and then commenting out the section where getopt.getopt assigns the processed value.

Finally, I found that when using multiple arguments, n-1 of them is interpreted and used, and the nth is ignored. This is kind of a workaround since I can really use a script ... but obviously this is not recommended. If I want to see today's meetings, I can execute clenotes.cmd appointments --today --today and it will work. sys.argv spit out: ['appointments', '--today', '--today\r'] .

So ... what causes the final \r ? I think this is due to the actual script. Remember again:

 java -cp ./lib/ -jar ./lib/jython.jar -Djython.home=./ -Dpython.path=./lib:./ext -Djava.library.path=/opt/ibm/lotus/notes/ ./lib/clenotes/clenotes.py $* 

So ... a bunch of path material and then the actual python file: clenotes.py $*

I got $* from HERE

Does carriage return collect ??

Answer 1

I think your problem is that clenotes.cfg has DOS line endings that Python interprets incorrectly. Try changing this line clenotes.py

 config.readfp(open('%sconfig/clenotes.cfg' % System.getProperty('jython.home'))) 

to read

 config.readfp(open('%sconfig/clenotes.cfg' % System.getProperty('jython.home'), "rU")) 

"rU" tells Python that although it runs on a Unix system, it should be prepared to handle a file containing the end of DOS lines. See http://docs.python.org/library/functions.html#open - scroll down to the paragraph that begins "In addition to the standard fopen() ... modes."

(Or you can run this command: perl -pi.bak -e 's/[ \t\r]+$// clenotes.cfg - this will convert it to the end of the Unix line. In your shoes, I will probably do and both.)

(If none of the suggestions above helps, the next thing I would try is to press clenotes.py with the above perl command. I don’t see how this could be a problem, but if the \r characters are not coming from clenotes.cfg , the .py file is the only likely remaining source.)

(EDIT: based on your comments on the question itself, now I think it is clenotes.cmd , a shell script that needs to be converted from DOS to the end of a Unix line.)

Answer 2

I will have to keep looking for where this comes from. But at the same time, this problem has become much easier. After analyzing the arguments, do the following:

 args = [arg.strip() for arg in args] 

This will save you from \r

EDIT: But wait - is this only a partial solution? Does it not handle the parameters correctly?

EDIT2: It seems that \r needs to be deleted earlier. When there is no command, /r will never be shy, because only the \r stripes after getopt are highlighted above. It should have been obvious to me before - instead of passing sys.argv[1:] here

 opts, args = getopt.getopt(sys.argv[1:], '', cliOptions2) 

change it first

 argv = [arg.strip() for arg in sys.argv[1:]] opts, args = getopt.getopt(argv, '', cliOptions2) 

You can also just do sys.argv[-1] = sys.argv[-1].strip() ... but the c programmer in me starts to feel a little nauseous looking at it. Probably irrational, I know.

Or just do what Zack said and convert clenotes.cmd to linux format - however, note that deleting here ensures that other people don’t have to solve the same problem again. (On the other hand, it is a little ugly or at least mysterious for people not expecting such problems.)