i wonder if it is common enough to want to change not only close but 9P (Tclunk would presumably change, or another message added such as T½clunk or Tclink). i think one reason it wasn't much used in old BSD is that most TCP/IP protocols have an application handshake at the end, two exceptions being now-deprecated BSD protocols. on the other hand, i grep and see that new BSD manages to use it in cat(!), and why not, and there are other uses, but only a few could be considered essential (mainly for those tcp/ip protocols i mentioned). inessential ones include a few preventing one part of the program from reading messages written by another part.
still, that's not to say close-write hasn't got some merit if otherwise you can't do something important, but if its use is generally specific to particular protocols (applications), one might add a control message to ip/tcp.c with some consequential coding. in fact, it has "hangup" but that seems to assume that RST sent implies no further data can be received, which might not be right anyway. perhaps just changing that would do. of course, i'm making the assumption that the application must know these low-level properties, because application protocol assumes the network has them, so it won't work on just any type of connection. it isn't quite the same as with IL/IP because it just transmits write boundaries, so that as with 9 pipes zero isn't a special case, and it doesn't shut down any part of the link. oh. i see. their cat includes specific support for Unix-domain sockets (ifdef'd). what the ... oh. i see. it's because plain open doesn't work on them and gives EOPNOTSUPP?? not-quite-unix domain sockets? and there are two shutdown calls but only one is ever called, on a read-only file, which reduces it to close. i wondered if some of the other calls i saw are there because a networking book says to use shutdown. i saw shutdown(fd, 0); shutdown(fd, 1); ok, ok. sometimes there are ifdef's and conditionals round some of those, but still.
