Re: [Nmh-workers] whatnow: can't attach because no header field name was given.
In message <201203160209.q2g29b1w019...@darkstar.fourwinds.com>, Jon Steinhart wrote: >Please excuse my ignorance here. What killed x-? If anybody happens to know, I'd also like very much to find out who killed Rosie Larsen. Regards, rfg ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] whatnow: can't attach because no header field name was given.
In message <201203160200.q2g20jwt032...@hedwig.cmf.nrl.navy.mil>, Ken Hornstein wrote: >>Full disclosure: I am using NMH version 1.3. Alas, version 1.4 has not >>been ported to FreeBSD yet. (Is this the real root of the problem?) > >When you say "not ported" ... do you mean, "It doesn't work when I >tried to compile it?", because that's a serious problem. Or do you >mean, "Not in the ports system", which is also a problem, but not >one we have control over. The latter. Sorry for not being clear. Regards, rfg P.S. I have sent an informal inquiry to the maintainer of FreeBSD port of NMH, asking if an update to 1.4 might perhaps be in the offing anytime soon. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] whatnow: can't attach because no header field name was given.
In message <201203160123.q2g1nay7018...@darkstar.fourwinds.com>, Jon Steinhart wrote: >valdis.kletni...@vt.edu writes: >> --==_Exmh_1331860781_2149P >> Content-Type: text/plain; charset=us-ascii >> >> On Thu, 15 Mar 2012 18:02:48 PDT, Jon Steinhart said: >> >> > And yes, having defaults for common content types in the profile would >> > be a good thing. At the time that I wrote this stuff suffixes were not >> > nearly as standardized as they are today. >> >> Wow. Maybe somebody should gather them all up into a file and call >> it /etc/mime.types or something, so all programs could benefit? >> >> > >Whoa, sarcasm. It's SOO appreciated :) > >This all goes back to the "don't break things" approach that I took when I >wrote this originally. Maybe it's time to revisit it. It's a complex issue >because of the linkage between mime types and helper applications. I used >what was there which comes from mhshow. No real objection to changing it >althout /etc/mime.types may not exist on all systems. Also, there are >probably considerable differences in choices of helper applications. Please excuse me if this is old news... I myself didn't know about it until today... but it would seem that the file(1) command on both FreeBSD and Linux implements a -i option that nicely spits out an appropriate MIME type for the file being examined. I haven't looked to see if the attach command for whatnow is using that or not, but certainly, if it is (or if it will, in the future), then it would seem to me that whatnow itself would not even need to make use of any file called "mime.types" (no matter where located). (Just tryin' to be helpful... on the off chance that I am not the only one on this planet who didn't know already know about this -i option.) Regards, rfg ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
> >I agree (with the re-write, I've never witnessed the problem). > > I assume you mean WITHOUT the rewrite, because nobody's re-written > m_getfld last time I looked :-) Right. > Looking at things ... it may be a simple fix, actually. I wasn't > envisioning any changes to m_getfld(), that's for sure. I stared at it for a few moments and thought that removing the scansbr.c snippet that you posted might do it, but I really don't know. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
>I agree (with the re-write, I've never witnessed the problem). I assume you mean WITHOUT the rewrite, because nobody's re-written m_getfld last time I looked :-) It's sort of Steve's setup that triggers it; not only does he have a bunch of Received: headers, but a huge spam score report, a couple of Return-Path: headers and a few other bits of extra stuff. That's enough with a wider display to put the start of the body right on the stdio buffer boundary in some cases. If you don't have that then you'd never see it. >The code after Ken's excerpt goes directly into the io buffer. It's in >the caller, not m_getfld(). Right, I don't think I explained that part well. While m_getfld() is sort of under-specified, the basic idea is that you're supposed to keep calling it until you get a state transition. From what I can tell everybody does that EXCEPT scan in this particular instance (the code after that snipped is used by inc). So everybody else can deal when m_getfld() returns a "short" buffer. Looking at things ... it may be a simple fix, actually. I wasn't envisioning any changes to m_getfld(), that's for sure. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
>>> Punt until the m_getfld() re-write If this was a five-9s thing, like 99.999% working, then I'd be down for that. But it's not, and maybe the fix is fairly simple? >> If we guess wrong, that would result in one extra read in some cases. Do I understand correctly that we're wringing our hands over one extra read per msg < 100% of the time? >> We know what "width" is, and the body can't >> be longer than that. So we could say that the body has to be at least >> width characters (or we reach EOF). If that looks easy, just do it? steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
Ralph wrote: > Punt until the m_getfld() re-write. It's annoyed me for years, it can > continue a while longer. I agree (with the re-write, I've never witnessed the problem). The code after Ken's excerpt goes directly into the io buffer. It's in the caller, not m_getfld(). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
Hi Ken, > Thoughts? Punt until the m_getfld() re-write. It's annoyed me for years, it can continue a while longer. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
>Since I started using mh-v, for about two months, I've been keeping a
>pretty close eye on making sure scan and mhshow work perfectly. This
>week collected four msgs where the decoding %{body} is truncated after 6
>to 16 characters with v1.2 and v1.4!
Okay, Steve was nice enough to give me a test message, so I took a look at
the problem.
Here's the issue. When scansbr.c:scan() calls m_getfld() (that bastard
again!) it has the following short-circuit test when m_getfld() returns the
BODY state:
if (! outnum) {
state = FILEEOF; /* stop now if scan cmd */
goto finished;
}
(For us, outnum is zero).
This means that as soon as we get any amount of data for the BODY
state, we stop scanning the message. In the message Steve pointed
me to the cutoff point in the scan listing is at byte 4096. Since
the code enters the BODY state without reading more (normally you
would keep calling m_getfld() until you get FILEEOF) you get only
what's in the buffer; hence the truncation. If the message headers
were shorter or longer, you'd never run into it. I think this bug
has been around forever, and that 30 years ago no one had any idea
message headers would ever approach 4K.
So, how do we solve it? Well, I'm not sure of the "right" thing to do. It's
hard with the current format system to determine how many characters the body
needs to be. We could take a guess. If we guess wrong, that would result
in one extra read in some cases. We know what "width" is, and the body can't
be longer than that. So we could say that the body has to be at least
width characters (or we reach EOF).
Thoughts?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
> Could someone forw me one of the affected messages? I'll be glad to track > it down. Also, if you could include an MD5/SHA1 checksum of the message > I can be sure on this end to recreate it exactly? Will do, off list, in a sec. steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
> Been seeing this, haven't had a chance to track it down. Looking at exmh's > .xmhcache files, I have 145,141 total messages listed in .xmhcache entries, > and > the bug is affecting 3,266 of them. So there's an anectodal value for the > frequency. ...but isn't the body sometimes smaller than the room in the scan listing?? Certainly is for me, but I have cron and at send me reminders a lot. Anyway... $ compute 3266/145141*100 2.2500 $ compute 9/602*100 1.4900 ...so perhaps I'd argue it's more than an insignificant nuisance. > Interestingly enough, Ken's 11:35 message did *not* trip over the bug, so > there's some state that's different between your machine and mine. My first > guess is number/length of Received: headers? I just removed the Ken's X-Face: header and problem disappeared. Ditto w/ removing my X-Envelope-From: injected by procmail. I don't think any more analysis from me would be useful. Free samples available by request! steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
>Wow. So I'm not hallucinating (at least not this time :) > >Been seeing this, haven't had a chance to track it down. Looking at >exmh's .xmhcache files, I have 145,141 total messages listed in >.xmhcache entries, and the bug is affecting 3,266 of them. So there's >an anectodal value for the= frequency. Could someone forw me one of the affected messages? I'll be glad to track it down. Also, if you could include an MD5/SHA1 checksum of the message I can be sure on this end to recreate it exactly? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan %{body} bug?
On Fri, 16 Mar 2012 16:46:46 CDT, ra...@hep.wisc.edu said: > Can someone/anyone replicate? Test with the msg from Ken to this list today, > March 16 2012 at 11:35:44 -0400? Wow. So I'm not hallucinating (at least not this time :) Been seeing this, haven't had a chance to track it down. Looking at exmh's .xmhcache files, I have 145,141 total messages listed in .xmhcache entries, and the bug is affecting 3,266 of them. So there's an anectodal value for the frequency. A few random samplings from my NANOG folder: 45498* Fri 17Feb5442 Sven Olaf Kamphui RE: Colo Vending Machine < pgpE9o2H5pp0q.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] scan %{body} bug?
Since I started using mh-v, for about two months, I've been keeping a pretty
close eye on making sure scan and mhshow work perfectly. This week collected
four msgs where the decoding %{body} is truncated after 6 to 16 characters
with v1.2 and v1.4!
See examples (300, 500-502) after my sig.
Can someone/anyone replicate? Test with the msg from Ken to this list today,
March 16 2012 at 11:35:44 -0400?
Just paged through my the Scientific Linux folder and found four more.
steve
--
$ scan
1 Tue Sep 13 11:23 REDACTED PAGE-DOWN KILLS THE SCROLLBAR Re:
[Fwd: White Pages Assi
2 -Wed Jan 25 07:48 "Workplace Produc CURRENT HREF JUMPS PROBLEM Improve
Your Memory and Get M
3 -Wed Jan 25 21:43 Eventful CURRENT HREF JUMPS PROBLEM This
weekend at Sundance Cine
5 Wed Feb 08 14:05 Ken Hornstein THREADING CODE Re: [Nmh-workers]
exciting new stuff for
100 Tue Mar 13 12:32 To:REDACTEDMIME RFC822 SHOWN INLINE AND AS
ATTACH! Re: Lenovo T500
200 Wed Mar 14 10:22 REDACTED Resolving dependency problems | For
the last
300 Wed Mar 14 11:09 Capital OneCURRENT HREF JUMPS PROBLEM Here's
your March credit card
400 Fri Mar 16 03:05 "webmaster@straig UTF-8 FAIL?? The Straight Dope
03/16/2012 | --cdf82e78-5
500 Fri Mar 16 09:13 Ken Hornstein Re: [Nmh-workers] temporary files |
>Rather than pr
501+ Fri Mar 16 10:35 Ken Hornstein Re: [Nmh-workers] temporary files |
>If we pr
502 Thu Mar 15 17:43 Jon Steinhart Re: [Nmh-workers] temporary files |
Jerra
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to -attach and -attachformat 1
Ken Hornstein writes: > Watching Ronald Guilmette struggle through making the attach command > work, I decided that this stuff should be cleaned up. I understand > Jon Steinhart's initial reluctance to make attach turned on by > default, but it's been in there for a decade now and I haven't seen > any complaints about it (other than, "How do I make this work again?"). > > So, in the spirit of improving usability and because I love cramming things > down people's throats whether they like it or not (joke!), I've made > "-attach Nmh-Attachment" & "-attachformat 1" the defaults. If you already > have set -attach in your .mh_profile, it should continue to work and > use the header name you specify. I also added a -noattach flag to the > relevant commands so you can turn it off if you desire. > > --Ken I'm fine with this. I was the new kid on the block when I did the attachment stuff and didn't want to get jumped on by you nmh pioneers for breaking something. Your wanting to mainstream it make me think that I did an acceptable job. Thanks. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Changes to -attach and -attachformat 1
Watching Ronald Guilmette struggle through making the attach command work, I decided that this stuff should be cleaned up. I understand Jon Steinhart's initial reluctance to make attach turned on by default, but it's been in there for a decade now and I haven't seen any complaints about it (other than, "How do I make this work again?"). So, in the spirit of improving usability and because I love cramming things down people's throats whether they like it or not (joke!), I've made "-attach Nmh-Attachment" & "-attachformat 1" the defaults. If you already have set -attach in your .mh_profile, it should continue to work and use the header name you specify. I also added a -noattach flag to the relevant commands so you can turn it off if you desire. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
On 2012-03-16, at 8:28 AM, David Levine wrote: > If we prefer to default to the current behavior (@ enabled) > but deprecate that default, OK by me. How about we add the switches in 1.5 but leave it on and mark the feature as obsolete in the release notes. In 1.6, disable it by default. And then when 2.0 comes along, rip the code out if nobody has howled by then. (The release notes should lay out this timeline as well.) If there's anything else we're firmly convinced needs ripping out, we should follow the same path. There are many MH users who aren't on the mailing list, so we really need to let this stuff soak in the field for a long time before ripping out the actual code, to give everyone a chance to speak up if the changes will hit them hard. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
>If we prefer to default to the current behavior (@ enabled) but >deprecate that default, OK by me. I actually just wrote the code :-) But I'm fine with saying that we're going to deprecate creating @ as a default. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
Ken wrote: > Because ... I'm writing the code, and I get to make the decision? :-) > > In all seriousness ... it's a balancing act between "move nmh forward" > and "keep around existing interfaces". So I have to make a judgement > call, and my judgement is to add switches. If someone ELSE wants to > write the code, they can use their judgement. > > There are practical concerns as well. Specifically: > > - A LOT of people apparantly just take whatever the package manager > chooses for the options. That means effectively that if it's an > option which is turned off by default, that means it's turned off > for most people. - Just a guess, but I expect that most people who use prepackaged nmh don't use @. (Again assuming no use by mh-e and xmh.) - And the facts that there's only one @, and that the user won't get a @ if they can't write to the directory, means that they really have to know what they're doing with it. - It really is bad form to open a file in the current directory. Someone finally got burned by it, though admittedly with the help of su. This is one ugly default that really needs to be phased out. If someone wants to keep using it, they'll have the run-time/profile option to do so. How about this: * Add the switches. * Default to disabled. * I'll write the code :-) If we prefer to default to the current behavior (@ enabled) but deprecate that default, OK by me. David nmh fun fact of the day: mhn was deprecated in June 2001. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
>Rather than proliferate switches, why not begin deprecating it, by first >making it something that must be explicitly enabled in build? Because ... I'm writing the code, and I get to make the decision? :-) In all seriousness ... it's a balancing act between "move nmh forward" and "keep around existing interfaces". So I have to make a judgement call, and my judgement is to add switches. If someone ELSE wants to write the code, they can use their judgement. There are practical concerns as well. Specifically: - A LOT of people apparantly just take whatever the package manager chooses for the options. That means effectively that if it's an option which is turned off by default, that means it's turned off for most people. - I am loath to add more #ifdefs. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
Hi, Jerrad Pierce wrote: > Rather than proliferate switches, why not begin deprecating it, by > first making it something that must be explicitly enabled in build? I've known of ./@ for many years and have only rarely used it, and it does make other users ask why they can see a file called ./@. (I'm not a Dr*pbox user.) I'm all for dumping it completely but we won't know of users that do need it and why until we make it stop working for them and they speak up. So how about adding an option to produce it, the current behaviour, but having that off by default. Then they can call in here, or read the fine manual, learn of the new option and recover. The manual would warn it's to be removed completely at $futuredate and they should pipe up in protest if they care. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
>forever (and like Valdis said, exmh might use it). AFAICT, this has Then it should be updated to use $EDITALT, n'est-ce pas? (The dox use lowercase, but isn't convention for environment vars all-caps? Rather than proliferate switches, why not begin deprecating it, by first making it something that must be explicitly enabled in build? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Are we ready for 1.5?
>Better mime handling in repl/forw ? Ok, maybe that is too much to ask. >But an option for repl/forw which simply drops attachments shouldn't >be too complicated. Unfortunately I can only hope this request is >category a) stuff. Sadly, it's complicated. See previous discussions on the list. I wish it was easy, but it ain't. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Are we ready for 1.5?
On 03/15/12 01:31, Ken Hornstein wrote: So I guess what I'm asking is ... does anyone else think that there is something that should be in 1.5? Note that these suggestions should either be a) simple or b) come with an offer to write the code :-). I know Paul Vixie wants to kill m_getfld() and I can't really blame him, but I don't think that's going to happen for this release unless Lyndon has a private branch that he hasn't told us about :-) Better mime handling in repl/forw ? Ok, maybe that is too much to ask. But an option for repl/forw which simply drops attachments shouldn't be too complicated. Unfortunately I can only hope this request is category a) stuff. regards Andreas Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Geschäftsführer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
> >If it's not used by exmh (and mh-e and xmh?), how about if we > >disable it by default? > > OK. I can assure you that exmh doesn't use it (at least not in any > critical way) because it's broken for multiple concurrent replies, my ol' exmh setup creates ~/@ when doing repl. but keep in mind i have it hacked where Sedit repl with external editor is replaced with pure "xterm -e repl ..." [doesn't suffer from the multiple concurrent reply nor reply window lost on exit problems btw.] $ pwd /usr/local/src/exmh-20101208/lib $ grep -B 2 -A 5 '@ by default' extrasInit.tcl Preferences_Add "Quoting" \ " The following options control how exmh writes to the quoting file, @ by default. This file contains a version of the message replied to that sedit or other editors can use to quote. Currently there are two basic choices for the quote file. It can either be a symlink to the original message, or it can be a composite message built by only including some types of a MIME message after type-specific processing. $ head -4 quote.tcl # Quoting support for exmh. These functions center around the # writing of the quote file, which is a pseudo-copy of the message # being replied to. The quote file is usually read by the editor, # sedit or other (I use XEmacs), and processed more completely. steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
David Levine writes: >If it's not used by exmh (and mh-e and xmh?), how about if we >disable it by default? OK. I can assure you that exmh doesn't use it (at least not in any critical way) because it's broken for multiple concurrent replies, and I frequently reply to many messages concurrently within exmh without problems. While I'd happily see it gone altogether, disabling it by default would be a good start. Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
