21 May 2012 23:24
Re: Proposal: Add option to add dates to write(1)
Mouse <mouse <at> Rodents-Montreal.ORG>
2012-05-21 21:24:46 GMT
2012-05-21 21:24:46 GMT
>> Possibly, if you can come up with a way for "the receiver's >> environment" to be (a) well-defined and (b) accessible to the >> sender. > ps(1) uses kvm_getenvv2(3). I guess we'd agree that satisifies (a) > but not (b) unless the sender is the super-user? I wouldn't. Part of the reason I mentioned (a) is that write is writing to a tty, whereas environments are attached to processes; there may well be 0, or >1, processes associated with the tty, for whatever value of "associated" you end up using. (Arguably, write should write to a user, not a tty, with the historical behaviour of choosing a tty to write to being a historical accident. If you go with this point of view, it makes things even worse.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse <at> rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
> > > 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,
>> No. Anyone can read a mode 644 file.
> Thus having permissions in your home directory set.
True, but there's nothing inconsistent about "if you want this to work,
the writer has to be able to read the file, including searching your
homedir".
>>> And to fail when network is down because of nfs (home) hanging,
>>> ldap hanging, or whatever.
A valid point. This could be worked aorund by doing the lookup in a
child process, with a relatively short timeout in the parent.
The KISS argument has weight to me too; I am inclined to agree with the
people who've been saying that one of write's strengths is its
simplicity. Given the original intended use case, perhaps this could
be done only when a particular flag is given on the command line?
Thus, it requires agreement from the sender, but only minimally, and
the strftime format is still supplied by the receiver.
I'm not sure I like it, but I dislike it less than anything else I've
seen suggested; this version actually, to me, makes the "is it worth
trying" cut (albeit not by much).
RSS Feed