compiler switches; getopt behavior

Robert Schweikert rjschwei at
Sat Dec 9 12:10:24 CET 2000

Is there a compile time switch used when building Python on Linux to
make getopt behave as if the POSIXLY_CORRECT environment variable was
set? Or is the interpreter setting this environment variable somehow in
its environment?

It seems that if one builds Python a bit different one can get the
following undesired behavior.

script, test the system getopt function.
import sys

print sys.argv

Now running this on Linux (not the interpreter that comes with the
distribution) I can produce the following

python -help

Python: invalid option -- h
usage: Python [-d] [-i] [-s] [-u ] [-v] [-c cmd | file | -] [arg] ...

Options and arguments (and corresponding environment variables):
-d     : debug output from parser (also PYTHONDEBUG=x)
-i     : inspect interactively after running script (also
-s     : suppress printing of top level expressions (also
-u     : unbuffered stdout and stderr (also PYTHONUNBUFFERED=x)
-v     : verbose (trace import statements) (also PYTHONVERBOSE=x)
-c cmd : program passed in as string (terminates option list)
file   : program read from script file
-      : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]

Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH   : colon-separated list of directories prefixed to the
               default module search path.  The result is sys.path.

However, when I leave the dash of I get what I expect:

python help
['', 'help']

Further after setting POSIXLY_CORRECT I also get what I expect:

python -help
['', '-help']

Thus the question what did I mess up when custom compiling the


Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei at                         LINUX

More information about the Python-list mailing list