modifying os.environ

[Donn Cave]

Quoth quinn at euro.ugcs.caltech.edu (Quinn Dunkan):
| On 18 Apr 2000 16:30:13 GMT, Donn Cave <donn at u.washington.edu> wrote:
...
|> - Raise exception on exit status, complete with error output as
|>   exception value.  A bit of a pain to implement, and again not
|>   not always the right thing to do, but usually it is the right
|>   thing.
|
| I don't understand... are you saying the close() method should throw the
| exception?  What's wrong with just checking it's return value normally?  How
| is a child you started exiting exceptional?  And if the child has been started
| asynchronously, do you mean throw an exception from the SIGCHLD handler, or
| waitpid()?

The exception, I should have said, is on exceptional exit status,
i.e. non-zero.  In theory this means the program failed, terminated
abnormally, etc.  Of course exit(0) raises no exception.

In C, we'd check the exit status (I hope), just as we'd check the
return (I hope) from a system function like unlink() or whatever.
In Python, we get exceptions instead and don't have to insert
``I hope'' into our discussions about how things work.  I find
this as useful with external commands as with internal functions.

In my version of this, I will raise the exception after finding
the exit status via waitpid().  I never trap SIGCHLD, don't think
it's a very good idea, so luckily I don't have to think about what
would happen if I had to raise an exception from a signal handler.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu