By the way, I've been using RC3 for several weeks now and it appears
to work fine. But, I'm probably not the best tester since I don't
use all of the twisty little features.
Jon
___
Nmh-workers mailing list
[EMAIL PROTECTED]
I just checked out the CVS so that I could fix some bugs. I noticed that there
is no config.h.in or configure as part of the distribution. Anyone mind if I
add those. Doing so will make the INSTALL instructions work. Or, I could
change the INSTALL instructions, but I think that the first
Ken wrote:
I just checked out the CVS so that I could fix some bugs. I noticed that th
ere
is no config.h.in or configure as part of the distribution. Anyone mind if
I
add those. Doing so will make the INSTALL instructions work. Or, I could
change the INSTALL instructions, but I think
Now, there's some confusion here on what is required to do an install.
When a tar file is built, of course I run autoheader and autoconf so
an end-user doesn't need autoconf to build nmh. But I consider people
who check out the CVS tree to be in the developer category, and thus
I think it's
Jon Steinhart wrote:
Fear of m_getfld has kept me from trying this.
It's not that dreadful, is it? I grant you that it sticks its
hands deep into the guts of the C library in a dreadfully unclean
manner, but if you're just using it it's not too bad.
Is there any consensus for ripping out
Howdy. I've been trying to figure out exactly what nmh does with folder names
so that I can have an external-to-nmh program treat them the same way. I
noticed something curious in compath() in sbr/path.c
I'm guessing that the purpose of this function is to compact a path by
removing extraneous
Oh, since I'm probably about to go make some changes again, I had an email from
somebody a while ago who was upset that I wasn't updating the Changelog when
making changes. I wasn't doing it because I thought that it was done
automatically. What's the policy on this? Is it supposed to be done
There is code in expath in sbr/path.c that just can't be correct. The second
main if statement in this function includes what is, after some substitutions,
if ( ... strcmp(name, .) strcmp(name, ..) ... )
This can never be true!
Can anybody out there explain to me what this function
Jon Steinhart [EMAIL PROTECTED] wrote on Jan 28, 2005:
There is code in expath in sbr/path.c that just can't be correct. The secon
d
main if statement in this function includes what is, after some substitution
s,
if ( ... strcmp(name, .) strcmp(name, ..) ... )
This can never
Jon Steinhart [EMAIL PROTECTED] wrote:
One of the tests (second one under case '.') looks for a trailing /.. on a
path. It would convert a path of /foo/bar/.. to /foo.
This doesn't seem correct to me. It works unless bar is a symbolic link.
A /.. after a symbolic link climbs up
with the current maintainer. I'm not a
great expert on all of the fine points of mail delivery, but I do have
an interest in modernizing the code base and adding new features.
Jon Steinhart
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org
Saw this while looking for something else.
m_chkids() forks a child process to run context_save() if the
uid is not the same as the euid. But, it ends up running as
if the uid and euid are the same if the fork() fails. Seems
to me that this should be an error. I realize that it will
probably
,
Jon Steinhart
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
On Sun, 15 May 2005 22:30:45 PDT, Jon Steinhart said:
So, ask per earlier messages, I'm looking at the context/profile
code and trying to clean it up as I make the changes that I need.
There's a pretty strange function called context_foil(). In all
but two of the places where
Jon Steinhart [EMAIL PROTECTED] wrote:
There's a pretty strange function called context_foil(). In all
but two of the places where it is called it is called with a NULL
argument so it does nothing except set the globals defpath and
context to /dev/null, and none of these calling
invoked when messages are inc'd, rmm'd, and refiled. Part of my project,
grokmail, builds a real database from your mail messages. So you can do
By 'real database' do you mean a Berkeley/MySQL-type DB? Is this sort
of like supporting IMAP?
Actually, it's in Sleepycat, i.e., Berkeley DB.
Josh Bressers [EMAIL PROTECTED] wrote:
Might I suggest we call it 1.2 to avoid confusion.
I have used the nmh-1.1.tar.gz to create the Fedora Core nmh packages, so
having a new nmh tarball with the same version is going to cause some pain
for any packagers who have used that source.
Is there a list of new features in 1.1 (from 1.0), or is it all bug fixes?
The nmh-announce archives don't seem to be available (in the event something
was sent to that list).
Nick
I think that it's mostly bug fixes. The only new features that I can think of
are (naturally) the ones that
Maybe Jon has a different view but I'd have thought that it'd be better
if we add anyone that reads this list and writes an occasional patch,
however infrequently. At least those occasional patches would make it
into CVS quickly instead of sitting in various places until someone has
the time
Jon Steinhart [EMAIL PROTECTED] writes:
BTW, I'm gonna make a small change; I need a -HONEST option to
mhpath. mhpath has the annoying characteristic that it lies
if there is no current folder. This is screwing up an application
that uses mhpath to find the current folder
I have thought about this. There are time where one really wants to
know THE current folder, which means none if there is none.
But there *is* a current folder if there isn't one in context, and
it's +inbox.
Why don't you use mhparam instead?
[EMAIL PROTECTED]:878]$ mhparam
Sorry if some of you have trouble contacting me directly. Out
of necessity I am running a very picky spam filter. Whenever I
see a problem I add the person to my whitelist, so it shouldn't
happen more than once. Apologies for having to take up mailing
list space with this; I look back fondly on
Howdy, I'm back in town and the holidays are over. As near as I can
tell from the mail while I was away, we're ready for another release
candidate. I wait a day and unless I hear otherwise, I'll crank one
out tomorrow. I plan on calling it 1.2-RC1 based on earlier discussion.
Oh, on the whole
Any major issues? Can we do the 1.2 release yet?
Jon,
What's the plan here? The only issue that was brought up has been fixed.
I'd like to see this release soon so development can continue.
Thanks.
--
JB
My plan was to wait until the end of the week. So I guess that this
Time to party!
Jon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Not sure that I've ever seen so much nmh-related email in a day before!
A few things...
No problem cranking out a 1.2.1 release (or should that be 1.3)? Should
I do it now or wait a bit for other problems to surface?
The wish list discussion is great. Maybe someone would spend the time
to
I haven't paid much attention to stuff over the holidays. I did
notice that Josh made a bunch of cosmetic changes (that I'm not
sure that I agree with but hey, that's the way it goes). Are the
NetBSD issues resolved at this point so that it's worth rolling
a new release? Oh, and Happy New Year
Hi,
I see a last issue. The problem happens in OpenBSD and NetBSD if the
GNU version of the m4 macro language processor is not available.
After applying the patch:
...
The patch isn't the issue here. If I make a new release from the CVS,
will it build and work correctly on *BSD? The
I haven't paid much attention to stuff over the holidays. I did
notice that Josh made a bunch of cosmetic changes (that I'm not
sure that I agree with but hey, that's the way it goes).
I'm always up for feedback and discussion. I have the current goal of
cleaning up the current
In message [EMAIL PROTECTED], Jon Steinhart writes:
The patch isn't the issue here. If I make a new release from the CVS,
will it build and work correctly on *BSD? The release won't include
the patch as the code will already be patched.
I would not expect issues here either. Just want
In message [EMAIL PROTECTED], Jon Steinhart writes:
I'm still confused. What I think I hear you saying is that you can't
patch and compile a version on a machine without GNU m4. What I'm
not clear on is whether you can compile a version that was already
correctly patched
Seems like a lot of energy going into nonproductive arguing here.
A few thoughts, in no particular order.
I want to keep using the mailing list; wiki's are nice for some
things, but not ongoing discussions. I hate having to reread all
sorts of stuff in wikis to find the new stuff, and I like a
I'd like to remove the manual steps, as well as support use
of X-MH-Attachment headers, which doesn't give me a chance
to edit the final draft before sending.
How would you propose doing this, since usually one is using
attachments for non-ASCII stuff? Or am I not understanding
the question?
Sorry if I'm about to rehash an old argument, but I'm only just now
coming to grips with Jon's 2002 attachment handling mods. I wasn't
even aware of them before.
Nothing to rehash; when I proposed the attachment handling mods a while back
it was met with silence. There was no debate at the
Anyway, I'm worried that it is send handling the attachment
headers. There are reasons other than attaching files for building a
MIME message, and mhbuild could be called before send. As far as I can
see, the attachment handling mods fail in this situation.
I don't see anything
Oliver wrote:
David Levine wrote:
The option to suppress Content-ID: could be added to either
mhbuild or send. mhbuild seems like the right place,
because that's where the MIME message is created. And it's
trivial to do there.
I would prefer if the option could actually be added to
Oliver wrote:
Jon Steinhart wrote:
I feel the same way about having the attachment header containing full
mhbuild directives. Not sure what you get from that; if you want to
do mhbuild directives, do 'em in the body, it still works. The whole idea
The attach command is convenient
Joel wrote:
Perhaps you should create a new utility that writes build directives
and works both interactively and non-interactively, depending on the
command line options? If it is able to write both directives and
attachment headers, whatnow can use it for a *really* versatile way to
attach
Changing the subject line here.
I have to admit that it's getting a bit hard for me to follow all of
the variations on mime message formats that people want because it's
not something that has ever been an issue for me. The automatically
generated stuff has worked for everybody to whom I send
Oliver wrote:
Currently, the attach command defaults to printing:
whatnow: can't attach because no header field name was given.
If a header field name is given it adds the filename to the header. What
I'm suggesting is that the default is to construct an mhbuild directive
- something like
How 'bout this? Why not add another option similar to the -attach
option that I added to whatnow and send? Why not add a -forward
option that would specify the name of another header that would be used
for forwarding messages. So, for example, if you had in your profile
repl:
Hi everybody. I've noticed a huge increase in the amount of
spam coming from the nmh-commits mailing list. Any chance that
one of you who has started checking stuff in recently is using
a Microsoft machine? If so, please check it for viruses and
stuff. I'm gonna have to unsubscribe if it keeps
Hi Philipp,
I wonder how I'd use the 'attach' option on the 'What now?' prompt.
Whenever I use it I get whatnow: can't attach because no header field
name was given.
As a side note, whatnow(1) mentions -attach header-field-name in
SYNOPSIS, but doesn't describe its use in DESCRIPTION.
Based on the recent emails, I am thinking about a small modification
to sendfile() in whatnowsbr.c. This change would be to skip the test
for automimeproc if attach (in Whatnow(), would have to be made global)
is set.
This change would keep things from getting confused if someone has
I don't use whatnow -attach, but I was fiddling around with it making a
test case for a related issue, and I noticed that it seems to behave a
bit oddly:
mnementh$ whatnow -attach foo
What now? attach foo_bar/baz
What now? alist
baz
What now? detach foo_bar/baz
What now? alist
My two cents on this fix is to just increase the buffer size and skip the
dynamic allocation. Memory is really cheap these days. The nmh code is
littered with efficiencies that made sense when running on a VAX but a
now liabilities. Keep it simple.
Jon
Oh, more old crap the KPOP code in sbr/client.c only supports
Kerberos V4. Since Kerberos V4 is way long in the tooth nowadays
and nmh supports Kerberos V5 via GSSAPI and the Cyrus SASL library,
as part of the general cleanup of this code I am (surprise!) proposing
it get junked
ve6bbm/ve7tfx wrote:
Another concern is meta-data. MH annotates messages by adding headers
to the message file. Messages in IMAP are immutable, so that won't
i don't think i was aware of this. i don't recall MH ever modifying
a message, and would have claimed that it doesn't do so.
Wow. Glad to see that there are still people interested in nmh out there.
I'm going to try to respond to a whole pile of messages at once rather than
flooding you with messages.
Autoconf: As long as we stick to simple usage it's fine. In general, I find
that the way that autoconf works,
And then an mhshow(1) that assumes a UTF-8 terminal
and converts headers and body to that for one seamless less(1)
I personally want mhshow to go away. It should all be integrated into show.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Jon Steinhart wrote:
While reading much nmh code these days, I also feel that parts of the
code are ancient. I'd like to support any effort in renewing it.
Autoconf is something I dislike.
I suppose that I'm willing to do some work here too if I'm not alone. My
main
interest
Jon Steinhart wrote:
Any attempt to rewrite or replace it ought to be preceded by the buildup
of the kind of test suite mentioned in the comments in m_getfld.c and
subsequently (alas) lost to history. (Some of the code in test/tests/inc
is trying to make a start on that.) But if you just
Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld
call
something that sort of looks like m_getfld but is different. Making it work
down
to all of the body parts would in my mind be architecturally better for nmh.
But,
as you say, more work.
So why not create
I'm starting to look at writing new code to handle reading MIME messages
as per the earlier discussion. My plan is to write a completely new
version of scan for people to play with, and to replace the original only
when consensus is reached on behavior.
I haven't paid attention to mail standards
Any opinions on how to deal with RFC2047 character sets? These are
an incredible pain.
I have written some other mail processing code that handles character sets.
This code works by converting everything into UTF-8 internally. It does
this by having mapping tables that map codes from various
On Sun, Nov 14, 2010 at 11:45 AM, Jon Steinhart j...@fourwinds.com wrote:
My preference is to say that we'll treat any =?...?= as an encoded word
wherever it appears and that we'll decode it. It appears that the authors
of
RFC2047 expect that everything will be parsed into tokens
Given the recent discussions:
Should we move the current nmh project to maintenance-only
mode, and start up a separate nmh2? It need not promise
perfect backward compatibility, I would think reason enough
to start anew.
And it could be written in C++ :-]
David
Sounds like a good
proposal:
Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
[2010-11-12 17:55] Jon Steinhart j...@fourwinds.com
I have difficulty seeing this as enough of a savings to be worth breaking
backward compatibility. If you really have to do this then you should
provide
Wow. Woke everyone up it seems. Good morning!
| A big thing that someone could do to help me with this would be to
| collect all of the various grammar into a single document.
Aside from intellectual curiosity, no, I don't think that's either
needed or useful. We know we can never
Maybe I don't understand your proposed changes. Apologies if I get this
wrong;
I didn't save a copy of your original email and the archives are currently
down.
There are currently -attach options on send and whatnow to support the
non-standard
attachment header. I don't even
On Thu, Dec 2, 2010 at 12:42 PM, Jon Steinhart wrote:
Correct me if my memory is failing me here, I'm being lazy and not rereading
rfcs at the moment because I have other things to do.
I recall that in the absence of appropriate headers messages are defined as
ASCII. If that's the case
Anyway, I guess my point here is: I'm thinking of converting nmh over to
Automake; I've started using it for a few projects here, and it just
Makes Things Easier. It could also make supporting things like
I'm fine with automake. It hides the ugliness of autoconf underneath
something
markus schnalke wrote:
(4) no attachments non-ASCII - no MIME; the message contains
non-ASCII chars; the recipient can not know which charset the
non-ASCII chars had been.
To cover case 4, one needs to run mime at the whatnow prompt manually.
Yes, and I find that annoying.
Sounds good. Is the patch that you sent out complete? I don't see an option
that enables/disables this behavior and I think that there should be one.
Jon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
The existing code takes a non-ASCII message body and sends it as an
attachment
of type application/octet-stream.
Your patch changes this behavior so that it is sent as type text/plain with
the
appropriately chosen character set.
You know I'm all for backwards compatibility and
I gotta say that I'm stunned by the amount of activity (and unnecessary
vitriol) on this topic. Where were you guys when I was begging for feedback
before I committed the changes a decade ago?
I originally implemented the non-ASCII message bodies as
application/octet-stream
because something
I personally think we have consensus on this should be changed, and
the new behavior should be the default; do other agree?
Just out of curiosity, what exactly do we mean by the new behavior?
I'm fine with changing how non-ASCII bodies are handled, I'm not fine
with changing how the -attach
I'm thinking about adding tab completion for file and directory names
for whatnowproc. Is that on anyone's to-do list??
steve
Not on my list but it be great.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I'm not an expert on IMAP. I don't use it and know very little about it. But
not being completely afraid to make a fool out of myself I have two thoughts:
1. I added code to nmh years ago that calls external hook programs when
messages are inc'd, rmm'd, and refiled. It does the right
--===6840960053006057842==
Content-Type: multipart/signed; boundary===_Exmh_1323651731_10493P;
micalg=pgp-sha1; protocol=application/pgp-signature
Content-Transfer-Encoding: 7bit
--==_Exmh_1323651731_10493P
Content-Type: text/plain; charset=us-ascii
On Sun, 11 Dec
Wow. What's the coder equivalent of the Purple Heart? Extreme
bravery in the case of old crusty code. Rescuing their comrades
from vestiges of the VAX.
While I'm too busy to participate in the current effort, m_getfld.c
has been the thing that's kept me from implementing the attachment
changes
Is there any way to change where nmh puts the draft temporary file? Never
paid much attention to this before, but nmh creates a file named @ in the
current directory when editing a draft. Normally not a problem, but I'm
working on a project that uses Dropbox, and when I compose a message from a
David Levine writes:
Jon wrote:
Is there any way to change where nmh puts the draft temporary file?
Never paid much attention to this before, but nmh creates a file
named @ in the current directory when editing a draft.
It shows up when doing a reply. I know that I don't have time
Ken Hornstein writes:
Is the attach command of whatnow making no attempt whatsoever to try
to determine the correct MIME content type specification? Is every
attachment just going to be sent as application/octet-stream?
Dude, you make it seem like using application/octet-stream is an
Ken Hornstein writes:
I agree. But times have changed, and it doesn't work well with new
stuff like dropbox.
Okay, I was confused a bit because you said the DRAFT temporary file,
but really the @ file is only created by dist and repl.
Jon, would you be happy with -atlink and -noatlink
Paul Fox writes:
jon wrote:
Ken Hornstein writes:
I agree. But times have changed, and it doesn't work well with new
stuff like dropbox.
Okay, I was confused a bit because you said the DRAFT temporary file,
but really the @ file is only created by dist and repl.
Jerrad Pierce writes:
An edge-case issue with @ be it in . ~/ or `mhpath +`
is that it does not allow for multiple concurrent replies.
Scripts should use the not-so-unintuitively named $editalt
to inherit the correct context. Humans will have to live
with @ pointing to the most recent
The only portion of the one I have here that seems at all relevant is
this:
For file names with dot suffixes, the context is scanned for a
mhshow-suffix- entry for that suffix. The content-type for
the part is taken from that context entry if a match is found.
If no
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
Lyndon Nerenberg writes:
On 2012-03-15, at 6:37 PM, Ken Hornstein wrote:
With X-MH-Attachment?
Could we please use nmh-* for this stuff? Just to make it clear this is
nmh-specific?
Are you suggesting having a header like nmh-attachment which is rfc-problematic
or just that we change
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
Paul Vixie writes:
On 6/25/2012 10:43 PM, Tethys wrote:
Ken Hornstein writes:
A possible way to solve the access to MIME parts problem
might be to store the parts as messageNumber.partNumber*
Creation of these parts would be optional, and eat space,
but it would make indexing/grepping
Paul Vixie writes:
On 2012-06-25 11:56 PM, Ken Hornstein wrote:
I also note that thread included someone (who shall remain nameless)
offering to design a new API to replace m_getfld() :-)
let's start talking about what it should look like?
Well, for starters, it shouldn't include any
Paul Vixie writes:
On 2012-06-26 2:28 AM, Jon Steinhart wrote:
Paul Vixie writes:
let's start talking about what it should look like?
Well, for starters, it shouldn't include any threatening commmentary!
Big thing that I think that it needs other than cleanup is the ability
to scan
Just upgraded. Have a message that looks like this:
To: gumby, djb
cc:
Fcc: ssc
Subject: Mucho Chango
X-MH-Attachment: /home/jon/cb/ssc/e2/embedded/io_board/ioboard.c
OK, this still needs some inspection and testing but to use
ra...@hep.wisc.edu writes:
I have...
send: -alias aliases -attach X-MH-Attach -attachformat 1
and just sent a PDF with the msg body in plain text via...
What now? attach ~/Quote_GSCQ33155_1344264047128.pdf
resulting in...
X-MH-Attach:
Ken Hornstein writes:
I took rader's issue to be that the plain text he wrote to accompany the
PDF has come out as application/octet-stream in base64?
Yeah, that's what I thought as well. That's what I tested and I couldn't
reproduce. If that is happening then that's a bug, of course.
Ken Hornstein writes:
The attach feature is really great! Thank you very much!!
I'd like to take credit for it, but it's really the brainchild of Jon
Steinhart, with a fair number of improvements by David Levine. My major
contribution was to make it work without having to configure
n...@dad.org writes:
I don't remember all the places I looked and things I tried, nor do I
remember the order in which I did them. But here are some o
f the things I tried:
man whatnow (It told me the feature existed, but not much more)
In my humble (but correct :-)
Ken Hornstein writes:
I guess I kinda believe the opposite. For example send won't send a
message if it doesn't understand any of the addressees. I think that's
a good thing. The general philosophy of mh was (contrary to the UNIX
philosophy) that if anything is wrong do nothing. For various
n...@dad.org writes:
Instead of saying what information should be in what man pages, and what man
pages should exist, let me opine a desideratum:
Granted that what goes on under the hood (relationship of attach to send etc.)
needs documentation, there ought to be documentation for the
Ken Hornstein writes:
We (by we I mean Steve Rader) did a one-time import; it's not
done every build (for one, not all systems have /etc/mime.types).
It would not be terribly hard to have nmh read this file on attach
or read it on nmh-install.
There is also the issue that if types are not in
n...@dad.org writes:
If a user doesn't want to use whatnow but wants to use
the attach feature, they could manage the magic headers
manually or via simple scripts (or now, mhmail).
But what if she's not as smart or as knowledgeble as you?
Then you, being smarter should help her out by
Ken Hornstein writes:
If a user doesn't want to use whatnow but wants to use
the attach feature, they could manage the magic headers
manually or via simple scripts (or now, mhmail).
Guys,
Is it me, or could we implement attach via:
% anno +drafts 1 -append -nodate -component
Ken Hornstein writes:
Ah. Well, if your argument is with the existence of whatnow as opposed
to the addition of attach to the existing whatnow we're in agreement.
As per other heated discussions on this list, there is a strong don't
break things mentality on this list (which got misplaced on
n...@dad.org writes:
It would be nice, if send would silently remove blank Nmh-Attachment headers.
Then users could put them in their templates. At composition time, they could
leave them blank, fill them in, or duplicate them for multiple attachments.
That way, folks like me, wouldn't
OK, gonna try to answer some questions quickly here. Real work is keeping me
pretty busy these days.
1. The attachment stuff all goes through the shell. See uip/whatnowsbr.c.
I am not really happy with this approach, but it seemed expedient at the
time. Would love to see something
Ken Hornstein writes:
what's happening is
execve(/bin/sh,
[sh, -c, $SHELL -c \ cd /tmp;ls `seq 1 5`\], ...) = 0
Yeah, I was actually thinking to myself when looking at that code, Hey,
doesn't our popen() use sh -c?
I look at this and I can't help thinking that's the wrong
I think this is all making an excellent argument for why all this built-in
magic should
be pushed to external programs, where the behaviour will be
1) predictable, and
2) customizable by the end user (e.g a profile element to provide an
alternative program to run).
All you need to do is
Lyndon Nerenberg writes:
On 2012-09-14, at 12:14 PM, Jon Steinhart wrote:
All you need to do is figure out how to track the current working directory!
The back end programs would exec() from the CWD, so they could
pwd(1)/getcwd(3)
as required. Obviously 'cd' must remain a built
1 - 100 of 186 matches
Mail list logo
