jbatson@bbn.com (Jay Batson) (12/21/90)
I am sure lots of people will have this answer, so maybe rather than flood the list with responses, probably you should answer to me directly. Here at BBN, we use MMDF, and therefore have always compiled MH to use MMDF as the "mts". However, BBN Advanced Computers, my division, sells a unix-based system of our own manufacture, based on the 4.3BSD release. Since MH is part of the release, we distribute MH. However, in our the build for our default release, we configure our conf/MH file to use MMDF as the mts. Of course, along a customer who wants to run MH, but uses sendmail at his mts. So I'm busy re-compiling with conf/MH set to use sendmail as the mts. However, I'm running into a hitch: When "inc" is doing it's thing, it (properly) looks for the maildrop in /usr/spool/mail/<myname> But when "inc" tries to create it's "locklfil" during execution, it tries to create it in /usr/spool/mail. Of course, as a non-privileged user, I can't write in that directory, so the call to lkfopen() of my mail file (in inc.c) fails. I suspect every sendmail site out there has bumped into this, too. So what am I doing wrong? I imagine it's a pre-compile configuration option somewhere, but what? By the way, I'm using MH 6.4 (for better or worse...). I've been hacking away, and I've hacked in the ability to add locklfil: xxx to my mtstailor file, and by the time we get to zotnet/mts/lock.c, the variable "locklfil" is set to point to xxx, and life works fine. (I also added support so that you can say @(LOCKLFIL) and config.sed will do the right thing.) But I can't imagine this is the "right" thing to do. Baffled in Boston.... Jay Batson Software Product Support UUCP: ...!uunet.uu.net!bbn.com!aci-questions 1-800-4AC-BFLY DOMAIN: aci-questions@bbn.com "Parallel processing can be fun!" Jay Batson BBN ACI Software Product Support UUCP: ...!harvard!bbn.com!jbatson 617-873-4119 DOMAIN: jbatson@bbn.com "Parallel processing can be fun!"