Re: default components file
Bill Wohler wrote: I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I think that this is the main point. Most mail users (in my experience) want to have a copy of mail that's been sent, for a variety of reasons. For a new user, trying to figure out simple things like this can be daunting, and they might not even realize that they are possible. In any case, when the user doesn't want the feature, figuring out how to delete FCC: +outbox will be easier than figuring out how to add it correctly.
Re: default components file
Ok, I've committed changes to components, forwcomps, distcomps, replcomps, replgroupcomps, based on the discussion. Only repl.man needed to be changed; the other man pages dynamically pull in the current default template file when the man page is built by 'make'.
pick argument order
While trolling for patches, I was pointed to a problem reported by Robert Elz last October. The order of the arguments -list and -seq matters, as mentioned in the man page. In other words, pick -list -seq x and pick -seq x -list do not do the same thing. -seq implicitly means -nolist -seq, so pick -list -seq x and pick -nolist -seq x do the same thing. Should this be changed, or will it break existing front ends to nmh? My reading of the exmh code is that it will not; it adds -list to the end whenever 'pick' is used. Thanks.
Patch for bug #3200 (with patch attached this time)
Jeffery Honig has been unable to subscribe to the mailing list. He'd like any
comments any one has about his proposed patch. You should mail the comments
directly to him:
Jeffrey C Honig [EMAIL PROTECTED]
Index: h/fmt_scan.h
===
RCS file: /cvsroot/nmh/nmh/h/fmt_scan.h,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 fmt_scan.h
--- h/fmt_scan.h 30 Apr 1999 18:08:34 - 1.1.1.1
+++ h/fmt_scan.h 27 Jun 2003 22:53:59 -
@@ -37,6 +37,13 @@
#define CT_MYMBOX (12) /* mymbox test being done */
#define CT_ADDRPARSE (13) /* address parse being done */
+/*
+ * c_flags bits
+ */
+#define CF_TRUE(10) /* usually means component is present */
+#define CF_ADDRPARSED (20) /* address has been parsed */
+#define CF_DATEFAB (30) /* datefield fabricated */
+
extern int fmt_norm;
/*
Index: sbr/fmt_compile.c
===
RCS file: /cvsroot/nmh/nmh/sbr/fmt_compile.c,v
retrieving revision 1.5
diff -u -u -r1.5 fmt_compile.c
--- sbr/fmt_compile.c 2 Jul 2002 22:09:14 - 1.5
+++ sbr/fmt_compile.c 27 Jun 2003 22:53:59 -
@@ -443,12 +443,10 @@
if (cm-c_type CT_DATE) {
CERROR(component used as both date and address);
}
- if (! (cm-c_type CT_ADDRPARSE)) {
- cm-c_mn = fmt_mnull;
- fp-f_type = preprocess;
- PUTCOMP(sp);
- cm-c_type |= (CT_ADDR | CT_ADDRPARSE);
- }
+ cm-c_mn = fmt_mnull;
+ fp-f_type = preprocess;
+ PUTCOMP(sp);
+ cm-c_type |= (CT_ADDR | CT_ADDRPARSE);
break;
case FT_FORMATADDR:
Index: sbr/fmt_scan.c
===
RCS file: /cvsroot/nmh/nmh/sbr/fmt_scan.c,v
retrieving revision 1.7
diff -u -u -r1.7 fmt_scan.c
--- sbr/fmt_scan.c 2 Jul 2002 22:09:14 - 1.7
+++ sbr/fmt_scan.c 27 Jun 2003 22:54:00 -
@@ -490,7 +490,7 @@
break;
case FT_LV_COMPFLAG:
- value = fmt-f_comp-c_flags;
+ value = (fmt-f_comp-c_flags CF_TRUE) != 0;
break;
case FT_LV_COMP:
value = (comp = fmt-f_comp)-c_text ? atoi(comp-c_text) : 0;
@@ -712,10 +712,10 @@
comp = fmt-f_comp;
if ((sp = comp-c_text) (tws = dparsetime(sp))) {
*comp-c_tws = *tws;
- comp-c_flags = 0;
- } else if (comp-c_flags = 0) {
+ comp-c_flags = ~CF_TRUE;
+ } else if ((comp-c_flags CF_DATEFAB) == 0) {
memset ((char *) comp-c_tws, 0, sizeof *comp-c_tws);
- comp-c_flags = 1;
+ comp-c_flags = CF_TRUE;
}
break;
@@ -779,6 +779,9 @@
case FT_PARSEADDR:
comp = fmt-f_comp;
+ if (comp-c_flags CF_ADDRPARSED)
+ break;
+ comp-c_flags |= CF_ADDRPARSED;
if (comp-c_mn != fmt_mnull)
mnfree (comp-c_mn);
if ((sp = comp-c_text) (sp = getname(sp))
@@ -805,15 +808,22 @@
if ((sp = comp-c_text) (sp = getname(sp))
(mn = getm (sp, NULL, 0, AD_NAME, NULL))) {
comp-c_mn = mn;
- comp-c_flags = ismymbox(mn);
+ if (ismymbox(mn))
+ comp-c_flags |= CF_TRUE;
+ else
+ comp-c_flags = ~CF_TRUE;
while ((sp = getname(sp)))
- if (comp-c_flags == 0
+ if ((comp-c_flags CF_TRUE) == 0
(mn = getm (sp, NULL, 0, AD_NAME, NULL)))
- comp-c_flags |= ismymbox(mn);
+ if (ismymbox(mn))
+ comp-c_flags |= CF_TRUE;
} else {
while (getname()) /* XXX */
;
- comp-c_flags = (comp-c_text == 0);
+ if (comp-c_text == 0)
+ comp-c_flags |= CF_TRUE;
+ else
+ comp-c_flags = ~CF_TRUE;
comp-c_mn = fmt_mnull;
}
break;
Index: uip/fmtdump.c
===
RCS file: /cvsroot/nmh/nmh/uip/fmtdump.c,v
retrieving revision 1.5
diff -u -u -r1.5 fmtdump.c
--- uip/fmtdump.c 2 Jul 2002 22:09:14 - 1.5
+++ uip/fmtdump.c 27 Jun 2003 22:54:00 -
@@ -39,6 +39,7 @@
static void assignlabel(struct format *);
static char *f_typestr(int);
static char *c_typestr(int);
+static char *c_flagsstr(int);
static void litputs(char *);
static void litputc(char);
@@ -163,7 +164,7 @@
if (fmt-f_comp-c_type)
printf(, c_type %s, c_typestr(fmt-f_comp-c_type));
if (fmt-f_comp-c_flags)
- printf(, c_flags %d, fmt-f_comp-c_flags);
+ printf(, c_flags %s, c_flagsstr(fmt-f_comp-c_flags));
break;
case FT_LV_SEC:
@@ -195,7 +196,7 @@
if (fmt-f_comp-c_type)
printf(, c_type %s, c_typestr(fmt-f_comp-c_type));
if (fmt-f_comp-c_flags)
- printf(, c_flags %d, fmt-f_comp-c_flags);
+ printf(, c_flags %s, c_flagsstr(fmt-f_comp-c_flags));
break;
case FT_LS_ADDR:
@@ -217,7 +218,7 @@
if (fmt-f_comp-c_type)
printf(, c_type %s, c_typestr(fmt-f_comp-c_type));
if (fmt-f_comp-c_flags)
- printf(, c_flags %d, fmt-f_comp-c_flags);
+ printf(, c_flags %s, c_flagsstr(fmt-f_comp-c_flags));
break;
case FT_COMPF:
@@ -228,7 +229,7 @@
if (fmt-f_comp-c_type)
printf(, c_type %s, c_typestr(fmt-f_comp-c_type));
if (fmt-f_comp-c_flags)
- printf(, c_flags %d, fmt-f_comp-c_flags);
+ printf(, c_flags %s,
Request for comment: update to mh-format.5
Bart Massey submitted an update to the mh-format man page as part of
bug report 2031. I'm not an expert on the content, but it looks like
he's done a good job at improving this page.
Please review it, and if there are no corrections, I plan to commit it.
Thanks.
Name
mh-format - format file for nmh message system
Synopsis
some nmh commands
Description
Several nmh commands utilize either a format string or a
format file during their execution. For example, scan
uses a format string which directs it how to generate the
scan listing for each message; repl uses a format file
which directs it how to generate the reply to a message,
and so on.
Format strings are designed to be efficiently parsed by
nmh which means they are not necessarily simple to write
and understand. This means that novice, casual, or even
advanced users of nmh should not have to deal with them.
There are a few alternate scan listing formats available
in /etc/nmh/scan.time, /etc/nmh/scan.size, and
/etc/nmh/scan.timely. Look in /etc/nmh for other scan and
repl format files which may have been written at your
site.
It suffices to have your local nmh expert actually write
new format commands or modify existing ones. This manual
section explains how to do that. Note: familiarity with
the C printf routine is assumed.
A format string consists of ordinary text, and special
multi-character escapesequences which begin with `%'.
When specifying a format string, the usual C backslash
characters are honored: `\b', `\f', `\n', `\r', and `\t'.
Continuation lines in format files end with `\' followed
by the newline character.
SYNTAX
Format strings are built around escape sequences. There
are three types of escape sequences: header components,
built-in functions, and flow control. Comments may be
inserted in most places where a function argument is not
expected. A comment begins with `%;' and ends with a
(non-escaped) newline.
A component escape is specified as `%{component}', and
exists for each header found in the message being pro-
cessed. For example `%{date}' refers to the Date: field
of the appropriate message. All component escapes have a
string value. Normally, component values are compressed
by converting any control characters (tab and newline
included) to spaces, then eliding any leading or multiple
spaces. However, commands may give different interpreta-
tions to some component escapes; be sure to refer to each
command's manual entry for complete details.
A function escape is specified as `%(function)'. All
functions are built-in, and most have a string or numeric
value. A function escape may have an argument. The argu-
ment follows the function escape: separating whitespace is
discarded: `%(function argument)'.
The argument to a function escape is processed in argument
mode. A function or component escape evaluated in argu-
ment mode should not be preceded by a leading `%'. Condi-
tional escapes (see below) are allowed, and are entered
normally.
Control-flow escapes
A control escape is one of: `%', `%?', `%|', or `%'.
These are combined into the conditional execution con-
struct:
% condition format-text
%? condition format-text
...
%| format-text
%
Extra white space is shown here only for clarity. These
constructs may be nested without ambiguity. They form a
general if-elseif-else-endif block where only one of the
format-texts is interpreted.
A `%' or `%?' control escape causes its condition to be
evaluated. This condition is a component or function
escape evaluated in argument mode. The control escape
tests whether the function or component escape evaluates
non-zero (for an integer-valued escape) or non-empty (for
a string-valued escape).
If the condition of a `%' or `%?' control escape
evaulates true, or a `%|' escape is encountered, then the
format-text of that escape (up to the next corresponding
`%|', `%?', or `%' control escape) is interpreted nor-
mally. Text up to the corresponding `%' control escape is
then skipped, and the `%' control escape is discarded.
If the condition of a `%' or `%?' control escape evalu-
ates false, however, the format-text (up to the next cor-
responding `%|', `%?', or `%' control escape) is skipped
instead of being
Should nmh be RFC 2822 compliant (bug report #3356)
Apparently the powers that be don't want informational messages to be part of the 'In-Reply-To: fields anymore (http://www.faqs.org/rfcs/rfc2822.html). The obsolete fields could look like: In-reply-to: Your message of Fri, 27 Jun 2003 13:35:24 EDT. [EMAIL PROTECTED] which is what nmh puts in by default. Now only the information in the angle brackets is to be supplied. Should we change this? Thanks.
Bug #562: mailing lists
Does anyone know the status of mailing lists? This request from 8/02 was for a user's mailing list.
patches for Solaris 8 and Mandrake 9.1
Attached is a patch for the problems I found with Solaris 8 and Mandrake 9.1 I've been trying to get a GNU Savannah login, but it looks like they are down tonight. It turns out that there are two database packages available with the Mandrake distribution that support 'ndbm' calls: db1 (derived from Berkeley code), and GNU gdbm. I've used the gdbm versions of the ndbm calls for years, with no trouble. I can't remember which one got linked in with nmh when I built it last year. I think that it's a safe bet that either will work. The 'configure.in' script will test for libdbm.a, libdb1.a, and libgdbm.a, in that order, and pull 'ndbm.h' from /usr/include/db1 or /usr/include/gdbm. I've chosen to remove diversion of standard error to /dev/null for the broken vi test, so Solaris systems with 'vim' installed don't hang. Since the variables used in the definition of MAN1, et al, in man/Makefile don't get changed after the definition, I don't believe that there's any harm in changing := to =, which allows the makefile to work with Solaris make and GNU make. The patch gets applied with patch -b -p1 misc-build.patch, so man/Makefile.in gets changed, not the top level Makefile.in. So if you could, please apply these patches and make an RC2 for folks to try out. Thanks.*** old/uip/slocal.c 2002-07-02 18:09:15.0 -0400 --- ./uip/slocal.c 2003-06-08 19:18:08.0 -0400 *** *** 52,59 --- 52,63 #ifdef HAVE_DB1_NDBM_H #include db1/ndbm.h #else + #ifdef HAVE_GDBM_NDBM_H + #include gdbm/ndbm.h + #else #include ndbm.h #endif + #endif #include utmp.h *** old/config.h.in 2002-07-03 10:52:01.0 -0400 --- ./config.h.in 2003-06-08 19:30:24.0 -0400 *** *** 279,284 --- 279,287 /* Define if your system has db1/ndbm.h instead of ndbm.h (ppclinux) */ #undef HAVE_DB1_NDBM_H + /* Define if your system has gdbm/ndbm.h instead of ndbm.h */ + #undef HAVE_GDBM_NDBM_H + /* Define to the header containing the declaration of initgroups() on your system, if any. AIX 4.[13], SunOS 4.1.3, and ULTRIX 4.2A have the function in libc but don't have a declaration anywhere. */ *** old/man/Makefile.in 2001-01-19 16:22:08.0 -0500 --- ./man/Makefile.in 2003-06-08 19:10:46.0 -0400 *** *** 71,79 MAN8SRC = ap. conflict. dp. fmtdump. \ install-mh. mh-mts. post. ! MAN1 := $(MAN1SRC:.=.$(manext1)) ! MAN5 := $(MAN5SRC:.=.$(manext5)) ! MAN8 := $(MAN8SRC:.=.$(manext8)) # Since vmh is not built or distributed, neither should vmh.1 be # MANEXTRA = vmh. --- 71,79 MAN8SRC = ap. conflict. dp. fmtdump. \ install-mh. mh-mts. post. ! MAN1 = $(MAN1SRC:.=.$(manext1)) ! MAN5 = $(MAN5SRC:.=.$(manext5)) ! MAN8 = $(MAN8SRC:.=.$(manext8)) # Since vmh is not built or distributed, neither should vmh.1 be # MANEXTRA = vmh. *** ./old/configure.in 2002-07-03 10:15:29.0 -0400 --- ./configure.in 2003-06-08 20:29:32.0 -0400 *** *** 364,370 dnl Check for broken vi AC_CACHE_CHECK(for broken vi, nmh_cv_attvibug, [if echo 'r /nonexist-file ! q' | ex /dev/null 21 then nmh_cv_attvibug=no else --- 364,370 dnl Check for broken vi AC_CACHE_CHECK(for broken vi, nmh_cv_attvibug, [if echo 'r /nonexist-file ! q' | ex /dev/null then nmh_cv_attvibug=no else *** *** 553,564 dnl Checks for ndbm AC_CHECK_FUNC(dbm_open, , AC_CHECK_LIB(ndbm, dbm_open, , ! AC_CHECK_LIB(dbm, dbm_open))) dnl dnl CHECK FOR NDBM.H dnl ! AC_CHECK_HEADERS(db1/ndbm.h) dnl dnl CHECK FOR HESIOD --- 553,567 dnl Checks for ndbm AC_CHECK_FUNC(dbm_open, , AC_CHECK_LIB(ndbm, dbm_open, , ! AC_CHECK_LIB(dbm, dbm_open, , ! AC_CHECK_LIB(db1, dbm_open, , ! AC_CHECK_LIB(gdbm, dbm_open) dnl dnl CHECK FOR NDBM.H dnl ! AC_CHECK_HEADERS(db1/ndbm.h, , ! AC_CHECK_HEADERS(gdbm/ndbm.h)) dnl dnl CHECK FOR HESIOD
Re: Solaris 'vim' configure bug
On Thursday 05 June 2003 04:52 pm, Jerry Peek wrote: On 5 June 2003 at 15:40, Glenn Burkhardt [EMAIL PROTECTED] wrote: Advice? I feel our momentum slowing here; thanks for waking us up, Glenn. Let's avoid waiting six more months until Jon has to nag us again! There are a few problems, like the Mandrake ndbm.h file location, that don't sound too tough to fix. The longer we wait to release, the more little problems like this will come up. Maybe we should make a fix or two, release 1.1, and then post patches (or start pushing for nmh 1.11) as new OS versions dribble out. Should nmh be 100% perfect before it's released? (Am I a heretic or what? :) A heretic. But I have no problem with declaring nmh 1.1rc1 a release, and let it go. About the vi test: How about a compromise? Does it gain users a lot to have nmh test the editor's exit status and discard the draft on a nonzero exit? If the user or the editor has some kind of error, won't that be obvious to the user -- so she can type q d at the What now? prompt to throw away the bogus draft? (Does exmh or MH-E depend on this error-exit facility?) After thinking about this on my drive home, it seems simpliest to eliminate the 21 at the end of the line. It looks like almost all 'vi' versions write messages to stdout, not stdin. And if they don't, the downside is that there's a funny message that comes out during 'configure'. I've checked this now with SunOS 'vi' (very old, BSD derivative), 'vim' (which is probably what all Linux, FreeBSD, and NetBSD systems use), and Solaris 'vi' (probably as generically System V as Sun can make it). Any more thoughts?
Re: A semi-annual poke about progress
Are you still sheparding this project? I remembered to look at http://savannah.nongnu.org/projects/nmh I noticed that there are outstanding bugs - I haven't had a chance to look at the reports. Do you need help with them?
Solaris 8 build
The makefile in the 'man' directory works with GNU make, but not Sun make (/usr/ccs/bin/make). What's the preferred solution here? Require GNU make? If so, shouldn't the configure script check for its presence, and set execution paths accordingly?
Solaris 'vim' configure bug
If vim 6.0 is installed on a Solaris system, the 'ex' program included with vim 6.0 goes into an infinite loop when this statement in 'configure' is executed: if echo 'r /nonexist-file q' | ex /dev/null 21 It seems wrong to me to include a newline in the string this way. It could be re-written as: echo 'r /nonexist-file\nq' | ex /dev/null 21 This works with vim 6.0 and both bash and the Solaris release of 'sh'. Should 'configure.in' be changed this way to make it work?
Re: Solaris 'vim' configure bug
Sorry, spoke too soon. The real problem has to do with output redirection. if echo 'r /nonexist-file q' | ex works but if echo 'r /nonexist-file q' | ex /dev/null 21 hangs. Redirecting just standard output cause no problem. But there doesn't seem any output to redirect anyway...
Re: nmh 1.1 release canidate uploaded
Ken Hornstein [EMAIL PROTECTED] wrote: Everyone, I've created a nmh 1.1 release canidate. You can get it from: http://savannah.gnu.org/download/nmh/nmh-1.1-RC1.tar.gz What's the difference between this release and the one I picked (and have been using since then) in July?
Re: what's happening?
I can help get a next release out. At the very least, I can help with testing, since I use nmh with my mail client.
Please could we have nmh 1.0.5??
Please! Thanks.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
My solution was to completely take out any dependency on system ruserpass, and use the version packaged with nmh. If you want to take advantage of this, I recommend you get the latext CVS version. I think that this is the best solution - it gets my vote!
nmh 1.0.4 doesn't work as POP client on LInux systems
Last November, I submitted a bug report with patches for nmh - it didn't work as a POP client properly on Linux systems. But unfortunately, the patches didn't get into the 1.0.4 release, so here goes again: The Symptom: Unless .netrc is used, on systems using glibc 2.1.1, 'inc' fails to work when nmh is configured as a POP client. The Reason: The glibc version of ruserpass() won't prompt the user for a password (the glibc maintainers believe that this is the right and proper behavior, and won't change ruserpass() - see note attached). Possible Solutions: 1. At minimum, the documentation should be changed to note the current restriction that ~/.netrc be used to supply a login/password for POP. 2. For Linux systems, avoid using the glibc version of ruserpass(), and use the version supplied with nmh. There's an additional problem here - ruserpass() calls getpass(), and in glibc, the getpass() flushes standard input before prompting the user for a password. When a program like exmh uses 'inc', it feeds in the password as standard input with code like: exec inc +inbox -truncate -nochangecur -width 100 password which fails with the glibc version of getpass(). So a replacement for getpass() needs to be provided as well. What to Do? I'm willing to put together changes to the nmh configure script that will use the nmh version of ruserpass(). I have a patch for ruserpass() that works with my system (see attached). Would you like me to work on the configure portion? But it is also the case that 'ruserpass()' is not a "well defined" function - it's not a Posix function, and can't be guaranteed to exist with any particular attributes on any particular system. It's an internal routine to rexec(), and by rights shouldn't really be used by nmh at all. So a better overall fix would be to always use the nmh version of ruserpass(), including its own 'getpass()' routine, to make sure it always works. So, what would you like to do? Please at least include a note in the MACHINES file about the restriction that on Linux systems, ~/.netrc must be used for POP login/password info. Thanks! glenn writes: Number: 1474 Category: libc Synopsis: rexec() function won't prompt for password if not found in .netrc file Confidential: no Severity: serious Priority: medium Responsible:libc-gnats State: open Class: sw-bug Submitter-Id: unknown Arrival-Date: Mon Nov 29 12:00:01 EST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: net Release:2.1.1 Environment: Mandrake Linux 6.1, i386 architecture Description: Unfortunately, none of this family of functions (rexec, rcmd) is documented in the manual. Previous editions of ruserpass() in the BSD distribution would prompt for a password if it wasn't found in a variety of places. The glibc version will only return a username/password if there are appropriate entries in the .netrc file. This has caused the current edition of nmh (1.0.2) not to work correctly, because it counts on the user being prompted for a password. Since there is no documentation of rexec() in the glibc manual, I include for reference excerpts from man pages on This has been discussed several times on the glibc mailing lists. I'm citing some comments from the discussion: Mark Kettenis writes on 26th October 1999: Do you have any evidence that the statement about rexec asking for the username/password is true? Although the BSD man pages do indeed mention that rexec() would do this, none of the BSD's derived from BSD 4.2 (which according to the man page is the first version that has rexec()) do implement this. Since the code in glibc is derived directly from BSD, it is no surprise that glibc doesn't do this either. So the whole issue appears to be a documentation bug on the side of BSD. There may be some reimplementations of rexec() around that do ask for a password based on the BSD documentation, but that's not very relevant. I think that there are a lot of cases where it is unwanted. As a principle, no library call should print anything (except when that's the explicit purpose of the call of course), let alone ask for input. And later, Mark again: Anyway, the issue has been discussed before [1]. Ulrich thinks we should stay with the BSD 4.4 implementation, and I agree with him. It's more or less the reference standard for rexec(). Also note that rexec() is considered to be pretty dangerous. FreeBSD and NetBSD only offer it for compatibility with BSD 4.4, and reccommend using another mechanism. Mark [1] http://sourceware.cygnus.com/ml/bug-glibc/1999-07/msg00085.html In a nutshell: glibc follows the BSD 4.4 implementation and we're not going to change it. Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] *** ruserpass.c.orig Fri Apr 30 14:08:34 1999 --- ruserpass.c Mon Nov
