tobeye@NORTHSTAR.DARTMOUTH.EDU (Anthony Edwards) (10/26/89)
Soon, we will be switching all of our mail from the /usr/spool/mail on our machines to individual mail on a mail host. Using messages, I know I can set a /usr/andrew/etc/AndrewSetup parameter to specify what program AMS should use in order to read mail. I will be writing that program soon. So far, no problems. However, the program I will be writing will want to ask the user for a password that is required by the mail machine. Is there any way to make messages prompt the user for a password, and give that password to the read-mail program? The only other alternative I see is to have a .readmailrc file in their home directory with their password in it (or some such scheme). Any ideas or suggestions how I might go about doing this? - Anthony Edwards
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (10/26/89)
Well, you've got a bit of a problem. Let me explain why it is harder than you might think. In the general case, you must recall, the user agent program (Messages, CUI, VUI, etc.) is a separate process from the messageserver process, and may even be running on a separate machine. They communicate via SNAP, the RPC package for AMS which is included in the R4 release. Now, the mail-collection-program you referred to is *forked* by *messageserver* rather than a UI program. This means that it may be running on an entirely separate machine from the UI, and therefore can't really do any I/O at all. So, in the general case, what you want simply can't be done. There is some hope, however. If you only ever want to have your users run the "No SNAP" version of AMS, in which the messageserver is linked in to the UI as a single process, then it is possible to break through the layers of the architecture and ask the user a question even from the messageserver code. To do this, you want to use one of the interface- independent user-interaction routines that each interface supplies to the CUI library (the common user interface library used by all of the user interface programs). These routines include one called something like "GetStringFromUser". What you can do is to call "GetStringFromUser" before calling the mail-collection-command, and pass down the results (i.e. an argument an password) on the command line. One problem with this scheme is, as I have stated, that it won't work in the SNAP-ified version of AMS. Another is that the password will undoubtedly be echoed in at least some of the user interfaces. I don't Now, the fourth argument to GetStringFromUser is a boolean "IsPassword" which, if non-zero, tells the UI not to echo the string as the user types it. However, I believe that this value is ignored in some user interfaces, notably Messages itself, because ATK doesn't give any way to get a password without echoing yet. This should be considered a bug in ATK, but I don't know if it will be fixed any time soon. Another problem with the approach outlined above is that it requires you to perform local patches to the messageserver source before recompilation, which is certainly undesirable if it can be avoided. Aha! There's another possibility. Right now, if you run the SNAP-ified source with the preference "AMS_RemoteLogin: machine-name" in your preferences file, it will try to contact a messageserver on the remote machine, but before doing so it will ask you for your id and password on that machine. This happens at program initialization time. It sounds like you could conceivably alter this mechanism to suit your needs. To do this, all you need to do is to alter the Machine_Init routine at your site so that it collects the password and, for example, puts it into an environment variable; the mail-collection-command could then get it out of the environment variable. I think that the only routine you'll need to alter to make this work will be ams/libs/cui/and-machines.c, Machine_Init. That routine will even have some sample code that shows you how to get the password in a way that is interface-independent. Of course, as said before, the password may echo in some interfaces. I hope all this was helpful; please ask for more information if any of it was not sufficiently clear. -- Nathaniel