Re: default components file

2003-07-01 Thread Glenn Burkhardt
 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

2003-07-01 Thread Glenn Burkhardt
 Bill Wohler wrote:
 Note that in replcomps, the Fcc only appears if you specify repl -fcc
 +outbox. But then it does appear in the header.

 Whatever we do should be consistent.

Jerry Peek had (privately) suggested this solution:

Fcc: %{fcc}%{fcc}%|+outbox%

as part of replcomps.  This would be my choice, since it's compatible
with 'repl -fcc +otherbox, and provides a default (which a new user 
could easily see how to change.



Re: default components file

2003-07-01 Thread Glenn Burkhardt
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'.



default components file

2003-06-30 Thread Glenn Burkhardt
I'd like to change the default components file to include a folder copy:

To:
cc:
Fcc: +sent-mail
Subject:


Most mail clients I've dealt with make a copy of sent mail by default, and
it's easier for new users to delete a line than to figure out how to
correctly add one.

I'll change the 'comp' man page too, if everyone agrees.

Thanks.



pick argument order

2003-06-30 Thread Glenn Burkhardt
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)

2003-06-28 Thread Glenn Burkhardt
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

2003-06-27 Thread Glenn Burkhardt
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)

2003-06-27 Thread Glenn Burkhardt
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

2003-06-25 Thread Glenn Burkhardt
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

2003-06-08 Thread Glenn Burkhardt
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

2003-06-06 Thread Glenn Burkhardt
I found this note in the 'vim' release notes:

When using cmd | vim -, stdin is not a terminal.  This gave problems with
GPM (Linux console mouse) and when executing external commands.  Now close
stdin and re-open it as a copy of stderr.

The source for version 6 does this:

if (read_stdin)
{
/* Use stderr for stdin, makes shell commands work. */
close(0);
dup(2);
}

I don't why this isn't a problem on Linux, too, but it is a problem on
Solaris 8.  The native Sun version of 'vi' doesn't have this problem.

The quickest fix for this is to only redirect stdout to /dev/null 
for the test

  if echo 'r /nonexist-file
q' | ex  /dev/null 21

Robert Elz noted that on NetBSD, the output was sent to stdout.  The
Sun version of 'vi' and 'vim 6.0' do this as well.

Advice?




Solaris 8 make error building man pages

2003-06-06 Thread Glenn Burkhardt
The makefile in the man directory uses GNU simply expanded variables with
these lines:

MAN1 := $(MAN1SRC:.=.$(manext1))
MAN5 := $(MAN5SRC:.=.$(manext5))
MAN8 := $(MAN8SRC:.=.$(manext8))

However, Solaris 8 uses a System V make that uses ':=' for conditional
macro assignment. 

My reading of the make file (and testing) indicates that we can change
:= to = without a problem, so the lines would be 

MAN1 = $(MAN1SRC:.=.$(manext1))
MAN5 = $(MAN5SRC:.=.$(manext5))
MAN8 = $(MAN8SRC:.=.$(manext8))

Is this right?




Re: Solaris 'vim' configure bug

2003-06-06 Thread Glenn Burkhardt
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

2003-06-03 Thread Glenn Burkhardt
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?



Re: A semi-annual poke about progress

2003-06-03 Thread Glenn Burkhardt
Please let's do it!!

