compiler switches; getopt behavior

[Robert Schweikert]

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 try.py, 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 try.py -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
PYTHONINSPECT=x)
-s     : suppress printing of top level expressions (also
PYTHONSUPPRESS=x)
-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 try.py help
['try.py', 'help']


Further after setting POSIXLY_CORRECT I also get what I expect:

setenv POSIXLY_CORRECT
python try.py -help
['try.py', '-help']


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

Thanks,
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei at mindspring.com                         LINUX