headers
Scott Lipcon | 14 Oct 2002 18:04

Fwd: [Bug #1393] sortm core dumps

I submitted this bug last week, and added an update today.  I don't
think anyone's really using savannah's bug tracking tool, so I'm
forwarding this to the nmh-workers list.   

Scott

------- Forwarded Message

Date:    Mon, 14 Oct 2002 11:46:34 -0400
From:    nobody <at> savannah.nongnu.org
To:      slipcon <at> mercea.net
Subject: [Bug #1393] sortm core dumps

=================== BUG #1393: LATEST MODIFICATIONS ==================
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=1393&group_id=2166

Changes by: Scott Lipcon <slipcon <at> mercea.net>
Date: 2002-Oct-14 15:46 (GMT)

- ------------------ Additional Follow-up Comments ----------------------------
I found time to track down the bad message - it looks like a Korean spam, with 
funny characters in the subject line.  The bad message is at http://mercea.net/
~slipcon/misc/bad-message.gz

I also tried sortm from the latest CVS, and it still core dumps.  

If anyone has time to look at this, that would be great.

Scott
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Elz | 15 Oct 2002 10:28
Picon

Re: Fwd: [Bug #1393] sortm core dumps

    Date:        Mon, 14 Oct 2002 12:04:46 -0400 (EDT)
    From:        Scott Lipcon <slipcon <at> mercea.net>
    Message-ID:  <20021014154751.E4FA0550 <at> mercea.net>

  | I submitted this bug last week, and added an update today.  I don't
  | think anyone's really using savannah's bug tracking tool, so I'm
  | forwarding this to the nmh-workers list.

Try the following patch to uip/sortm.c

The "korean spam" part of the message (if that's what it was)
is irrelevant, the same thing would happen to any message that
had a Subject header like

	Subject:N...

where 'N' is any alphanumeric character.

The patch below adds a #if 0 to remove a line of code (or two).  You can
change it to "#if 1" if you prefer, to eliminiate a different line of code.

Either line is acceptable, from the no core dump, point of view, but both
together are fatal.

This code is attempting to eliminate "Re:" from Subject lines before
comparing them.   It looks as if that was attempting (once) to get rid
of multiple instances of "Re:".  Someone then probably noticed that this
would also get rid of "Re:" in a context like "more:" which isn't what
is intended...   So, my guess is, the "break" was added so the "Re:"
skipping would be done only at the beginning of the Subject line, not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Elz | 16 Oct 2002 10:55
Picon

Re: Fwd: [Bug #1393] sortm core dumps

    Date:        Tue, 15 Oct 2002 10:02:06 -0400
    From:        Scott Lipcon <slipcon <at> mercea.net>
    Message-ID:  <20021015140206.80C23253 <at> mercea.net>

  | This patch works fine.   Should I commit it to CVS?

I assume you're asking nmh-workers in general, rather than me...

  | What else is left to be done before 1.1?

If you, or anyone else, cares, I have a patch to pick that gets
rid of the ugly

	pick -list -seq x
means
	pick -nolist -seq x

behaviour.   It leaves the default as being -nolist when -seq is
given, and -list when it isn't, it just gets rid of the arg order
dependency that currently exists.

That is,
	pick -list -seq x
and
	pick -seq x -list

end up meaning the same thing, which IMNSHO they should, MH has generally
never cared which order different args appear (only direct contradictions).

I haven't yet generated a patch for the man page to get rid of the comment
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Eriksson | 16 Oct 2002 23:30

Re: Fwd: [Bug #1393] sortm core dumps


kre <at> munnari.OZ.AU said:
>   | What else is left to be done before 1.1? 

I'm offline now, but i'd like to get this one in to bring it in line 
with the man page.

/A

--- nmh-1.0.4/uip/scan.c	Fri Feb  4 21:28:24 2000
+++ nmh-1.0.4/uip/scan.c.new	Tue Jan 15 07:57:48 2002
 <at>  <at>  -316,7 +316,7  <at>  <at> 

 	    switch (state = scan (in, msgnum, 0, nfs, width,
 			msgnum == mp->curmsg, unseen,
-			hdrflag ? folder : NULL, 0L, 1)) {
+			folder, 0L, 1)) {
 		case SCNMSG: 
 		case SCNENC: 
 		case SCNERR:
Permalink | Reply | 0 comments |
headers
Steve Kelem | 18 Oct 2002 01:27

Problems compiling nmh-1.1-RC1 under cygwin

Hi. I have the latest cygwin on Windows 2000, SP3.
NMH fails to compile.

Steve Kelem

nmh configuration

-----------------

nmh version                : 1.1-RC1

target os                  : i686-pc-cygwin

compiler                   : gcc

compiler flags             : -Wall -O2

linker flags               : -s

source code location       : .

binary install path        : /usr/local/mh/bin

libary install path        : /usr/local/mh/lib

config files install path  : /usr/local/mh/etc

man page install path      : /usr/local/mh/man

backup prefix              : ,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Eriksson | 20 Oct 2002 09:17

burst bug?


This stuff popped up on the mh news group. Anybod know how it 
compares to nmh -head and -rc1.1?

/A

"Bill Wohler" <wohler <at> newt.com> wrote in message news:<808z14tdw9.fsf <at> 
gbr.newt.com>...
> Jym Dyer <jym <at> econet.org> writes:
> > > mailman is producing "--__--__--" as a message delimiter, and
> > > burst is looking for "-------".  i didn't try to mentally run 
> > > the rfc934 state machine on that to see if it's legit or not.
> > 
> > =v= Well swat my hind, the string is hardcoded into burst.c:
> > 
> > static char delim3[] = "-------";
> > 
> > Whereas RFC934 lets anything that starts with "-" but not with
> > "- " serve as a separator.
> 
>   Thanks for digging into that. Turns out that MH has the bug, not
>   mailman.
> 
> -- 
> Bill Wohler <wohler <at> newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
> Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian!
> If you're passed on the right, you're in the wrong lane.
Permalink | Reply | 0 comments |
headers
Herb Peyerl | 20 Oct 2002 13:39

mhstore ignores umask ?

Hope this isn't too annoying a question. But I really couldn't find
the answer.

I'm using mhstore to stuff my attachments into an htdocs/foo directory
so I can then hit it with a browser, since most of the attachments I 
get are jpg's and so forth.  My problem is, I can't figure out how to 
get mhstore to set the perms to at least 644?  It insists on 600. I can
see how 600 is desirable when dealing with someone's mail but I'd like
to override it.  Setting my umask has no affect on it.

Am I missing something obvious? 

---
Beheading servers since 1999 -- The PC Weasel! http://www.realweasel.com
Permalink | Reply | 4 comments |
headers
Neil W Rickert | 20 Oct 2002 16:22
Favicon

Re: mhstore ignores umask ?

Herb Peyerl <hpeyerl <at> beer.org> wrote:

>I'm using mhstore to stuff my attachments into an htdocs/foo directory
>so I can then hit it with a browser, since most of the attachments I 
>get are jpg's and so forth.  My problem is, I can't figure out how to 
>get mhstore to set the perms to at least 644?  It insists on 600. I can
>see how 600 is desirable when dealing with someone's mail but I'd like
>to override it.  Setting my umask has no affect on it.

>Am I missing something obvious? 

I am finding that "mhstore" gives 664 permissions.  This is
presumably related to

Msg-Protect: 664

Arguably, it is a mistake for mhstore to follow the Msg-Protect
for this.

I have a related problem (the inverse problem) -- when "refile" has
to move to a different file system, it follows umask, when it should
either be replicating the original permissions or following the
Msg-Protect setting.  (My workaround is to make "refile" a shell
script that sets the desired umask, then invokes the real "refile").

 -NWR
Permalink | Reply | 0 comments |
headers
Herb Peyerl | 20 Oct 2002 16:28

Re: mhstore ignores umask ?

Neil W Rickert <rickert+nmh <at> cs.niu.edu>  wrote:
 > I am finding that "mhstore" gives 664 permissions.  This is
 > presumably related to
 > 
 > Msg-Protect: 664
 > 
 > Arguably, it is a mistake for mhstore to follow the Msg-Protect
 > for this.

I'm not finding that to be the case:

[grok hpeyerl 940 ]; grep -i msg-protect ~/.mh_profile
Msg-Protect: 664
[grok hpeyerl 941 ]; mhstore -part 1
storing message 283 as file /tmp/283.txt
[grok hpeyerl 942 ]; ls -al /tmp/283.txt
-rw-------  1 hpeyerl  wheel  1009 Oct 20 08:26 /tmp/283.txt
[grok hpeyerl 943 ]; umask
22
Permalink | Reply | 1 comment |
headers
Robert Elz | 20 Oct 2002 16:59
Picon

Re: mhstore ignores umask ?

    Date:        Sun, 20 Oct 2002 08:28:51 -0600
    From:        Herb Peyerl <hpeyerl <at> beer.org>
    Message-ID:  <200210201428.g9KESpG04363 <at> grok.beer.org>

  |  > I am finding that "mhstore" gives 664 permissions.  This is
  |  > presumably related to
  |  > Msg-Protect: 664

  | I'm not finding that to be the case:

I suspect that you don't want to know.   It can be either.   The default
permissions for files stored by mhstore depend on more things than make
sense - including whether the thing being stored comes from a message
(in which case Msg-Protect is the more likely source, regardless of the
permissions of the message) or from a file, in which case 0600 is close
to hard coded (but it is nothing like that clear cut).

kre
Permalink | Reply | 0 comments |

Gmane