Re: Proposal: Add option to add dates to write(1)

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Wed, 30 May 2012 19:22:26 +0200
Julian Djamil Fagir <gnrp%komkon2.de@localhost> wrote:

> > 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.  

> And to fail when network is down because of nfs (home) hanging, ldap
> hanging, or whatever.

Not ldap, surely.  who(1) looks in /var.  

Failing NFS-mounted home directories is a valid point.   I was trying
to avoid modifying anything besides write while keeping the user
in control.  

> Everything else involves technical complexity, defeating one of
> write's great pros.  

Your patch meets your needs, already works, and met no important
objection.  It should probably be accepted on that basis alone.  As the
Hitchhikers Guide to the Galaxy said of Earth, it's "mostly harmless".  

*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.  

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.  

I'm now inclined to agree with Mouse and Thor: the problem could be
solved, but not within a complexity budget justified by the minisule
size of the problem.  That leaves your solution, as you said, the only
one possible.  

--jkl