mark@alias.uucp (Mark Andrews) (01/25/91)
As a frequent user of Berkeley mail, I was dismayed to find that you have modified the interface. In particular, I am talking about the 'R' and 'r' commands. In Berkeley mail, 'R' means reply to the author of the message while 'r' means reply to all recipients of the original message. However, in your version of Berkeley mail, you have made 'R' and 'r' equivalent with 'Ra' or 'ra' replacing 'r'. Why was it changed? I prefer it the way it is, and would like it changed back if possible. ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research, Toronto, Canada Phone: (416)-362-9181 Mail box: mark%alias@csri.utoronto.ca -- ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research,
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/01/91)
In article <1991Jan24.185356.13375@alias.uucp>, mark@alias.uucp (Mark Andrews) writes: > As a frequent user of Berkeley mail, I was dismayed to find that you have > modified the interface. In particular, I am talking about the 'R' and > 'r' commands. In Berkeley mail, 'R' means reply to the author of the message > while 'r' means reply to all recipients of the original message. > >However, in your version of Berkeley mail, you have made 'R' and 'r' equivalent > with 'Ra' or 'ra' replacing 'r'. Why was it changed? I prefer it the way it > is, and would like it changed back if possible. Having the "natural" or "default" reply command send to all recipients would be a serious bug. In small and large organizations, mail messages with more than one recepient are usually addressed to a small number of people. When replying to a message to a small number of receipents, it is common but not unversal to want to reply to all other recipeients as well as the originator. In medium organizations, multiply addressed email messages are commonly used for things like "Toyota in parking lot has lights on," "anyone who wants the extra foobaz outside the lab should speak up," and "if you want to go to the baby shower/going away party/funeral for Joe, let me know". In such an organization that do not have a fixed BSD Mail, you are bombarded with responses that you were not intended to receive. The harm these errant responses cause is far greater than inconvenience of having to use an uncommon command to respond to all recipients. There are several common ways in which the "r" commaond in BSD Mail is changed. One is to exchange the meanings of "r" and "R". Another is what SGI has done. As I say, this is a very common change. The SGI Mail command is originally the 4.2 BSD Mail, with many local changes, and those changes we liked from 4.3BSD. This particular change dates from 1986. I remember the improvement it made in life within SGI. In these days of high SGI-BSD compatibility, porting the 4.3BSD Mail from the tape or uunet should be trivial, should you want to change it back. Vernon Schryver, vjs@sgi.com Disclaimer: I was not a disinterested observer of this change to Mail.
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (02/02/91)
In article <1991Jan24.185356.13375@alias.uucp> mark@alias.uucp (Mark Andrews) writes: > >... in your version of Berkeley mail, you have made 'R' and 'r' equivalent >with 'Ra' or 'ra' replacing 'r'. Why was it changed? I prefer it the way it >is, and would like it changed back if possible. I'd go further. The Iris man page describes the original Berkeley way of doing things: R->sender, r->all recipients. This has never worked on my machine. There is no mention of ra. I just tried it and it does work. So I'm rather peeved that not only did they change the interface; they also didn't tell us that they changed it, and didn't tell us at all that a functionality that I, at least, used to use all the time, is in fact, still available. This is a 4d25tg running 3.2.1. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/02/91)
In article <1991Feb1.192946.18249@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: > > ... The Iris man page describes the original Berkeley way of doing > things: R->sender, r->all recipients. ... > > This is a 4d25tg running 3.2.1. 3.3.2 has fixes for many things, including many man pages. The 3.3.2 man page seems to correctly describe the SGI Mail r* commands. Even the help text in 3.3.2 Mail mentions ra. Please let us know if the newer text is still wrong. Vernon Schryver, vjs@sgi.com
slevy@poincare.geom.umn.edu (Stuart Levy) (02/02/91)
In article <83600@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <1991Jan24.185356.13375@alias.uucp>, mark@alias.uucp (Mark Andrews) writes: >> As a frequent user of Berkeley mail, I was dismayed to find that you have >> modified the interface. In particular, I am talking about the 'R' and >> 'r' commands... >There are several common ways in which the "r" commaond in BSD Mail is >changed. One is to exchange the meanings of "r" and "R". Another is what >SGI has done. As I say, this is a very common change. >... >In these days of high SGI-BSD compatibility, porting the 4.3BSD Mail >from the tape or uunet should be trivial, should you want to change it >back. > >Vernon Schryver, vjs@sgi.com I'd like to second Mark Andrews' complaint. Yes, it's reasonable to have reply-to-all be non-default. But if you were going to make that change, it'd be better just to swap 'r' <-> 'R'. We system administrators could then 'set replyall' in the systemwide Mail.rc to exchange them back. But with the command names changed, we can't. What other vendors have adapted mail in SGI's 'r' = 'R' != 'ra' style? This is new to me, at least. At our site, we're just stuck with remembering that Sun and NeXT mail uses one set of commands, and SGI mail uses an idiosyncratic different set. Yes, we can replace mail, but we shouldn't have to! Stuart Levy, Geometry Group, University of Minnesota slevy@geom.umn.edu
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/03/91)
In article <1991Feb2.005029.19901@cs.umn.edu>, slevy@poincare.geom.umn.edu (Stuart Levy) writes: > I'd like to second Mark Andrews' complaint. Yes, it's reasonable > to have reply-to-all be non-default. But if you were going > to make that change, it'd be better just to swap 'r' <-> 'R'. > We system administrators could then 'set replyall' in the systemwide Mail.rc > to exchange them back. ... Well, the change was made in 1986 before we'd looked at the 4.3BSD Mail, so we missed 'set replyall'. I recall that we argued about whether to just switch r & R, or to use a new command to "avoid confusion and calls to the Hotline." I don't remember which side I argued, so feel free to blame me. I started the thing by borrowing the idea from a previous employer, but don't remember if they switched r&R, or did ra. In either case, they're effectively out of business. At this late date, SGI is stuck with ra, to avoid making important people unhappy, most existing customers. I think we should re-review the differences between our 4.2BSD+SGI Mail and 4.3BSD Mail. How about adding a string valued replyall variable which would select among the two 4.3BSD and the SGI [rR]* choices? Is anyone bugged by the many ~ commands Robert added? I like them, and so hope not. Vernon Schryver, vjs@sgi.com
Dan Karron@UCBVAX.BERKELEY.EDU (02/04/91)
I like the mailer, but I am used to it. I think that we need more control over message header presentation. Such options are a longer subject field, I don't need to know the character count of a message, and the received date. I would rather know the send date. I would like to see more settable .mailrc options, such as a way to automatically set the showfrom option when reviewing saved outbound record'ed mail messages. Also, all of the .mailrc options should be settable from the command line option, so you can override your mailrc for special cases, situations, customers, whatever. A visual front end would be nice, and I would like to see a sendmail option so you can send a paper letter (printed on letterhead, with an envelope, and so on) with the inclusing of a special escape sequence, unknown computer, special domain, or what ever. We also need a way to scan subject header lines for literal and RE expressions. Also needed is a way to scan From and From: lines by user, domain, uucp path, etc. I would also like to see utilities to group mail by date send, date read, users from a domain, aliases, etc. I would like to also see the vacation automatic reply working, or a automatic reply like "I am very busy, but I did get your mail, and I will reply to it next morning" to let your corrospondants know that you are alive but distracted. > (contact usenet@ucbvax.Berkeley.EDU if you have questions) >Date: 2 Feb 91 21:08:24 GMT >From: Vernon Schryver <ucbvax.berkeley.edu!sgi!vjs%rhyolite.wpd.sgi.com> >Organization: Silicon Graphics, Inc., Mountain View, CA >Subject: Re: Why was mail_bsd(1) changed? >Message-Id: <83826@sgi.sgi.com> >References: <1991Jan24.185356.13375@alias.uucp>, <83600@sgi.sgi.com>, <1991Feb2.005029.19901@cs.umn.edu> >Sender: info-iris-request@BRL.MIL >To: info-iris@BRL.MIL > >In article <1991Feb2.005029.19901@cs.umn.edu>, slevy@poincare.geom.umn.edu (Stuart Levy) writes: >> I'd like to second Mark Andrews' complaint. Yes, it's reasonable >> to have reply-to-all be non-default. But if you were going >> to make that change, it'd be better just to swap 'r' <-> 'R'. >> We system administrators could then 'set replyall' in the systemwide Mail.rc >> to exchange them back. ... > >Well, the change was made in 1986 before we'd looked at the 4.3BSD Mail, so >we missed 'set replyall'. I recall that we argued about whether to just >switch r & R, or to use a new command to "avoid confusion and calls to the >Hotline." I don't remember which side I argued, so feel free to blame me. >I started the thing by borrowing the idea from a previous employer, but >don't remember if they switched r&R, or did ra. In either case, they're >effectively out of business. At this late date, SGI is stuck with ra, to >avoid making important people unhappy, most existing customers. > >I think we should re-review the differences between our 4.2BSD+SGI Mail and >4.3BSD Mail. How about adding a string valued replyall variable which >would select among the two 4.3BSD and the SGI [rR]* choices? > >Is anyone bugged by the many ~ commands Robert added? I like them, and so >hope not. > > >Vernon Schryver, vjs@sgi.com > +-----------------------------------------------------------------------------+ | karron@nyu.edu (E-mail alias that will always find me) | | Fax: 212 263 7190 * Dan Karron, Research Associate | | . . . . . . . . . . . . . . * New York University Medical Center | | 560 First Avenue \*\ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 263 5210 \***\_________________________________________ | | Main machine: karron.med.nyu.edu (128.122.135.3) IRIS 85GT | +-----------------------------------------------------------------------------+ NOTE PHONE NUMBER CHANGE: The Med Ctr has changed from 340 to 263 exchange.
jim@baroque.Stanford.EDU (James Helman) (02/04/91)
Control over mail header presentation: mh/format files Sort mail on arrival into folders, into mh/maildelivery the spool, or into a vacation program: Select messages by regexp matches in fields: mh/pick Sort mail by date or any other field mh/sortm Visual presentation: mh/xmh (X-based) mh/mhe (emacs-based) mh6.7 is available from many ftp sites, e.g. uunet.uu.net, gatekeeper.dec.com. xmh is available from these same sites. mhe, which I strongly prefer over xmh, comes with GNU emacs. Caveat: mh stores messages the same way most USENET news systems do, i.e., each folder is a directory containing numbered files, one message per file, as opposed to a folder or mbox file containing multiple messages. Hence, mh is not compatible with mbox-type folders a la Sun's mailtool, although conversion utilities are available. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127
mark@alias.uucp (Mark Andrews) (02/05/91)
In article <83600@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: <Stuff deleted> >In these days of high SGI-BSD compatibility, porting the 4.3BSD Mail >from the tape or uunet should be trivial, should you want to change it >back. > > >Vernon Schryver, vjs@sgi.com >Disclaimer: I was not a disinterested observer of this change to Mail. I agree you about the porting except for a few points. The SGI version of BSD mail has a few differences from the "true" 4.3BSD mail. As it says in the mail_bsd(1) man page, the following files are created" FILE Reason ---- ------ /usr/mail/user.lock Lock for user's mailbox. /usr/mail/user.rolock Read-only lock for user's mailbox. Used to prevent file contention between multiple Mail instances. Under what circumstances are these files created by mail_bsd(1)? I suspect that the `user.lock' file is only created by the mail program which delivers the mail to a users mailbox. Does SGI's version of mail_bsd(1) care about the existence of this file? I know from prior releases that if /usr/mail/user.lock existed when that user logged in, their login session would be locked until the user.lock file was removed (i.e.: the `/bin/mail -e' test in /etc/cshrc). I seem to remember reading about something in the IRIX 3.3 or 3.3.1 release notes that SGI had fixed this problem, but I don't remember. What should mail_bsd(1) do if it encounters a user.lock file? The purpose of the user.rolock is probably exactly as it looks. When you enter mail_bsd(1), the rolock file is created, thus making the users mail file read-only. As long as /usr/mail/user.rolock exists, the file may not be modified. If an attempt is made to modify the mail file (i.e.: concurrent mail sessions), the program should warn the user that the file may not be modified at this time. There is also the point that mail_bsd(1) is setgid mail, while BSD mail was not. While I could get the BSD mail compiled okay on the SGI machines, I would be worried about any important changes that I have overlooked during the port that may be important to SGI's implementation of the mail program. I appreciate the explanation. I guess I will have to get used to ra. ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research, Toronto, Canada Phone: (416)-362-9181 Mail box: mark%alias@csri.utoronto.ca -- ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research,
roberts@nimrod.wpd.sgi.com (roberts) (02/06/91)
In article <1991Feb4.175108.9761@alias.uucp>, mark@alias.uucp (Mark Andrews) writes: > > FILE Reason > ---- ------ > > /usr/mail/user.lock Lock for user's mailbox. > /usr/mail/user.rolock Read-only lock for user's mailbox. > Used to prevent file contention between multiple > Mail instances. > > Under what circumstances are these files created by mail_bsd(1)? > > I suspect that the `user.lock' file is only created by the mail program which > delivers the mail to a users mailbox. Does SGI's version of mail_bsd(1) care > about the existence of this file? Yes. This file is (should be) created and respected by any program which reads or modifies a mail file. The file will exist whenever /bin/mail or BSD Mail is reading or modifying the contents of the mailfile. Both /bin/mail and BSD Mail check for the existance of this lock file before reading or modifying the mail file. > I know from prior releases that if > /usr/mail/user.lock existed when that user logged in, their login session would > be locked until the user.lock file was removed (i.e.: the `/bin/mail -e' test > in /etc/cshrc). I seem to remember reading about something in the IRIX 3.3 > or 3.3.1 release notes that SGI had fixed this problem, but I don't remember. > What should mail_bsd(1) do if it encounters a user.lock file? Yes, the problem you mentioned has been solved. The user.lock file contains the PID of the process which created it. If BSD Mail encounters a user.lock file containing the PID of an active process, it will sleep and check again every 5 seconds. If 5 minutes elapse and the user.lock file has not disappeared, or the process which created it has not died, BSD Mail will assume that the user.lock file is bogus (since any user.lock file should be short-lived) and will overwrite it with its own user.lock file containing its own PID. Note, a similar mechanism is used by /bin/mail. > The purpose of the user.rolock is probably exactly as it looks. When you enter > mail_bsd(1), the rolock file is created, thus making the users mail file > read-only. As long as /usr/mail/user.rolock exists, the file may not be > modified. If an attempt is made to modify the mail file (i.e.: concurrent mail > sessions), the program should warn the user that the file may not be modified > at this time. You are correct. > There is also the point that mail_bsd(1) is setgid mail, while BSD mail was > not. This is so that the lock files can be written into the /usr/mail directory. Pre-3.3 BSD Mail did not create user.lock files correctly, and there was a possibility for corruption of the mailbox if you were quitting Mail at the same time that /bin/mail was delivering a message. The problem with writing proper lock files also contributed to the login session lock-up problem of pre-3.3 systems. - Robert Stephens Silicon Graphics Inc. roberts@sgi.com