jmr@predator.austin.ibm.com (07/24/90)
ATK has been around for some time. It has many of the features that people want in a computing environment. Can anyone comment on why it is not more widely used and/or accepted? -- Jim Rowan (My ravings are my own, and are no fault of my employer.) cs.utexas.edu!ibmchs!jrowan
Craig_Everhart@TRANSARC.COM (07/25/90)
My $.02. It's a big pill to swallow; it's hard to move to ATK piecemeal. It currently requires dynamic loading before it will work on an architecture. It requires an on-site wizard to keep it working. Craig
bader+@ANDREW.CMU.EDU (Miles Bader) (07/25/90)
Because it isn't being promoted as a standard by some huge wacko group of clueless business computer users. [note that its merits, whatever they may be, have nothing to do with the likelihood of being selected by the above process] -Miles
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/25/90)
Excerpts from internet.info-andrew: 24-Jul-90 Re: Why isn't ATK more wide.. Craig_Everhart@transarc. (213+0) > It's a big pill to swallow; it's hard to move to ATK piecemeal. > It currently requires dynamic loading before it will work on an architecture. > It requires an on-site wizard to keep it working. All true, and I'd add 2 more: -- It isn't supported by any vendors or consortia. -- It's "reinvent the world" approach means that there are many places where you could imagine it being compatible with something else, but it isn't. Notably, it isn't compatible with any other mail system database formats, or with any other multimedia document formats (such as they are). I guess this is really just a more detailed version of Craig's "it's a big pill" answer, but lack of compatibility deserves special mention. -- Nathaniel
tlwells@lynn.austin.ibm.COM (Tracy Wells) (07/25/90)
I've wondered the same thing many times. I've also wondered about X11 and about AFS. What is it about those 2 "products" that has caused them to be embraced across the industry (as much as anything gets embraced in the Unix world)? What was done differently for those 2 products? Any insights from MIT about X11? How about from Transarc about AFS? Tracy Wells
janssen@parc.xerox.com (Bill Janssen) (07/25/90)
I've been working with Andrew for a couple of years now, outside the ITC and CMU environment, and I've come up with one big reason. While ATK is a very broad and comprehensive environment, and the best thing I've seen in terms of an X11/Unix environment (which excludes things like Cedar, SmallTalk, the Macintosh, and Interlisp), it is too shallow. By this I mean that ordinary users (outside the CMU environment) keep tripping over things in ATK that make them turn to other tools. For example: - almost no one around here uses typescript, the official ATK tool for running shells in, because it does not support rlogin or curses-oriented programs. There is no officially supported terminal emulator program in ATK. tm, the contrib terminal emulator, does not emulate a vt100, the way that xterm does, and it loses the ability to use cut/paste etc., when being used by a curses program. (Which makes some sense, but it annoys people who are rlog'ed in to some other machine, and want to cut and paste the way they do with an rlog'ed in xterm.) Most people here use xterm instead of typescript or tm, just because of the rlogin problem. - when the R4 help tool came out, it core-dumped almost every time a man page was requested. After having that happen to them 3 or 4 times, most pioneers around here turned to xman instead, and have never turned back. This has the added effect of making the documentation on ATK harder for them to read, since they are not used to help. I myself have `man' aliased to `/bin/man $* | col -b | pipescript'. I really enjoyed help under R3, but it got too Byzantine and unpredictable under R4. - textview is a fairly reasonable text editor. Unfortunately, it does not support undo, which in modern emacs-style text editors is a must. In general around here, most people need two editors, a code editor and a document editor. ez is sort of both, but not really good enough at either to beat out GNU Emacs for the code editing job (no undo, hard to share/change/customize modes, what's the analogue of M-x recover-file?), and FrameMaker or Publisher for the document job (no virtual-paper mode). I use GNU Emacs for code, ez for documents. - Most people would like to have a good drawing editor on the Sun -- a simple MacDraw clone. ATK provides zip, which is an extremely idiosyncratic drawing editor (apparently actually designed to support the Great American History Machine, not as a drawing editor). zip was plagued by unfortunated interactions with the R3 and early R4 X servers, which would cause the server to core-dump when various standard zip demos were performed. Which made one's whole world disappear. People learned early on not to use zip. Nowadays, zip still has bugs, such as not wrapping itself in an ATK datastream when invoked at the top level, and having an extremely bad menu layout. Most people here go to the Mac to produce figures, or use the graphics editor in FrameMaker. - table, the ATK spreadsheet, was eagerly adopted by some people here. After some early crashes due to impossible-to-reproduce malloc bugs (apparently a bad pointer being passed to realloc), they learned to steer clear of it. Now they use a spreadsheet on a Mac, or use the sc public domain curses-oriented spreadsheet in an xterm. - printing for all of ATK is very delicate. It requires that one have AT&T ditroff, and Adobe's transcript package. Most people who don't have these also have trouble getting money to purchase them for this experimental ATK system. - no new user appreciates ATK menus. So if you look at what might be considered a ``full-Andrew'' environment (console, messages, typescript, help, ez-textview-zip-raster-table), the only things that really make the grade are console and messages. Of course, messages uses umpty-zillion inodes (every message in a separate file) and hides your mail in files that are hard to run grep on, and console causes some of our Sun-4/330's to lock up in some low level assembly language routine. But even so they are judged more of a win than a nuisance. A typical X screen around here might have: messages, console, one or two GNU Emacs', a FrameMaker control strip, one or two xterms, an xbiff, and an xman. Some people use rmail in GNU Emacs instead of messages. There is no good way to read USENET news with ATK, so you have to run xrn or Emacs gnus or rn in an xterm (tm doesn't work with it too well). By the way, I have set up messages to read news and discontinued it after a month. It uses unbelievable amounts of CPU to run CUI scripts to do the indexing, and the interface through messages is clumsy for certain operations (posting a followup, for example). Now, if you're just going to run messages and console, ATK requires a lot of disk and a lot of intellectual effort, to get everything running. Maybe too much, for the payback. Bill
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/25/90)
Excerpts from internet.info-andrew: 24-Jul-90 Re: Why isn't ATK more wide.. Bill Janssen@parc.xerox. (4883+0) > - when the R4 help tool came out, it core-dumped almost every time a man > page was requested. After having that happen to them 3 or 4 times, most > pioneers around here turned to xman instead, and have never turned back. > This has the added effect of making the documentation on ATK harder for > them to read, since they are not used to help. I myself have `man' > aliased to `/bin/man $* | col -b | pipescript'. I really enjoyed help > under R3, but it got too Byzantine and unpredictable under R4. Yeah, that was bad. It has gotten reliable again with later patches, but I can understand your giving up. > - no new user appreciates ATK menus. Well, that may be true if you define "new user" to mean "someone who is used to Motif (or Macintosh, or whatever) menus and doesn't want to learn something new. But the ITC did a lot of real testing of what I consider "new users" -- people without preconceptions -- and that's how the ATK menus were chosen. So while I personally think that ATK menus should be changed to match Motif menus, I think so because the latter are becoming standard, not because they're intrinsically easier to use -- I still suspect that the truth is the opposite. Most of your other comments ring true to me. -- Nathaniel
guy@auspex.auspex.com (Guy Harris) (07/26/90)
>It currently requires dynamic loading before it will work on an architecture.
And even if your OS supplies run-time dynamic linking (as more UNIX
versions, for example, seem to be doing), which would probably obviate
the need to do much work making "doload.c" (there might even be one
that'd be portable among all SunOS 4.1/S5R4 implementations that
provided "dlopen()" and company, for example), I think you still need to
whip up assembler code for all the "ClassEntryN" thingies. datri@convex.com (Anthony A. Datri) (07/26/90)
>ATK. tm, the contrib terminal emulator, does not emulate a vt100, the >way that xterm does, and it loses the ability to use cut/paste etc., >when being used by a curses program. I couldn't even get curses/termcap programs to display correctly inside of tm. >- printing for all of ATK is very delicate. It requires that one have >AT&T ditroff, and Adobe's transcript package. Wouldn't another *roff clone work as well? How's Transcript required? >only things that really make the grade are console and messages. Outside of an AFS environment, console doesn't even seem that useful. >course, messages uses umpty-zillion inodes (every message in a separate >file) Don't many other unix UMA's do that? I'm fairly sure that at least MH does. > and hides your mail in files that are hard to run grep on This is quite true. It's not just grep either -- anything that wants to interpret the leading + as a switch causes problems. >Now, if you're just going to run messages and console, ATK requires a >lot of disk and a lot of intellectual effort, to get everything running. I would have liked more information about the whole mail-locking issue when I set it up here. I *still* don't fully understand the issues about mailbox locking, which is why I haven't announced the availability of messages here. /var/spool/mail would be NFS mounted, and while I haven't had any obvious problems on my workstation, I can't encourage my users to use something that might lose their mail when it interacts with binmail on the mail server. --
lyndon@cs.athabascau.ca (07/27/90)
> >- printing for all of ATK is very delicate. It requires that one have > >AT&T ditroff, and Adobe's transcript package. > > Wouldn't another *roff clone work as well? How's Transcript required? Presumably the only ditroff facility required is the ability to embed postscript source within the troff document. GNU roff provides this facility, and I'm looking at using it as a replacement *roff backend.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/27/90)
Excerpts from internet.info-andrew: 26-Jul-90 Re: Why isn't ATK more wide.. Anthony A. Datri@uunet.u (1545) > I would have liked more information about the whole mail-locking issue > when I set it up here. I *still* don't fully understand the issues > about mailbox locking, which is why I haven't announced the availability > of messages here. /var/spool/mail would be NFS mounted, and while I > haven't had any obvious problems on my workstation, I can't encourage my > users to use something that might lose their mail when it interacts with binmail on the mail server. AMS won't hurt you with having /var/spool/mail NFS-mounted, but sendmail/binmail will/might. You're living very dangerously if you're letting normal sendmail/binmail deliver mail into spool files on NFS. I recommend against it. However, if you're already doing that, I don't think AMS can make things any worse. -- Nathainel
cmf@UNIX.CIS.PITT.EDU ("Carl M. Fongheiser") (07/27/90)
Excerpts from info-andrew: 26-Jul-90 Re: Why isn't ATK more wide.. Anthony A. Datri@uunet.u (1545) > >- printing for all of ATK is very delicate. It requires that one have > >AT&T ditroff, and Adobe's transcript package. > Wouldn't another *roff clone work as well? How's Transcript required? I haven't tried it, but groff ought to work. It has all the functionality needed, though not necessarily compatibly. Maybe I'll try that this afternoon... > >only things that really make the grade are console and messages. > Outside of an AFS environment, console doesn't even seem that useful. I'd have to agree with that. I can't even get console to stay running on my PMAX! > >course, messages uses umpty-zillion inodes (every message in a separate > >file) > Don't many other unix UMA's do that? I'm fairly sure that at least MH does. Yes, it does, and it's relatively trivial to turn an MH folder into an AMS folder. > >Now, if you're just going to run messages and console, ATK requires a > >lot of disk and a lot of intellectual effort, to get everything running. > I would have liked more information about the whole mail-locking issue when > I set it up here. I *still* don't fully understand the issues about mailbox > locking, which is why I haven't announced the availability of messages here. > /var/spool/mail would be NFS mounted, and while I haven't had any obvious > problems on my workstation, I can't encourage my users to use something > that might lose their mail when it interacts with binmail on the mail server. Depending on the version and OS you're running, it might work or it might not. 'flock' definitely does *not* work over NFS, and you'll run into trouble if you try to do it that way. One of the many reasons we're looking at AFS here. Carl Fongheiser cmf@unix.cis.pitt.edu
gk5g+@ANDREW.CMU.EDU (Gary Keim) (07/27/90)
Excerpts from misc: 27-Jul-90 Re: Why isn't ATK more wide.. "Carl M. Fongheiser"@uni (1801+0) > I'd have to agree with that. I can't even get console to stay running > on my PMAX! We've recently discovered a bug on the dynamic loading code for the pmax that results in console leaving rudely. It will be out in the next patch but if anyone wants it sooner send me mail and I get it to you. Gary Keim ATK Group
datri@convex.com (Anthony A. Datri) (07/28/90)
>AMS won't hurt you with having /var/spool/mail NFS-mounted, but >sendmail/binmail will/might. You're living very dangerously if you're >letting normal sendmail/binmail deliver mail into spool files on NFS. I >recommend against it. What I've got is /var/spool/mail mounted from the server, which is where mail is also directed via an alias. My concern is that AMS/Messages might read /var/spool/mail/datri (for example) and truncate it at the same time that binmail on the server is trying to deliver new mail into that mailbox. The client machine's sendmail.cf has Sun's "OR" flag set so that local mail is sent to the server's sendmail instead of the local one. Thus, local binmail and sendmail never write. --
he@idt.unit.no (Haavard Eidnes) (07/29/90)
In article <kag5Vkk_V0001KrkZs@unix.cis.pitt.edu> cmf@UNIX.CIS.PITT.EDU ("Carl M. Fongheiser") writes: >> Wouldn't another *roff clone work as well? How's Transcript required? > >I haven't tried it, but groff ought to work. It has all the >functionality needed, though not necessarily compatibly. Maybe I'll try >that this afternoon... Ok, several other seem to think the way I do... I've tried to make groff work with ATK documents. Below follows the changes I've done so far. Apply at own risk. I've yet to be able to print a combined graphics and text document, but I am able to print pure text documents and pure raster images. I do not have the time to continue working on this, so I would appreciate it if someone else picked this up and continued. Regards, Havard Eidnes ------------------------------ Cut here: #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # README # patches # atk_print # This archive created: Sat Jul 28 19:21:47 1990 export PATH; PATH=/bin:/usr/bin:$PATH if test -f 'README' then echo shar: "will not over-write existing file 'README'" else cat << \SHAR_EOF > 'README' Preliminary try at supporting printing ATK documents with groff. Explanation of changes: atk/text/tmac.atk: .po change apparently needed because .po occurs outside of a .de .. section. groff complains otherwise. Add knowledge of "ps" printertype. Non-space mode has to be turned off for spacing to work. Since we use the \X'ps:import' primitive, and the postscript image is imported with its lower left corner at the current troff output position, we have to space forward appropriately. I don't understand what this testing for number register .j is all about. My doc (Sun's) says it's something to do with adjust mode, but why would a picture be positioned elsewhere due to different adjustment modes? Also my doc doesn't mention what the different values of .j are supposed to mean. Since the perl program makes some guesses (that troffadjust will be defined to { pop 0 }), the conditional code should perhaps be changed to unconditional? Anyway, it's difficult to convey to the perl program what adjustment mode will be used... I just comment out the PB and PE macro calls, since we won't be using Transcript. atk/text/txttroff.c: Changes are straight-forward -- just change of font names. atk_print: Perl program which splits out imbedded postscript in ditroff style and constructs the (hopefully) appropriate \X'ps:import' statement. After running groff deletes the constructed input files. Yes, my inexperience with using perl probably shows here... I'd be glad if someone else turned this into something that worked for combined documents! he@idt.unit.no, 28 Jul 1990 SHAR_EOF fi if test -f 'patches' then echo shar: "will not over-write existing file 'patches'" else cat << \SHAR_EOF > 'patches' *** /tmp/,RCSt1a18173 Sat Jul 28 20:07:47 1990 --- atk/text/tmac.atk Thu Jul 26 22:31:31 1990 *************** *** 91,95 **** .. . \" default footer string definitions ! .po +\\n(INu . \" BT -- Bottom trap handling .de BT --- 91,95 ---- .. . \" default footer string definitions ! .po +\n(INu . \" BT -- Bottom trap handling .de BT *************** *** 353,358 **** --- 353,361 ---- .if "\*(.T"postscript" 'nr zT 1 .if "\*(.T"psc" 'nr zT 1 + .if "\*(.T"ps" 'nr zT 1 .de PB 'ne \\$2p + 'rs + 'sp \\$2p 'nr zw \\n(.l-\\n(.k-1m-\\$1p 'nr zH \\n(.k *************** *** 369,383 **** .sp |\\n(zVu 'if ((\\n(zx<=0)&(\\$2p>0.75v)) \\x'\\$2p-0.75v'\\c ! \\!% ! \\!%! ! \\! PB 'if \\n(.j=3 \\{\\ ! \\! /troffadjust { neg 2 idiv } def 'ss\\} 'if \\n(.j=5 \\{\\ ! \\! /troffadjust { neg } def 'ss\\} 'if \\n(.j<3 \\{\\ ! \\! /troffadjust { pop 0 } def 'ss\\}\\} .. --- 372,386 ---- .sp |\\n(zVu 'if ((\\n(zx<=0)&(\\$2p>0.75v)) \\x'\\$2p-0.75v'\\c ! .\" \\!% ! .\" \\!%! ! .\" \\! PB 'if \\n(.j=3 \\{\\ ! \X'ps:exec userdict beginn /troffadjust { neg 2 idiv } def end' 'ss\\} 'if \\n(.j=5 \\{\\ ! \X'ps:exec userdict begin /troffadjust { neg } def end' 'ss\\} 'if \\n(.j<3 \\{\\ ! \X'ps:exec userdict begin /troffadjust { pop 0 } def end' 'ss\\}\\} .. *************** *** 384,389 **** .de PE 'if \\n(zT \\{\\ ! \\! PE ! \\!. 'ie \\n(zx \\{\\ 'if (\\$2p>0.75v) \\x'\\$2p-0.75v'\\c --- 387,392 ---- .de PE 'if \\n(zT \\{\\ ! .\" \\! PE ! .\" \\!. 'ie \\n(zx \\{\\ 'if (\\$2p>0.75v) \\x'\\$2p-0.75v'\\c *** /tmp/,RCSt1a18179 Sat Jul 28 20:08:43 1990 --- atk/text/txttroff.c Tue Jul 24 12:52:35 1990 *************** *** 133,143 **** /* All shadowface is bold for now */ } fonttable[] = { ! {"timesroman", {"R", "I", "B", "BI", "C", "CO", "CB", "CD", "B"}}, ! {"helvetica", {"H", "HO", "HB", "HD", "C", "CO", "CB", "CD", "B"}}, ! {"andy", {"R", "I", "B", "BI", "C", "CO", "CB", "CD", "B"}}, ! {"andysans", {"H", "HO", "HB", "HD", "C", "CO", "CB", "CD", "B"}}, ! {"andytype", {"C", "CO", "CB", "CD", "C", "CO", "CB", "CD", "C"}}, ! {"gacha", {"C", "CO", "CB", "CD", "C", "CO", "CB", "CD", "C"}}, ! {0, {"R", "I", "B", "BI", "C", "CO", "CB", "CD", "B"}} /* default for unknown family */ }; --- 133,143 ---- /* All shadowface is bold for now */ } fonttable[] = { ! {"timesroman", {"R", "I", "B", "BI", "CR", "CI", "CB", "CBI", "B"}}, ! {"helvetica", {"HR", "HI", "HB", "HBI", "CR", "CI", "CB", "CBI", "B"}}, ! {"andy", {"R", "I", "B", "BI", "CR", "CI", "CB", "CBI", "B"}}, ! {"andysans", {"HR", "HI", "HB", "HBI", "CR", "CI", "CB", "CBI", "B"}}, ! {"andytype", {"CR", "CI", "CB", "CBI", "CR", "CI", "CB", "CBI", "CR"}}, ! {"gacha", {"C", "CO", "CB", "CD", "CR", "CI", "CB", "CBI", "CR"}}, ! {0, {"R", "I", "B", "BI", "CR", "CI", "CB", "CBI", "B"}} /* default for unknown family */ }; SHAR_EOF fi if test -f 'atk_print' then echo shar: "will not over-write existing file 'atk_print'" else cat << \SHAR_EOF > 'atk_print' #!/local/bin/perl $mainfile = "/tmp/atk_main.$$"; $outfile = "/tmp/atk_ps.$$"; $template = "/tmp/atk_ps_part$$"; open(main,">" . $mainfile) || die "Can't open $mainfile for write!"; $tmp_no = 0; $pb_seen = 0; while(<>) { if($pb_seen) { if(/^\'if/) { printf main $_; $tempfile = $template . "_" . $tmp_no++; open( temp, ">" . $tempfile ) || die "Can't open $tempfile!"; printf main "\\X'ps:import $tempfile %d %d %d %d %d %d'\n", 0, -$height, $width, 0, $width * 1000, $height * 1000; } else { if(/^\'PE/) { $bp_seen = 0; close(temp); printf main "\\}\n" ; printf main $_; } else { if(/^\\}/) { next; } s/\\!//; printf temp $_; } } } else { if(/^\'PB/) { $pb_seen = 1; $line = $_; split; $width = $_[1]; $height = $_[2]; printf main $line; } else { printf main $_; } } } close main; system "groff -C -e -Tps $mainfile"; for( $n = 0; $n < $tmp_no; $n++ ) { unlink($template . "_" . $n); } unlink($mainfile); SHAR_EOF chmod +x 'atk_print' fi exit 0 # End of shell archive
guy@auspex.auspex.com (Guy Harris) (07/29/90)
>I couldn't even get curses/termcap programs to display correctly inside >of tm. I've gotten MicroEMACS to work inside of one (albeit slowly, when running the "tm", the MicroEMACS, and the X11R3 server on the same humble 3/50; the X11R4 server did much better), at least to the limited extent that I tested it. There may well be problems I didn't bump into. >>course, messages uses umpty-zillion inodes (every message in a separate >>file) > >Don't many other unix UMA's do that? I'm fairly sure that at least MH does. Yup, but that just means more UNIX UMAs than just "messages" are a little scary to those of us with auspex% ls -l /usr/spool/mail/guy -rw------- 1 guy 3327379 Jul 28 15:44 /usr/spool/mail/guy auspex% from | wc -l 1500 (and I don't think I could get a disk to myself on the NS5000 upstairs...).
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/30/90)
Excerpts from internet.info-andrew: 27-Jul-90 Re: Why isn't ATK more wide.. Anthony A. Datri@uunet.u (720) > My concern is that AMS/Messages might read /var/spool/mail/datri (for > example) and truncate it at the same time that binmail on the server is > trying to deliver new mail into that mailbox. This is a valid concern, but it is equally valid with ANY mailer that removes things from the spool file. Messages carefully follows the file locking conventions that were established on /usr/spool/mail files in early versions of UNIX. However, these simply DO NOT WORK RELIABLY ON NFS. That's all there is to it. AMS is no worse than any other mail reader in this situation. (Where the spool files are on local disks or AFS, or anything else that supports flock, AMS will be as reliable as any mail reader, and more reliable than the many that don't do proper locking.) You're right to be concerned about locking on /usr/spool/mail files, but you're wrong to think that AMS makes the situation any worse. You should either A. Not have your spool files on NFS (that's what we do at Bellcore), or B. Only use mailers that always leave everything in the spool files, never even deleting messages, which is ridiculous, or C. Give up on reliability. Blaming AMS for this situation is just ridiculous; AMS follows every convention there is regarding the spool file, but there is simply no established way to make the spool file mechanism secure against lost mail in the absence of flock. There are ways I could imagine doing it, but you'd have to modify the delivery program AND all the mail readers. At CMU, we build a whole new delivery system because of problems like this. I'm not saying you should do the same, just don't fool yourself into thinking that this problem has anything to do with using AMS user interfaces and you're safe if you don't use them, because it doesn't and you aren't. -- Nathaniel
datri@convex.com (Anthony A. Datri) (07/31/90)
>NFS. That's all there is to it. AMS is no worse than any other mail >reader in this situation. I know, I know. I didn't mean to imply that AMS was any different. >You're right to be concerned about locking on /usr/spool/mail files, but >you're wrong to think that AMS makes the situation any worse. I don't -- I want to understand the issues for *any* mailer. >A. Not have your spool files on NFS (that's what we do at Bellcore), or I have little choice -- my workstation is diskless, and the machines that have spool/mail and to which aliases are directed are platforms on which ATK doesn't really run. Hence, to use Messages, it's got to be on my workstation, over NFS. >C. Give up on reliability. Granted, I haven't noticed a problem in many months of usage, but I wouldn't feel good about turning it loose for my users without full comprehension. >At CMU, we build a whole new delivery system because of problems like >this. Relies on AFS, though, doesn't it? --
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/31/90)
Excerpts from internet.info-andrew: 30-Jul-90 Re: Why isn't ATK more wide.. Anthony A. Datri@uunet.u (986) > I have little choice -- my workstation is diskless, and the machines > that have spool/mail and to which aliases are directed are platforms on > which ATK doesn't really run. Hence, to use Messages, it's got to be on > my workstation, over NFS. Ah, then what you want to do is the following: 1. Install my "eatmail" program, which simply transfers mail from /usr/spool/mail/nsb into separate files in your Mailbox directory. I sent this to the ITC, but I don't know if they're putting it in a patch or not. If not, I can send you a copy privately. It doesn't use dynamic loading, etc., and hence should be pretty easy to compile anywhere. 2. Set up your sites AndrewSetup file with a line like the following: AMS_MailCollectionCommand: rsh your-mail-mainframe /full/path/to/eatmail This will mean that every time you say "Check New Messages", the eatmail program will be rsh'ed on your mail mainframe. The eatmail program will move your mail into your Mailbox directory on NFS, and all will be well from there. The spool file can stay local to the mainframe, so you won't have to worry about trying to lock files over NFS. I think that should solve your problem -- good luck! -- Nathaniel
howard@THUMPER.BELLCORE.COM (Howard Bussey) (08/01/90)
Excerpts from internet.info-andrew: 31-Jul-90 Re: Why isn't ATK more wide.. Nathaniel Borenstein@thu (1307+0) > ... > 1. Install my "eatmail" program, which simply transfers mail from > /usr/spool/mail/nsb into separate files in your Mailbox directory. I > sent this to the ITC, but I don't know if they're putting it in a patch > or not. If not, I can send you a copy privately. It doesn't use > dynamic loading, etc., and hence should be pretty easy to compile > anywhere. > 2. Set up your sites AndrewSetup file with a line like the following: > AMS_MailCollectionCommand: rsh your-mail-mainframe /full/path/to/eatmail > This will mean that every time you say "Check New Messages", the eatmail > program will be rsh'ed on your mail mainframe. The eatmail program will > move your mail into your Mailbox directory on NFS, and all will be well > from there. The spool file can stay local to the mainframe, so you > won't have to worry about trying to lock files over NFS. > I think that should solve your problem -- good luck! -- Nathaniel I used another approach (with some consultation with Nathaniel) so that my mail went to one machine (thumper.bellcore.com) which has systems administration to make sure it keeps running, but I could read the mail from messages running on a workstation. I simply put the following line in my per-user crontab (USG Unix V5.xx(?) , Sunos 4.0.xx): 1,6,11,16,21,26,31,36,41,46,51,56 * * * * /usr/local/pkg/X11/andrew/bin/cui check\; quit </dev/null >/dev/null 2>&1 (it's all one line) The problem is that this method breaks things like "xbiff". Note that if having xbiff broken isn't a problem, Nathaniel's mail eater could replace this rather kludgy use of cui. I'll be switching to "eatmail" soon. Howard Bussey <howard@thumper.bellcore.com>; Bellcore MRE 2P-288; voice: +201.829.4479; fax: +201.984.2283
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/01/90)
Excerpts from info-andrew: 31-Jul-90 Re: Why isn't ATK more wide.. Howard Bussey@thumper.be (1834+0) > I used another approach (with some consultation with Nathaniel) so that > my mail went to one machine (thumper.bellcore.com) which has systems > administration to make sure it keeps running, but I could read the mail > from messages running on a workstation. I simply put the following line > in my per-user crontab (USG Unix V5.xx(?) , Sunos 4.0.xx): > 1,6,11,16,21,26,31,36,41,46,51,56 * * * * > /usr/local/pkg/X11/andrew/bin/cui check\; quit </dev/null >/dev/null > 2>&1 > (it's all one line) > The problem is that this method breaks things like "xbiff". Note that > if having xbiff broken isn't a problem, Nathaniel's mail eater could > replace this rather kludgy use of cui. I'll be switching to "eatmail" > soon. ... and if having xbiff or console broken IS a problem (it would be for me), you can use a preference: *.PersonalMailCollectionCommand: rsh mail-host-name /full/path/to/eatmail or an AndrewSetupLine: AMS_MailCollection:Command: rsh mail-host-name /full/path/to/eatmail Cheers. -- Nathaniel
janssen@parc.xerox.com (Bill Janssen) (08/01/90)
Perhaps what we need is another version of `xbiff' called `andybiff' which will look at Mailbox rather than /usr/spool/mail/$USER. Then you could have `eatmail' running as a daemon without worrying about it. Bill
grahamd@otc.otca.oz.au (Graham Dumpleton) (08/01/90)
Excerpts from info-andrew: 31-Jul-90 Re: Why isn't ATK more wide.. Nathaniel Borenstein@thu (1307+0) > 1. Install my "eatmail" program, which simply transfers mail from > /usr/spool/mail/nsb into separate files in your Mailbox directory. I > sent this to the ITC, but I don't know if they're putting it in a patch > or not. If not, I can send you a copy privately. It doesn't use > dynamic loading, etc., and hence should be pretty easy to compile > anywhere. We have the Rand Message Handling System (more commonly known as just MH) running on our machines and their inc program does essentially the same thing as eatmail. > 2. Set up your sites AndrewSetup file with a line like the following: > AMS_MailCollectionCommand: rsh your-mail-mainframe /full/path/to/eatmail We just then have AMS_MailCollectionCommand: inc in the AndrewSetup file. If you also run popd then this will even work if you are logged into a machine which is not your maildrop machine. One last thing which we have to do to get this all to work is the following cd ~ ln -s .Mail/inbox Mailbox where .Mail is the directory where MH puts your mail. This is usually Mail but can be redefined in your .mh_profile as we have; ie: we have the following in our .mh_profile Path: .Mail Also we have a number of users who in general prefer to use MH most of the time (NOTE: they will not use cui), and so rather than do as mentioned above; which would result in all mail dissappearing into Andrew, we do the following: folder +mmm # creates new folder in MH cd ~ ln -s .Mail/mmm Mailbox This way, when they get some multimedia mail they can refile it into the mmm folder and then run messages. Graham Dumpleton. (grahamd@otc.otca.oz.au)
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/01/90)
Excerpts from internet.info-andrew: 31-Jul-90 Re: Why isn't ATK more wide.. Bill Janssen@parc.xerox. (216) > Perhaps what we need is another version of `xbiff' called `andybiff' > which will look at Mailbox rather than /usr/spool/mail/$USER. Then you > could have `eatmail' running as a daemon without worrying about it. Well, you sort of already have this -- the Andrew Console program when you tell it you're running AMDS checks this way, of course. The trick is to fool it into thinking that. Unfortunately, it now checks precisely whether or not you're running AMDS to make that determination. If you added a preference to tell console "check Mailbox even though I'm not running AMDS" then you'd get the right mail checking behavior. The fix should be very easy. Right before line 106 of atk/console/cmd/mailmon.c (which says "SetMailEnv()") you could add a line something like this (this is untested): if (UseNonAndrewMail) UseNonAndrewMail = environ_GetProfileSwitch("console.alwayscheckmailboxdir", FALSE); I think that such a single line change would make console work in this situation, but as I said I haven't tested it. -- Nathaniel