From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6745 Path: main.gmane.org!not-for-mail From: "Edward J. Sabol" Newsgroups: gmane.emacs.gnus.general Subject: Re: Is Username Expansion possible in GNUS? Date: Mon, 17 Jun 1996 14:21:09 -0400 Message-ID: <199606171821.OAA21210@thuban.gsfc.nasa.gov> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147157 4601 80.91.224.250 (20 Oct 2002 20:52:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:52:37 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id LAA24363 for ; Mon, 17 Jun 1996 11:46:11 -0700 Original-Received: from thuban.gsfc.nasa.gov (thuban.gsfc.nasa.gov [128.183.127.167]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 17 Jun 1996 20:21:11 +0200 Original-Received: (from sabol@localhost) by thuban.gsfc.nasa.gov (LHEA9504/950407.s1) id OAA21210; Mon, 17 Jun 1996 14:21:09 -0400 Original-To: Gnus Mailing List In-reply-to: (message from Lars Magne Ingebrigtsen on 17 Jun 1996 04:33:36 +0200) Xref: main.gmane.org gmane.emacs.gnus.general:6745 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6745 Excerpts from [ding]: (17-Jun-96) Re: Is Username Expansion possible in GNUS? by Lars Magne Ingebrigtsen > Mark Eichin writes: >> I've often used it (or rather, a different local binding that's been >> around for 5 or 6 years) just to double check that I spelled the username >> right. This is particularly important at a large site, like MIT, where you >> have dozens of smiths and hundreds of chens... and a one character typo >> can often yield a valid username, or worse a mailing list. > > That makes sense. I sure could use it sometimes -- I often send test > mails to myself, and my user name is "larsi". I often forget the "i" > part, and I think the user who has the user name "lars" must be getting > rather tider of getting mail from me. :-) > > We do definitely need getpwnam(3) support in Emacs, then. Anybody want > to write it and send patches to RMS and Chuck? I think all the necessary support is already in mailalias.el which is distributed with Emacs. For /etc/passwd look-ups, check out: (defun mail-get-names (pattern) "Fetch local users and global mail adresses for completion. Consults `/etc/passwd' and a directory service if one is set up via `mail-directory-function'." It doesn't use getpwnam(3); instead it loads /etc/passwd into a buffer and searches that. For large sites, one is more likely to use YP, NIS, NIS+, Ph, or Kerberos to look up such information. In such case, I believe you can even set up arbitrary e-mail address look-up methods by intelligently setting the variables `mail-directory-function', `mail-directory-requery', and `mail-directory-process' to something useful. But maybe I'm wrong. I've never used it that way personally. Check out: (defvar mail-directory-function nil "Function to get completions from directory service or `nil' for none. See `mail-directory-requery'.") ;; This is for when the directory is huge, or changes frequently. (defvar mail-directory-requery nil "When non-`nil' call `mail-directory-function' for each completion. In that case, one argument gets passed to the function, the partial string entered so far.") (defvar mail-directory-process nil "Unix command when `mail-directory-function' is `mail-directory-process'. This is a list of the form (COMMAND ARG ...), where each of the list elements is evaluated. When `mail-directory-requery' is non-`nil', during evaluation the variable `pattern' contains the partial input being completed. This might look like '(remote-shell-program \"HOST\" \"-nl\" \"USER\" \"COMMAND\") or '(remote-shell-program \"HOST\" \"-n\" \"COMMAND '^\" pattern \"'\")") This probably isn't as user-friendly as it could be. For example, something like a YP/NIS look-up could probably be offered as a default method. Then users could just set some variables to the hostname of their YP/NIS server. Later, Ed