Suppose that you are in the situation from yesterday's entry , where your support volume is too high to let youuse a single support alias that everyone is on but particular supportrequests are passed from person to person. As it happens, I think thatthere are still ways to avoid having a public ticketing system as yourprimary support method.

The problem that a public ticketing system is really solving here isthat you need a separate point of contact for each ticket that goesto several people (but not everyone)

In the past, I've been somewhat negative abouthaving a ticketing system as the primary method of talking with thesysadmins. But I have to admit that sometimes such a ticketing systemactually makes sense, and here's one example:

Suppose that your support group is sufficiently busy (you serve eithera large organization or one with a lot of problems) that a singlesupport alias would have too much traffic to be read by everyone all ofthe time. In this environment you have to hand support requests to

Everyone knows what ^D does on Unix; it generates an end of file,so that cat or various other programs will exit (especially ifthey have accidentally wound up reading from standard input ).

But this is just the usual effects of typing ^D; it is not whatit actually does. What ^D actually does is simple but subtle:

Typing ^D causes the tty driver to immediately finish a read() .

Normally doing a read() from a terminal is line-buffered inside thetty

Given the problems that the POSIX EINTR stuff causes to various programs, one might wonder why they existat all. Why not make all system calls restart when signals aredelivered?

What I believe it comes down to is library safety.

Suppose that your signal handler wants to change the main flow ofthe program. There are two plausible mechanisms for this: you canimmediately transfer control back to the main flow of your program withsome changes (the traditional setjmp()/longjmp() approach), or you can