bash$ python3.1 -c 'pass' 2>&-
Aborted (core dumped)

(I verified, the core dump belongs to python.)

If you remove the redirection thingy at the end, it works.

Not sure why I ever wrote that code, but it has been working since
forever up to python3.0.

The problem is the check_fd in _fileio.c checks fstat of 2, which
returns EBADFD. I'm not sure what about this redirection makes it a bad
file descriptor, though..

After some searching around with Google, "2>&-" means "close file
descriptor 2" (i.e., standard error).

Please note that normally an error message is output, but of course it
doesn't display since stderr is invalid :-)

It's clearer if you close stdout instead:

$ ./python -c 'pass' >&-
Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor
Abandon

If we want to allow for closed {stdin, stdout, stderr}, I'm not sure
what the semantics should be. Should sys.std{in, out, err} be None? Or a
file object which always throws an error?

Under Python 2.x, you don't get a crash but the behaviour is quite
unhelpful anyway:

$ python -c 'print 1' >&-
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:

Is it even possible to portably test the validity of a file descriptor
without trying to write/read it?

When I first saw this bug, my gut feeling was "well, don't do that
then!"  However, I then recalled that Windows GUI applications have no
stdin, stdout, or stderr.  

Python 2 will raise IOError: Bad File Descriptor when the user tries to
write to stdout or stderr (more accurately, it raises the exception when
trying to flush data to the file descriptor).  

I just tested pythonw.exe.  If I set sys.stderr by hand to a file, then
write to sys.stdout, 2.6 will correctly write the exception to the file.
 3.1 exits silently.

> 3.1 exits silently.
Did you use "print"? pythonw.exe 3.1 sets sys.stdout to None.
if you use sys.stdout.write, you get an exception. But print() silently
does nothing if the file is None.

For what it's worth, the code in question is used here (using "import
distutils" instead of "pass"):

http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/config/python.m4?rev=1.15;content-type=text%2Fx-cvsweb-markup

This is obviously a completely gratuitous variant on 2>/dev/null, but it
has apparently been working since forever.  I'll probably go make the
change anyway.

Nevertheless, I think Python shouldn't core dump.  It may choose to exit
doing nothing (useful) if it doesn't want to deal with this case.

Check this for possible alternative behaviors:

$ ls 1>&-
ls: write error: Bad file descriptor
($? = 2)
$ ls 1>&- 2>&-
($? = 2, no output)

sorry, title restored!