I've been using nmh-1.1-RC1.tar.gz since Nov 18, 2002.  It works.  I give
it my blessing (for whatever that's worth!).

I've forgotten who had put it together and where it's hosted - does
anyone remember??



Re: A semi-annual poke about progress

2003-06-03 Thread Glenn Burkhardt
On Monday 02 June 2003 04:40 pm, you wrote:
 Hi.  Seems like we've had a 1.1 release candidate sitting for a long
 time.  Can we make it a release yet?  It would be nice to have something
 newer than 1.0.4 going into things like Linux distributions.

 Hm, well ... how about everyone (including me) makes sure what's on the
 1.1 branch compiles on all of the major platforms that they have access
 to, and if the answer is yes, then we call the head of the 1.1 branch
 1.1 final ?

 --Ken

A quick check:

SunOS (yes, I run a department of Computer Antiquities) fails, many functions
missing from the libraries (strerror, vnsprintf, 
snprintf).
I suggest that this be ignored.

Mandrake Linux 8.1 - no problems (and I've been using it since Aug 2002).
Mandrake Linux 9.1 - the ndbm.h file has been moved to /usr/include/gdbm,
 so the compile of slocal.c bombs; the link of slocal 
 needs -lgdbm added.  No other problems after 
correcting
 location of include files and referencing the library.
 This should be able to be fixed in the configure 
script.
Solaris 8 - test for broken 'vi' hangs in execution of 'ex',   
  
 when package  SMCvim (vim-6.0-sol8-sparc-local)
 from SunFreeware is installed.  Required installation
 of autoconf-2.13 and m4-1.4 for make to start.
 Compiles until the 'man' directory, and then:

make: Fatal error in reader: Makefile, line 75: Unexpected end of line seen
Current working directory /export/home/glenn/nmh-1.1-RC1/man

15 secs of looking at line 75 of the makefile doesn't reveal much to me:
MAN5 := $(MAN5SRC:.=.$(manext5))

Do I have to test it on all these platforms, too?  (just kidding...)

You have waited to long to release this stuff.  Now we have to fix it...

Clues on what the test for 'broken vi' does are solicited.




Solaris 8 build

2003-06-03 Thread Glenn Burkhardt
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

2003-06-03 Thread Glenn Burkhardt
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

2003-06-03 Thread Glenn Burkhardt
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

2002-11-18 Thread Glenn Burkhardt
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: POP problems with inc

2002-09-26 Thread Glenn Burkhardt

 I just compiled and installed without errors, but 'inc' is not working
 correctly.

For what it's worth, POP access in the most recent release 1.1-RC1 of nmh works
for me, with these two commands:

/usr/local/nmh/bin/inc -snoop +inbox -truncate -nochangecur -width 100 -host priam 
-user asdf
Password (priam:asdf): 
--- +OK POP3 priam v2000.70mdk server ready
--- USER glenn
--- +OK User name accepted, password please
--- PASS 
--- +OK Mailbox open, 0 messages
--- STAT
--- +OK 0 0
--- QUIT
--- +OK Sayonara
inc: no mail to incorporate

echo password | /usr/local/nmh/bin/inc +inbox -truncate -nochangecur -width 
100 -host priam -user asdf

and with the values put into .netrc, too.

Server is Mandrake Linux 7.2, client system is Mandrake Linux 8.1.

I suggest you trace more verbosely on your server, and perhaps use the
debugger with 'inc'.







Re: what's happening?

2002-04-12 Thread Glenn Burkhardt

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??

2001-08-20 Thread Glenn Burkhardt

Please!  

Thanks.




time for new edition?? (fwd)

2001-05-31 Thread Glenn Burkhardt

This note generated a bit of positive response.  So can there be a new 
release now?  I've just seen another note about POP access problems on 
the exmh mailing list.  Thanks!




There are quite a few bug fixes in the CVS repository that could help
folks out - isn't it time for a new release?  In particular, I'm still
seeing reports of problems with POP access that I know were fixed about
a year ago...

Thanks..




time for new edition??

2001-04-30 Thread Glenn Burkhardt

There are quite a few bug fixes in the CVS repository that could help
folks out - isn't it time for a new release?  In particular, I'm still
seeing reports of problems with POP access that I know were fixed about
a year ago...

Thanks..




Re: nmh 1.0.4 doesn't work as POP client on LInux systems

2000-04-24 Thread Glenn Burkhardt

 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

2000-04-22 Thread Glenn Burkhardt

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 

nmh doesn't work as POP client with glibc

1999-11-30 Thread Glenn Burkhardt

I recently tried to configure nmh 1.0.2 to work as a POP client on a 
Mandrake Linux 6.1 system, which uses glibc 2.1.1, and it didn't work.

The problem is the glibc edition of 'ruserpass.c', which is called by 'inc'
to get the user password.  The glibc edition of ruserpass won't prompt the user
for a password, and their policy at present is not to change it (see attached
note).

The first thing that comes to mind is to use the 'ruserpass.c' routine supplied
as part of the compatibility routines with nmh.  This is not enough, at 
least if one wants 'nmh' to work with 'exmh'.  The nmh version of ruserpass.c
uses a standard Unix function called 'getpass()' to pick up the password from
the use.  However, the glibc version of 'getpass()' flushes standard input
before prompting the user for a password.  So, since exmh uses code like:

exec inc +inbox -truncate -nochangecur -width 100  password

it can't work, since the glibc getpass() function throws the password string
away before issuing the prompt.

I threw together this patch for nmh/sbr/ruserpass.c that works for inc with
exmh:

*** ruserpass.c.origFri Apr 30 14:08:34 1999
--- ruserpass.c Mon Nov 29 13:57:58 1999
***
*** 178,183 
--- 178,196 
  return(-1);
  }
  
+ char *getpass(const char *prompt)
+ {
+ static char buff[50];
+ char *s;
+ 
+ s = fgets(buff, sizeof(buff), stdin);
+ if (!s) buff[0] = 0;
+ 
+ if (buff[strlen(buff)-1] == '\n') buff[strlen(buff)-1] = 0;
+ 
+ return buff;
+ }
+ 
  static int
  token(void)
  {


This is not a good permanent solution.  The function 'ruserpass()' is not
a standard Unix function, and is in fact an internal routine for the C library,
and one can't expect its function to be constant among different systems.  
Portable code would avoid its use.

Since these days the MH functions are 'backend' routines to GUI frontends, it
would be much better to provide command line arguments for the password.  

There are other places in the nmh code where ruserpass is used:  
mhbuildsbr.c, mhparse.c, msgchk.c, popi.c - so these places should be changed
as well.





 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]




slightly better patch for ruserpass.c

1999-11-29 Thread Glenn Burkhardt

Sorry - the last one didn't include printing of the prompt - I was mostly
concerned with getting exmh to work

*** ruserpass.c.origFri Apr 30 14:08:34 1999
--- ruserpass.c Mon Nov 29 14:45:04 1999
***
*** 178,183 
--- 178,210 
  return(-1);
  }
  
+ #include termios.h
+ char *getpass(const char *prompt)
+ {
+ static char buff[50];
+ char *s;
+ struct termios tio, tioO;
+ int in;
+ 
+ fputs(prompt, stdout);
+ fflush(stdout);
+ 
+ in = fileno(stdin);
+ tcgetattr(in, tioO);
+ tio = tioO;
+ tio.c_lflag = ~ECHO;
+ tcsetattr(in, TCSANOW, tio);
+ 
+ s = fgets(buff, sizeof(buff), stdin);
+ if (!s) buff[0] = 0;
+ 
+ tcsetattr(in, TCSANOW, tioO);
+ 
+ if (buff[strlen(buff)-1] == '\n') buff[strlen(buff)-1] = 0;
+ 
+ return buff;
+ }
+ 
  static int
  token(void)
  {