Ken Hornstein wrote:
> >I let the Mac and PC worlds distract me for a bit, but I'm really
> >tired of dealing with Calendar, Outlook, and the like, especially when
> >Microsoft is threating to change the user interface again. Is there
> >a calendaring program that uses a similar structure to nmh
Ralph Corderoy wrote:
> Hi Paul,
>
> > What happened to the possibilitiy of simply replacing the .fc macros,
> > and the use of tbl, with tab characters?
>
> Or one of the other alternatives I gave along with that one.
The "PROFILE COMPONENTS" section of inc(1) appears to use an alternative
I'm fairly sure they announced it on this list some time back.
For me, it solves the issue of wanting to use the command-line for mail in
general but also being able to access mail from a mobile phone (or HTML capable
mail client) using Maildir backed dovecot and IMAP.
The basic approach of
Ken Hornstein wrote:
> Hey, I believe I've fixed this; can you try it out?
That now works for me again. Thanks!
The reason for earlier commits failing that I mentioned in the original
message is down to to it now defaulting to port 587 instead of 25. The
fact that this is only configurable with
Ken Hornstein wrote:
> The more subtle thing is apparently you can do something like:
>
> -host "pop1.foo.com pop2.foo.com"
Yes that's an undocumented side-effect of the current code. I don't think
you need to worry especially about preserving it. ...unless someone is
either actually using it or
With a build from current git, post seg faults for me.
I've bisected this down to 5cb3431b (Add support for certificate
verification when using TLS).
New code in smtp_init() is assuming that the server parameter is a string
containing the SMTP server. It isn't unless you specify -server as a
Paul Fox wrote:
> i do. and i just spent some quality time with the git-grep man page,
> hoping that it had a -prune option. it doesn't. :-/ i'm surprised --
I'd recommend ag (the_silver_searcher) over git grep. It isn't specific
to git repositories. It also does have a --ignore option for
David Levine wrote:
> "X-" headers are deprecated by RFC 6648. We could add, say, a Mailer
> header.
User-Agent seems to be the newer replacement for X-Mailer. I don't know
if that's standardised or not other than in HTTP.
I prefer that we don't have Nmh- prefixes on our headers. Apart
from it
On 28 Sep, Ralph Corderoy wrote:
> I realise it's probably just the first one that came to hand, but it
> whiffs a bit, and
If you've got a good nose for it, could you perhaps try to sniff out a
better one. As you surmise, it was the first that came to hand. I just
did 'ag getline' in the opencsw
David Levine wrote:
> I added a welcome message when nmh detects that its version
> changed. You'll you see it the first time after checking out
> It's implemented by adding a Version: string to the user's context.
I like to have a different current folder in different terminals so in
my
On 23 Sep, Ken Hornstein wrote:
> I think that we are starting to get close to being ready for a 1.7
The latest code in git is failing to build on Solaris because it
relies on getline(3). getline was a GNU extension that has now been
added to recent POSIX specifications but may still be lacking
Ken Hornstein wrote:
Even if it can, I am unsure we can maintain
the correct column position when dealing with things like combining
characters.
That is possible. wcwidth() returns 0 for combining characters.
Do we have any specific cases where forcing a UTF-8 assumption actually
helps? The
On 9 Nov, Ken Hornstein wrote:
I have attached. I think it broke with nmh 1.6, it used:
mhshow-show-multipart/signed: sigcheck %a %F
That was probably my fault, but it would be helpful to figure out
exactly how it broke. It begs a larger meta-question: should we allow
a handler for
David Levine wrote:
2) For each switch, repl puts one pseudoheader in the draft of form:
Nmh-mhbuild-TYPE: [ARGSTRING] file://FILE
What is the URL style file:// syntax needed for? Is it sometimes http or
something?
Example 1, text/calendar:
1) repl switch -converterarg
David Levine wrote:
included with later MH distributions:
The scripts are in docs/historical/mh-6.8.5/support/general/
of the nmh git repo. Is anyone interested in improving/
updating them?
In the past, I used Neil Rickert's scripts which are at
http://faculty.cs.niu.edu/~rickert/mh/
They
Norm wrote:
I don't particularly mind seeing the  's. But they are a bit of a
nuisance when I select text and insert it into some file.
I will just have to get used to removing them. I could teach
norms-cool-editor to defaultly ignore them, or at least to not write them.
Maybe I will.
If
Ken Hornstein wrote:
What produces these? Can they be suppressed?
Like Paul said, they've always been there (they're produced by mhshow,
actually, and show will invoke mhshow as needed).
If you look at mhshow(1), you'll see this is related to the %l display
string escape for
Ken Hornstein wrote:
So, right now, the only way to make it work is as you've discovered;
always use $MHSHOW. I am sure this will be fixed for the next nmh
release (when that will happen, I do not know; hopefully it will be
sooner than 2 years, but I can't make any promises). I suspect a
Ken Hornstein wrote:
I don't quite understand how you made it work BEFORE 1.6; mhshow wouldn't
do any character conversion, for one. Also, it still won't reflow text
that's too wide.
You could use profile entries like mhshow-charset-iso-8859-1 to run a
script that would run iconv. The script
Ken Hornstein wrote:
Err ... that _would_ work with the proposed scheme, right? I mean, assuming
you had a profile entry that used w3m to convert the HTML to text, this
would continue to work. So I'm unclear why we need two mechanisms.
Yes, it continues to work. I should probably just think
Ken Hornstein wrote:
In MH/nmh, each part was processed individually. Combining them all under
one pager works great for text parts, but if you have graphical content
then it sort of falls down, because you might want confirmation of that.
But in my experience, usually you can divide your
otah...@gmx.ca wrote:
Thanks for the clarifications.
What about ease of use, especially from a newbie perspective?
Also, which scripting language would you suggest? Is there already a
repository for nhm scripts?
There's a good number of example scripts in Jerry Peek's MH book† though
that
David Levine wrote:
While cleaning up the tmp files, I noticed a potential security
issue. mhshow, mhn, etc., used to create temporary files using
mkstemp(3) and then rename(3) them in order to add a filename
extension that reflects the content type. E.g.,
/tmp/mhshowXYZ123.html. rename
I find it happens quite often that I receive an e-mail where someone
has attached something that is likely to be plain text (such as a diff)
but their mail program has marked it as application/octet-stream.
Viewing such attachments ends up being a bit of a hassle because they
need to be stored in
Ken Hornstein wrote:
What I took away from our last conversation on this topic was that GPG
has a different canonical form than S/MIME. I personally view that as
another reason to store the original, but that's just me.
From memory, you have to put DOS line endings in for GPG/PGP which isn't
I noticed that en_US.UTF-8 appears in hardcoded form in the test cases.
Knowing that my system doesn't have it, I tried running the test cases
and, sure enough:
Unable to convert string →n̈
test/scan/test-scan-multibyte: 59: test: Illegal number:
test/scan/test-scan-multibyte: 63: test: Illegal
You wrote:
/bin/sh -c 'proc $@' dummyarg arg1 arg2 arg3
What do others think about this? Anything I'm missing?
Seems like a nice trick to me. I like how it ensures expansion of any
arguments from .mh_profile without doing expansion on further arguments
provided by nmh.
I've thought about
My script for handling replies relies on the $editalt variable. This
broke recently and git bisect pointed me to commit 25581a94 which makes
-noatfile the default. I don't care too much for the @ file but need
$editalt.
Does -atfile have wider effects than merely disabling the @ file or
is there
Ken Hornstein wrote:
- I'm fine with moving stuff into $(prefix)/libexec; the reason those
programs were in $(libdir) was historical, and I think MH predated hier(7).
I have no doubt this will screw over someone :-/
Note that hier(7) makes no mention of libexec. libexec is an invention
Ken Hornstein wrote:
My thinking was to add an extra parameter to fmt_scan() that meant the buffer
size available and limit the output based on both the number of characters
and the total buffer size. This is easy enough to do, but I realize that
Multiplying maximum width by MB_CUR_MAX is one
You wrote:
What do you people do in such circumstances?
I simply do ssh from my phone. I have a Nokia N900 which has a hardware
keyboard and even comes with an xterm application. With Android, you
should be able to get a terminal and ssh client. You might also want
to put an alias in
David wrote:
Thank you for analyzing this and providing a patch. I
have one question. The patch removes the setting of
t-tx_charset. Should we retain that? It's used in
mhbuild, I believe.
It seems this was broken in the first place in 636b3bab. That change
merged similar code from mhshow
Ralph Corderoy wrote:
David Levine levin...@acm.org writes:
Note that whatnow's attach will continue to allow attachment of
directories because it expands those out to their contents. It
doesn't check what the contents are, though. That's why we needed
to add this check.
I
David Levine wrote:
Note that the current attach -r is an undocumented relic of the
implementation, because whatnow passes the -r to ls. Maybe it
shouldn't even be allowed. The whatnow documentation specifically
says attach files.
attach clearly passes any option you like to ls. And note
David Levine wrote:
Does POSIX ls support -- ?
Yes. POSIX basically requires it for all utilities. See Guideline 10,
section 12.2. It works on the oldest systems I can currently log into
and I'm fairly sure I've used it since a long time ago. glob(3) would
probably still be a more robust
David Levine wrote:
We'd need a new mts value, in addition to the current smtp
and sendmail, in mts.conf to select it. spost, unless
there's a better idea?
If all it does is pipe the message content in to sendmail's stdin then
how about pipe. Or is it actually giving sendmail a file (the
You wrote:
i noticed that the provided mhl.* and scan.* and repl*comps aren't
uniform in their use of decode for address fields. for instance, To
and Cc headers don't ever use it, and From and Reply-to are
inconsistent as well. is there any reason not to simply use it
everywhere?
We
Ken Hornstein wrote:
Oliver, what does SHELL get set to in the nmh Makefile? It might be as
It gets set to /bin/bash.
I suppose you have to consider that autoconf is a FSF thing so it
will try to find GNU stuff first, much as it will default to GCC over
Solaris Studio, gawk over nawk etc.
The
Ken Hornstein wrote:
I know this was six years ago, but I'm wondering if a) you remember exactly
what you were trying to solve and b) if we could fix it another way. I
have thought about various code fixes but they all have issues. We
have the %(trim) function available in mh-format; we
n...@dad.org wrote:
I'm very sorry. I was unclear. As far as I know, the problem probably has
little
to do with the upgrade. I recently installed Linux on the computer in question
(It previously ran Microsoft Windows), so I installed the latest version, 1.4,
of nmh on it. I have had
n...@dad.org wrote:
Folder name completion was what I wanted for. I guess that it's not to be.
If it is decent completion you want, then I would very much recommend
you consider using zsh instead of bash. It has good completion for MH
built in; just do: autoload -U compinit; compinit
I would
Lyndon Nerenberg wrote:
On 2012-02-07, at 3:00 AM, Oliver Kiddle wrote:
I'd prefer to just see the email. mhshow could have a -pedantic or -lint
option.
Or you could use cat(1).
Well that's what I do do.
It's great that MH makes that easy and there are various situations in
which I
Ken Hornstein wrote:
- If we have to choose one, the only logical choice is Unicode (which in
practice means UTF-8; maybe UTF-16, but a trip through the format
code made me think that UTF-8 is probably the only real choice).
One very reasonable option would be to use the current locale
Jon Fairbairn wrote:
Long ago, before mh I used an email system that stored email in
files with unique ids, which suggests a way to do this. Switch
to storing messages in (say) date-named accession order folders
with unique filenames (derived from the message-id, or simply
accession
n...@dad.org wrote:
Could somebody please tell me how I can install the current version of nmh on
RedHat 6.1? Is there on rpm somewhere?
What I usually do is try to find the .spec file from Fedora and build an
rpm using that.
The Fedora files are here:
On 11 Aug, Tony Winn wrote:
Undefined symbols for architecture x86_64:
_libiconv_close, referenced from:
_decode_rfc2047 in libmh.a(fmt_rfc2047.o)
It'd be good to see the iconv related output from configure.
Most likely it is getting iconv.h from GNU libiconv but when linking
-liconv,
On 19 Nov, Ken Hornstein wrote:
Oh, I also added TLS support for the SMTP MTA. I tested it a bit, and
it seems to work fine. SASL also works with it (but SASL encryption is
turned off if TLS is in use), so if you need to use TLS plus authentication
it should work fine. See --with-tls and
I've had a look through for any pending patches since the last release.
Mostly, this is Meillo's recent patches. Does anyone know of any further
patches that we might apply or rework.
Eric Gillespie: scan message numbers from stdin
It looks like people were generally in favour in
Peter Maydell wrote:
undo of install-mh
What did you think of my proposed patch to the manpage?
Telling people to do
echo ${MH:-$HOME/.mh-profile}
Is not going to work for users of non-Bourne based shells. May be easier
to just say that .mh_profile is in the home directory unless the MH
valdis.kletni...@vt.edu wrote:
Current -git tree:
% inc -help
inc: no mail to incorporate
% inc -version
inc: no mail to incorporate
I've just checked in a fix for this. Problem was introduced with c0521048;
that removed a pile of switches to inc and msgchk by removing lines
such as the
Peter Maydell wrote:
Has there been much of interest gone in since 1.3 to merit a 1.4?
If not, we could still release a 1.3.1. I'm a fan of the release early,
release often principle.
I did the 'turn handle, release nmh' work last time round but I'm
currently horribly busy so am unlikely to
Ken Hornstein wrote:
So, I vote we move to git; objections?
I'd be very much in favour of a move to git.
I could put up with svn, if only because git-svn works very well.
You're one of the people with the requiste savannah permissons to effect
the change, right?
David Levine writes:
Should
Eric Gillespie wrote:
The default behavior of throwing new xterms at me out of nowhere
is horribly annoying.
Does anyone still have it configured to do that instead of having it
just invoke iconv, recode or similar.
That's not to say that that's easy. Combine a setting for
Joel Reicher wrote:
Which is just a multi-folder scan. It might be better to adapt scan so
that you can specify multiple folders with a sequence.
What would you want for the context change? Change to the last folder on
the command line, or no change at all when multiple folders are given?
Eric Gillespie wrote:
for as long as I've used mh, and I've used this much faster
reimplementation in my local mh tree for the last couple years.
I hate to be negative but my main objection to these commands is that
they are hardcoded to the unseen sequence instead of being more general.
All
Peter Maydell wrote:
My impression from the changelog was that that was in 1.2 --
Sorry, seems the iconv change was in 1.2 but the handling of multi-byte
characters for field widths in scan listings wasn't.
Oliver
___
Nmh-workers mailing list
On 4 May, Russell Ruby wrote:
There were a few build and run glitches needing fixing, but nmh-1.3-RC1
has now been chewing through mail just fine for the last few days.
I have submitted a couple of patches in the project bugs section so
far, but forgot to reference nmh-1.3-RC1 in the title
It'd be good to get acconfig.h cleared out because it is an obsolete
autoconf feature (and autoheader keeps complaining about it).
Does anyone still tweak any of the options in acconfig.h? We can either
add configure options, remove the macro and hardcode one behaviour,
leave the macros but use
It'd be good to get acconfig.h cleared out because it is an obsolete
autoconf feature (and autoheader keeps complaining about it).
Does anyone still tweak any of the options in acconfig.h? We can either
add configure options, remove the macro and hardcode one behaviour,
leave the macros but use
[EMAIL PROTECTED] wrote:
Of course this is all rather mishandled anyway. What we ought to be
doing is letting the user read and compose messages in their local
charset (as defined by LC_CTYPE) and using iconv to automatically
convert to/from whatever charset is required for the email being
[EMAIL PROTECTED] wrote:
I just did a 'cvs update', and the resulting tree was lacking a config.h.in
which the configure script wanted:
Try running autoheader and autoconf first. config.h.in is a generated
file.
Oliver
This e-mail and any attachment is for authorised use by the intended
Paul Fox wrote:
it occurred to me yesterday that this script might be quite
useful (instead of just pretty :-) if it had one simple feature:
the ability to add each thread to a separate, temporary, mh
sequence (t1, t2, t3, ...). the output would then include
Instead of creating, multiple
Ralph Corderoy wrote:
Yes, I'm hitting it daily and having to work around it. Given the
increase in space and time of computing resources, it's now practical to
have +inbox containing thousands of emails and have a script that picks
them into many different sequences in reasonable time
Jon Steinhart wrote:
The attach command is convenient though. Perhaps if the -attach option
is not set in .mh_profile, attach could add an mhbuild directive to the
body.
I'm not sure what you mean by this. Are you suggesting that if some option
is not set in the profile, then the
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 though. Perhaps if the
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 the attach
whatnow
David Levine wrote:
Any suggestion on how to associate the option values with the build
directive? printf style?
whatnow: -attach X-MH-Attachment='#%T; name=%N %C[%D; %M] %F'
I don't see why that needs to be configurable instead of hard coded.
whatnow? attach
Joel Reicher wrote:
Does anyone know why the contents of papers/ from mh-6.8.4 aren't in
the nmh distribution?
I wouldn't know but their content is sufficiently old that they don't
have much value other than historic interest. Jerry's book is more
useful as a tutorial and reference. It's
Joel Reicher wrote:
I believe this will work, and doesn't have the problem with gaps in
message numbers that kre's script does.
How about the following:
last=`mhpath first:$((2*n)) cur:$n|tail -1`
last=${last##*/}
scan $last:-$((2*n))
Oliver
This e-mail and any attachment is for authorised
Any thoughts on the following patch? It gets rid of the DATE file and
has the date automatically updated when autoconf is run. This has the
advantage that the date will be automatically updated when a release is
made and the man pages won't read 1 Jul 2003 for ever. It also means
the date gets
The following patch removes remaining code for dealing with MMDF. The
mts/mmdf directory was long ago removed so this code is currently
unusable.
Any objections to removing mh-mts.8? There really is no useful
information left in it and any MTS related information would probably be
better placed
Ken Hornstein wrote:
I have mail stored on an IMAP server. I think it's perfectly
reasonable that I should be able to do scan +IMAP:inbox (or however
you want to indicate that a particular folder is on an IMAP server; I
Why not extend that to +mbox:inbox for mbox folders?
Seriously, though,
Nathan Bailey wrote:
PS: Another couple of things I'd like to see on the MH wiki would be:
i) How do you do 'To/Cc/Dcc/Bcc' field completion? (i.e. in the same way
the GUI clients do, or web browsers do for URLs). Special bonus if your
solution supports an LDAP directory (i.e. not just
On 23 Dec, you wrote:
I want to do IMAP too. I have an idea for design:
If I had a need for IMAP support, I would sooner consider writing a FUSE
module for an IMAP filesystem. It'd have more chance of working with
scripts written around MH because non-MH commands would work.
Short of a grab
On 20 Nov, Igor Sobrado wrote:
I am building the latest release candidate of nmh-1.1. From the output of
the compiler I see that there are *a lot* of uninitialized variables. Really
a lot of them! I will use this nmh release candidate on a machine were I am
I would be inclined to think that
[EMAIL PROTECTED] wrote:
Jon Steinhart wrote:
In the meantime, I'd rather
concentrate on fixing critical things so that we can get the release out.
We could create a branch on CVS if anyone really does have time for
something new.
So, what have we still got to fix? I hope this list is
[EMAIL PROTECTED] wrote:
Places I haven't looked:
* archives of this mailing list (sorry, I ran out of time this morning :-))
I just did a quick search and found the following:
http://www.mhonarc.org/archive/html/nmh-workers/2004-02/msg00020.html
-- AFS fix where files didn't appear to
[EMAIL PROTECTED] wrote:
I notice that the GNU make info manual claims that this:
install uninstall: FORCE
# rule with no prerequisites or commands, and there's no file 'FORCE':
FORCE:
has the same effect, and doesn't rely on GNU make extensions.
We should check that that works on Mac
lookup revealed misconfiguration: Error during DNS A lookup
for rly11e.srv.mailcontrol.com: DNS alias found where canonical name wanted
[Irritated]
Oliver Kiddle wrote:
2, 4, 6, 7: already fixed in CVS (6 is the vfork issue)
1 (194349) 3 (261089): man page sections: distribution specific
5
[EMAIL PROTECTED] wrote:
I don't mind committing it to CVS; the question is whether you want
to add people to the CVS access list who might commit two or three
fixes and then do nothing for six months. (I don't often have time for
nmh work.) I've appended the patch to this email, anyway.
Bill Wohler wrote:
Various files reference the old mailing list address and the old web
site address. Do a grep for mhost.com. Question 3 of the FAQ is also
out-of-date.
Thanks, Oliver. I assume you're referring to:
I was actually referring to the docs/FAQ file within the nmh
Tet wrote:
These days, yes it is. The number of systems actually running nmh without
COW is probably pretty negligible by now. Even for those where vfork()
is actually faster (like NetBSD, for example), there's no real advantage
to using vfork() unless you're forking an awful lot of
There are quite a few patches on savannah or the mailing lists which
have never been applied. Given that people went to the effort of
creating these it is silly for them to go to waste. Over the past year
or so, installing nmh for me has meant checking the source out of CVS,
applying a couple of
Paul Fox wrote:
in general, i agree, and it was my first reaction, after seeing
that content-disposition has been on the mh todo list for a
number of years. in this particular case, the changes aren't for
me -- they're for my wife, to use at work, where she's been
burned in the past by
Paul Fox wrote:
so basically, the entire text between the { } pair would fully
specify the Content-disposition header, but that unlike
Content-description (which has no default value), the
Content-disposition header would have a default value of
attachment; filename=file basename
does
Paul Fox wrote:
i have what feels like a simple problem.
i want to post-process the output of mhbuild to add a Content-disposition
header after any Content-type header that matches some criteria.
Wouldn't it be easier to just edit the C code? Out of interest, why do
you want to do this? Are
On 14 Feb, I wrote:
It's probably easier to hack the C code. I've had a quick go at
producing something which uses iconv to convert stuff to the native
character set (patch is below). Would be good if you could try this out
and look for ways to improve it.
I've now produced something good
A little while back, I noticed that inc crashes if I have logged in
using su from another user. Having investigated, it is the code which
reopens the terminal to read the password. When logged in using su, this
is still owned by the original user so the fopen fails. It ought to be
opening /dev/tty
Paul Fox wrote:
it seems that this patch relies on other local changes you've
made to your tree -- i went searching for get_charset with google,
and came up with a message you sent to this list on january 24
which contained such a routine, in different mime-related patch. :-)
The patch is
[EMAIL PROTECTED] wrote:
In general, you *can't* do a good job of using iconv to mash things between
the various iso8859-* charsets. There *will* be lossage - after all, there
is a *reason* they're up to -15, namely that one isn't sufficient. So
whichever
one you're in, there *will* be
Paul Fox wrote:
can nmh decode UTF or otherwise-encoded headers? it's not that
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a UTF-8 locale and set
You wrote:
i guess i was thinking of a wrapper for scan or show that took care
of setting up the locale and charset, either via argument for manually
choosing, or maybe even by examining the message and then figuring out
what locale/charset it should probably use, this time.
It's probably
One of the patches I apply against the nmh sources is a modification of
Michael Richardson's patch which can be seen here:
http://www.mhonarc.org/archive/html/nmh-workers/2002-07/msg0.html
My modification to it is to run a different command to get around a
firewall issue I have. Anyway, I've
On 21 Jan, wrote:
a user may have done 'export MM_CHARSET=$LANG;', so we might want to check
if UTF-8 is found anywhere in the string:
User's really shouldn't set MM_CHARSET like that. That'd result in
outgoing mime messages having something like charset=fr_FR.UTF-8 in
the Content-Type
On a new Linux installation, I have a UTF-8 locale enabled by default.
For this reason, I set MM_CHARSET to UTF-8. Recently, I noticed that
show invokes mhshow for messages with:
Content-Type: text/plain; charset=us-ascii
whereas that doesn't occur for ISO-8859-1.
UTF-8 is just as compatible
The following patch is a fix to the second bug I described in my message
to the list on 1st September (see
http://www.mhonarc.org/archive/html/nmh-workers/2004-09/msg2.html).
Because I regard this as a bug fix, I'll commit it to CVS unless anyone
complains first.
The problem was that when
96 matches
Mail list logo
