Hi, I'm not really thinking anymore about really patching write, but just for completion. ;-) > > > Agreed, the complexity might not be worth it, fsvo of "it". But the > > > OP's proposal was more complex, requiring agreement between sender > > > and recipient. By using ~/.writefmt instead, write locates the > > > user, attempts to open one file in his home directory and, if > > > successful, uses the contained string to format the time. Fallback > > > is current behavior. It's small, safe, predictable, and > > > convenient. > > > > so you want write(1) or group tty resp. to have even more permissions > > than currently. > > No. Anyone can read a mode 644 file. Thus having permissions in your home directory set. > > And to fail when network is down because of nfs (home) hanging, ldap > > hanging, or whatever. > > Not ldap, surely. who(1) looks in /var. Depending on your nss configuration, the system might first look into ldap for gecos fields. > *Because* it relies on administrative cooperation, however, I doubt the > feature you've implemented has general utility. It is subject to > being forgotten or ignored because it's nonstandard and because only > some recipients want it used. I suspect most operators -- not yours, > of course -- don't care whether the date appears in the message > banner. Certainly in the general case senders don't care a fig about > the receivers' formatting preferences. My patch is not about the general case, but about people having a write session for days. And if you do so, you have to agree with your communication partner *anyway* about the terminal you use, and some kind of communication protocol to be able to read the output. > That is why I said the receiver should be able to express a preference > that write respects, something he already does with e.g. mesg(1). I > was challenged to come up with a way to do that, a challenge I've > perhaps taken too seriously, and one definitely made more interesting by > the skeptical audience. That would be optimal, yes. Regards, Julian
Attachment:
signature.asc
Description: PGP signature