stevesu@bronze.UUCP (Steve Summit) (09/21/83)
So far, I haven't found pipes to be too deficient for passing messages between processes. I have a replacement for "cu" with a pipe between the transmit and receive processes, so that the transmit process, which is under the control of the user, can send messages to the receive process, telling it to open a local file for writing, etc. (In the generic cu, this information must come from the remote device, in a painful syntax involving the '~' character, which many big mainframes don't have.) It works like a charm. I'm sure there are more complicated applications out there where pipes and signals break down, which is what prompted this discussion, but I haven't had to deal with them yet. (No flames about my naievete, please.) I'm getting tired of people complaining that "unix doesn't have IPC," "unix doesn't have file and record locking," etc. These deficiencies are an acknowledged part of the "unix philosophy," as described in the "UNIX Time-Sharing System" paper by Ritchie and Thompson. (Everyone should read this article two or three times before posting an article mentioning "unix philosophy." It's right there in volume two of your unix manual.) It's big, hairy features like IPC and record locking that turn operating systems into hard-to-use dinosaurs. Of course, those features are occasionally useful, but I like to see unix stay "small and beautiful." I know I'm going to get flames from people who say that operating systems have to grow and respond to new needs and ideas. (Actually, that's in the unix paper too, and is one of the reasons unix was developed in the first place.) However, elegance and simplicity are virtues that are often not appreciated. Our pals at Berkeley have already contrived a number of pieces of software that are a bit on the "big and ugly" side. (Take a look at csh, or vi, or the new tty driver.) Steve Summit textronix!tekmdp!bronze!stevesu