[Mailman-Users] sys.exit(0) causes no cgi output

[Karl Berry]

Red Hat 7.2 (i686), apache 1.3.26, python 2.2.2, mailman 2.1.1 (also
happened with 2.1).

After applying the htdig patches, we found that calls to
http://.../mailman/htdig/... got an internal server error (HTTP 500).
(An example full url:
http://tug.org/mailman/htdig/pdftex/2002-July/002843.html.)

It turned out that nothing was being written to stdout, that is, in
driver.py we have the following block:

        try:
            try:
                sys.stderr = logger
                sys.stdout = tempstdout
                main()
                sys.__stdout__.write(tempstdout.getvalue())
            finally:
                sys.stderr = sys.__stderr__
                sys.stdout = sys.__stdout__
        except SystemExit:
            # This is a valid way for the function to exit.
            pass

The sys.__stdout__.write(tempstdout.getvalue()) statement was not
getting executed, so apache had no headers to send back, thus the ISE.
Instead, the main() call was jumping to the finally block and then the
except SystemExit block.

Why?  Because of the sys.exit(0) at the end of htdig.py.  If that is
changed to `return', it works.  So, apparently sys.exit(0) is throwing a
SystemExit exception, which I guess is logical enough.

Since not every sys.exit(0) can be changed to return (e.g., the one in
error_quit in htdig.py), for now I changed driver.py so that the `except
SystemExit' also does the write:
        except SystemExit:
            # This is a valid way for the function to exit.
            sys.__stdout__.write(tempstdout.getvalue())
            pass

(Well, actually, I changed cgi-wrapper.c to invoke xdriver and changed
it in a new script xdriver.py to avoid possibly disturbing all the other
mailman cgi scripts.)

Of course, there are sys.exit's scattered everywhere throughout all the
*.py files, not just in htdig.py.  So I feel like I must be missing
something.  How can it be working for every other script (at least I
guess it is), and no one else is seeing the problem?  Or does driver.py
really need to be changed?

Any info appreciated, this has been a frustrating morning.

Thanks,
karl at tug.org