ease.
commit 937ee92013bed7b3ebd30fff2c17a751d37b1a61
Author: Ralph Corderoy
Date: Sat Aug 19 15:58:49 2017 +0100
test-sendfiles: Feed `lzma -cd' stdin rather than a filename.
Håkon Alstadheim reported that Debian's lzma-9.22-2 would complain at
`lzma -cd fo
Hi,
> Good point. I'm not too sure either; it depends what the current
> needs are...
So my email above had this part to it, that made it through the list
back to me.
> Content-Type: message/external-body; access-type="url";
> url="dict://dict.org/d:yagni:foldoc"
>
> Content-Type: text/p
Hi,
> Good point. I'm not too sure either; it depends what the current
> needs are, or what they would be if the code was nicer. Options
> include: just using atexit(3); ...
With good timing, this just cropped up.
With gcc 4.9.2, `-O -D_FORTIFY_SOURCE=2', on
1.6-branchpoint-1494-g23645d5, I g
Hi David,
> > valgrind here, 3.13.0-2, doesn't complain about the printf, and that
> > prints zero. That puzzles me.
>
> Yes, interesting. Have you tried with -O0?
gcc 7.1.1-4. valgrind 3.13.0-2.
With -D_FORTIFY_SOURCE=2:
-O0 Compile fails; optimisation needed.
-O2 valg
Hi David,
> > There are probably various valid paths where a program exit(0)s that
> > don't write the context file.
>
> Yeah, yet another unification target.
Germany's was a cinch compared. :-)
> > sbr/done.c's done is a file pointer that often points to exit(3).
> > Is it just a poor man's at
Hi,
I've been doing `inc -version' before and after upgrading the installed
nmh as 1.7-release changes to check it went OK. I noticed this
behaviour.
$ cat ~/mail/context
Current-Folder: inbox
Version: nmh-1.7-RC2
$ sed -i 2d ~/mail/context
$
$ inc -version
==
Hi,
David wrote:
> Ken wrote:
> > And dang, coming up with a test for the url external-body type is
> > going to be a pain.
How about
Content-Type: message/external-body; access-type="url";
url="http://google.com/robots.txt";
Could have https too. They could be skipped if a curl(1)
Hi Ken,
> Huh, the HEADERS have ^M on them?
I've tried slapping CR at various places on the email that was
originally attached and can't get mhfixmsg to go wrong. The original
that has the problem would be handy to find the issue and come up with a
minimum test case if it is a nmh bug. And it p
Hi Håkon,
> Which is smaller. Update: You pointed out the carriage returns. Can
> you send the problem email as a .tar.gz or something that will leave
> everything alone.
It would still be useful to have that to reproduce the mhfixmsg problem
here.
> > > 11.tar: unknown suffix -- unchanged
>
Hi Håkon,
> $ mhlist -version
> mhlist -- nmh-1.7-RC2 built 2017-08-18 11:32:04 + on garbo
> $ mhlist 1
> mhlist: bogus multipart content in message 1
> msg part type/subtype size description
>1 multipart/mixed32K
And yet I got
> > $ mhlist -file 9707
Hi Håkon,
> Trying to run mhfixmsg on it just removes the entire body of the mail.
Can you give a command that fails? It seems OK here.
$ mhfixmsg -version
mhfixmsg -- nmh-1.7-RC2 1.7-RC2-1-g42b75672 built 2017-08-18 06:44:22 +
on orac
$ scan -file 9707.2.email -format '%{messa
Hi again,
> Same for a negative number. (Try passing -1718 to fmttest.)
$ fmttest -raw -format '_%4(putnumf)_' ''
_ 0_
$ fmttest -raw -format '_%0(putnumf)_' ''
^C
$ fmttest -raw -format '_%(putnumf)_' ''
^C
$
The last two get stuck.
--
Cheers, Ralph.
https://plu
Hi Valdis,
> Actually, could use that now, I've been using a git tree copy for quite some
> time now... :)
Good show.
> man mh-format says:
>
>When a function or component escape is interpreted and the result will
>be printed immediately, an optional field width can be speci
Hi Ken,
> I'm not really liking the idea of having a code fix that only appears
> on the release branch. I'd rather have the same code in 1.7 and
> master. So I say apply the re-write to 1.7.
OK, I'll check-pick these across to the branch a little later on then.
Let me know if that's not the ri
Hi Ken,
> So, I guess I'm a liar ... turns out MacOS X _does_ define
> __WCHAR_MAX__. Although it seems like WCHAR_MAX is the correct macro
> according to POSIX, so maybe getcwidth.c should still switch?
Yes, I can't recall why I plumped for the __ version now. I've pushed a
fix. Indentifiers
Hi,
What use is whatnow(1)'s -prompt option? The man page says
The -prompt string switch sets the prompting string for whatnow.
It doesn't document that it's subject to printf(3) expansion and
provided with a single argument that's the program's name, i.e.
"whatnow", unless you copy it to s
Hi,
I've opened https://savannah.nongnu.org/bugs/index.php?51693 to track
this because I don't have time at the moment, but I don't know who gets
those "bug opened" emails so here's a copy.
$ git describe
1.7-branchpoint-10-ga091c28b
$ uip/scan -format '' -file /dev/null
scan: sbr
Hi David,
> > Sunglasses have a width of 1 here, that's why David and I don't see
> > the problem.
>
> I'm surprised that I didn't see the same behavior as Norm, because we
> use the same locale, en_US.utf8. Any idea why?
I'm en_GB.utf8, but I don't see it either. It's the wcwidth(3) answer
for
Hi,
David wrote:
> > inc seems to have a similar, if not identical problem.
>
> It's identical: inc uses the same code to print the scan line.
I was surprised recently when plodding through the source that inc(1)
actually uses the scan() function to do the inc-ing, with the scan as a
side effect
Hi Leonardo,
> At least regarding the `make check' (always on NetBSD/amd64 8.99.1),
> all 104 tests are passed and 7 tests were not run.
Great, thanks.
> Regarding the not run ones (all expected):
>
> ./test/oauth/test-inc: skipped: no oauth support
MACHINES says that's ftp
Hi Leonardo,
> Sure! Here what I see with your patch applied:
>
> % scan -format '%(decode{subject})' +. 1
> mbtowc(0x20) = 1
> cntrl:0 space:1 blank:1 print:1
> mbtowc(0x1f576) = 4
> cntrl:0 space:0 blank:0 print:0
> wcwidth(0x1f576) = -1
Yeah, I think the code was assuming if it's n
Hi Leonardo,
> (gdb) print wide_char
> $2 = 128374 L'\x1f576'
> (gdb) quit
>
> L'\x1f576' (in wide_char) is probably the `dark sunglasses' (U+1F576)
> unicode character
It is. One of three non-ASCII characters in that subject.
$ uip/scan -file 8759.2.email -format '%(decode{subject})' |
Hi again Norm,
I wrote:
> Could you run this scan command with 1.7-RC1
With Leonardo's reply, there's no need to bother.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu
Hi,
> Assertion failed: (w >= 0), function cpstripped, file
> ../nmh/sbr/fmt_scan.c, line 291.
char_len = mbtowc(&wide_char, str, len);
if (char_len < 0) {
altstr = "?";
char_len = mbtowc(&wide_char, altstr, 1);
}
I wonder if mbtowc()'s internal sh
Hi Norm,
> scan applied to an Email like the attached dumps core. I will send
> more particulars, on request.
Could you run this scan command with 1.7-RC1 to make sure it still has
the assert(3) failure on the problem email.
scan -format '%(decode{subject})' cur
And then repeat that but und
Hi Ken,
> Ooof, I get:
Like David, I don't. The Subject is two lots of base64 that I think
decode to
f0 9f 95 b6 53 75 6e e2 80 99 73 20 6f 75 74 2c |Sun...s out,|
0010 20 73 61 76 69 6e 67 73 20 4f 4e e2 80 94 73 68 | savings ON...sh|
0020 6f 70 20 6d 61 6a 6f 72 2
Hi Conrad,
> packf leaves "..map" files lying around my mail directory; this
> is documented in the man page as a "binary index". Is there a point to
> this file? Better documented elsewhere?
Support was deleted in
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=e6c917710e4318949cb4174cabca
Hi,
I've seen this on and off and can now describe when it happens.
I normally run ./configure in a git checkout of master.
#! /bin/sh
cc='ccache cc' # -pg
opt=-O3
bs= #-DBUFSIZ=225
tls=yes
oauth=yes
readline=yes
rm -f config.cache
./configure \
CC="
Hi Ken,
> Ah, I remember why I use GPG; that's a savannah requirement that they
> put in place after a break-in. I think, when I looked at it, there
> wasn't an obvious cross-platform checksum program.
No, they've all slightly different names, but produce the same digest.
> To me, that's one of
Hi Ken,
> I guess I was thinking if the concern is the distribution has been
> compromised by attackers they could produce a bogus hash file, but not
> a GPG signature (at least hopefully not one signed by me).
True, but some won't bother with checking a GPG signature, is it `gpg
--verify foo.sig
Hi,
Corporations are increasing slapping needless, bloated, branding images
onto their emails, ones I want to keep. I've a crude `shrinkimg' script
that replaces the image's data with a tiny one whilst keeping the type,
e.g. PNG, so any internal references to it are still valid. I was
thinking m
Hi Ken,
> > I used https and it worked fine.
>
> Fair enough; the links to the download area are all http, and the
> release DOES have a GPG signature (which I suppose we don't
> advertise), so I didn't think about it.
SHA-1 and SHA-256 might be what folks are more used to checking against.
The m
Hi Ken,
> and the first release candidate is now available!
Well done.
> You can download it here:
>
> http://download-mirror.savannah.gnu.org/releases/nmh/nmh-1.7-RC1.tar.gz
I used https and it worked fine. Can we switch to that from now on;
those that can't handle TLS for some odd reason
Hi Ken,
> So, I am wondering if there is anything people are working on that
> they would like to get in before we start the 1.7 release cycle?
No.
> Thoughts?
Release early, release often. :-)
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Hi Bob,
> I have a sufficiently non-standard install. Specifically, I prefer to
> use ctwm instead of any of the modern "desktops"
Arch Linux's install media leaves one at a VT with a shell.
https://wiki.archlinux.org/index.php/Installation_guide runs through the
next steps, Internet access, par
Hi Bob,
> (I originally intended to use 13.10 until 14.04 LTS came out.
> Laziness. B-)
Erm, I was Ubuntu 10.10 until 2016-02-13 when this Arch Linux took over.
:-) Finding the block of time to do the Ubuntu upgrade was a chore, and
the next one would pile up behind it. With Arch, it's a rolli
Hi Bob,
> I didn't install all the build tools I needed before the Ubuntu 13.10
> repositories were decommissioned.
You might find the "old-releases" repositories useful to plod along with
13.10. https://help.ubuntu.com/community/EOLUpgrades/
--
Cheers, Ralph.
https://plus.google.com/+RalphCor
Hi Bob,
> Out of curiosity, would it help to have "micro-volunteers" to update
> the testing?
I'd have thought so, though David is, I think, the main person behind
the test suite.
> namely having (sufficient) test coverage,
...
> If enough of us do that, maybe we could significantly improve
> co
Hi Ken,
> > As for inc being silent, «inc -forma ''» almost achieves that apart
> > from the annoying, noisy, non-Unix, "Incorporating new mail into
> > inbox...\n\n".
>
> Well, there IS also >/dev/null, this being Unix and all :-)
Yes, this is true. :-) But both should really be given because
Hi Ken,
> > How about giving inc(1) a [-sequence foo]... that added the
> > incorporated emails to the sequences. The user's script could then
> > cook up a unique sequence name, run inc, then pick(1) and mark(1)
> > their way through that sequence doing what they liked.
>
> I like it; keeps the
Hi Thomas,
> You make it sound like the lack of capacity stemming from the
> volunteer nature of the project is bad. I disagree. nmh could never
> exist as a commercial project because it's too good and simple; in a
> company developing nmh, the workers would have to add lots of garbage
> features
Hi Ken,
> If the goal is to filter messages at "inc" time, then I'd guess that
> the best thing to do would be to add a new interface that allowed you
> to tell "inc" where you wanted the message to end up.
Sounds complex. How about giving inc(1) a [-sequence foo]... that added
the incorporated
Hi Laura,
> 374 06/01 Jacob Hallén Fang Yuan Shi Wu<>
I would guess the `From' header encoded `Hallén' and nmh was happy to
decode. Judging by the single question mark, I think the body has a
single byte for the `ö', but that isn't valid for its stated encoding,
e.g. UTF-8.
It would be u
Hi Ken,
> * It appears that some versions of Sendmail will return Code 451
> * when they don't really want to indicate a failure.
> * "Code 451 almost always means sendmail has deferred; we don't
> * really want bomb out at this point since sendmail will rectify
> * things later." So, if you
Hi Ken,
> I'm still surprised that in 2017 the main SMTP server for a large
> university would support TLS 1.0 as the _highest_ protocol.
Agreed.
> I can understand supporting TLS 1.0 in addition to TLS 1.1 and 1.2 to
> handle support for older clients, but NOT supporting TLS 1.1 or 1.2
> seems
Hi Ken,
> But AFAICT all MTAs store their maildrops in mboxo format (at least
> the ones that use mbox format do). I couldn't find one that used
> mboxrd format
Not qmail? http://qmail.org/man/man5/mbox.html describes mboxrd by
default, and then describes how qmail-local locks the file.
> > I
Hi Johan,
> > Not really, if: /usr/bin/nmh mmdfunburst
> > really does exec(/usr/libexec/nmh/mmdfunburst)
>
> This is what git does.
Yes, for some commands. Others are built in, e.g. `git status'.
I was thinking most sub-commands would be fairly trivial and structured
as a function call or two,
Hi Valdis,
> > Here are man pages sourced by other "one line" man pages.
...
> > man5/mh-profile.5 ← man/mh_profile.man
> > man5/mh-tailor.5 ← man/mts.conf.man
> >
> > The files they document are $HOME/.mh_profile and /etc/nmh/mts.conf.
> > I don't think mh-profile(5) and mh-tailor(5) shou
Hi,
Here are man pages sourced by other "one line" man pages.
man1/new.1 ← man/fnext.man
man1/new.1 ← man/fprev.man
man1/new.1 ← man/unseen.man
Those three make sense give new(1) says
fnext is equivalent to new -mode fnext
fprev is equivalent to new -mode fprev
unseen is
Hi Ken,
> I realize this wouldn't happen for likely a while, but would people be
> happy with just mboxo and mboxrd support in terms of maildrop parsing?
Those two seem sufficient, but the user would have to state which their
system used?
> And does anyone see Content-Length headers in their mai
Hi Ken,
> Hm. I am reluctant to remove functionality that people might find
> useful; what do others think?
David said off-list that he occasionally uses `repl -file' so I guess
they stay. Just axe the `msh' comments?
I meant to say last time, we could maintain statistics under `mhpath +',
e.g.
Hi Ken,
> >uip/forw.c:X("file file", 4, FILESW) /* interface from msh */ \
> >uip/repl.c:X("file file", 4, FILESW) /* interface from msh */ \
>
> I am wondering if any third-party tools use those switches? A quick
> grep suggests that exmh does NOT; what about MH-E?
Some git-grep
Hi,
Mopping up remaining bits of the deleted msh(1), I find
uip/forw.c:X("file file", 4, FILESW) /* interface from msh */ \
uip/repl.c:X("file file", 4, FILESW) /* interface from msh */ \
They're in the commands' man pages.
Should they stay or should they go nooww?
--
Cheers, R
Hi Mark,
> Or were you thinking that /usr/bin/nmh would have functionality that's
> not available in any other executable, rather than just being a
> front-end, and there wouldn't be a stand-alone program 'mmdfunburst'?
Yes, new exclusive functions rather than a veneer front-end.
--
Cheers, Ral
Hi Mark,
> Do you mean /usr/bin/mh as a sub-directory?
No, a new executable, e.g. `mh foo', `mh bar'.
> I'd think that "unpackf" (or "burstmmdf") might be better off in
> /usr/libexec/nmh.
Seems off to bury a command a user would want to run off-PATH over
there?
--
Cheers, Ralph.
https://plus
Hi,
It's the "nmh" project, used in URLs, mailing lists, etc., but MH is
still prevalent in command names, ~/.mh_profile, etc., which is fine.
We've lots of user commands, and have created ones that seem to
potentially tread on others' toes a bit with their genericness, e.g.
new(1). We've also g
Hi Ken,
> > msh has gone post 1.6. Can inc's -pack die too
> > before 1.7? It seems there's quite a bit of lingering msh rotting away.
> > :-)
>
> I say, "Oh, hell YES!"
Done that with 6170b76c. I think I've jiggled test/inc/test-pop
correctly; one of its -pack uses wasn't -pack related so ne
Hi again,
More woes.
> I take this to be an MH-only file, unused by other parties. Thus if
> nothing in nmh reads them then it doesn't have to bother to create and
> maintain them any more? And so all the supporting code can also go
> pre-1.7?
The main user in creating map files is inc(1), but
Hi,
I asked:
> Does anyone know about the `map' file that is built by packf?
...
> I don't think MH uses them so they're probably leftovers to feed to
> the swine.
I suspect the last user was msh(1), removed by
1.6-branchpoint-16-ge6917522, i.e. after 1.6's release.
A `map' file is an array of `
Hi,
kre wrote:
> No, it always was in band - the 4-SOH sequence was searched for in all
> lines of the message, and SOH has always been a possible character in
> e-mail. Just even more unlikely years ago than it is now.
I have, AIX, recollections of one of the four SOH sometimes being munged
to
Hi,
I've been poking m_getfld() a bit, trying to get a firm understanding of
what all its callers demand. Thought I'd pick the list's brains.
int m_getfld(m_getfld_state_t *gstate,
char name[NAMESZ],
char *buf, int *bufsz,
FILE *iob)
On entry, *bufsz is the size of b
Hi Ken,
> > Lack of From munging?
>
> I suppose that's a reason, but it just seems like mbox has been the
> standard for approximately forever and MMDF is one of those weird
> relics like UUCP that I only hear about once in a million years.
I used to come across it on sendmail-using AIX quite a l
Hi Ken,
> > I use nmh and keep mmdf archives (produced by pack -mmdf).
>
> I have to ask ... why?
Lack of From munging?
> I think at this point MH/nmh is probably the only tool left that can
> deal with such things.
Python's mailbox in the standard library can read them. Unfortunately,
a GSoC
Hi Ken,
> >mmdelim1: \001\001\001\001\n
> > The beginning-of-message delimiter for mail drops.
>
> I say get rid of it now; that's support for MMDF, right?
Right. MMDF mail spool files are the normal (headers, blank line,
body), and instead of a "From␣" line header and blank line tail, t
Hi,
mts.conf(5) says these may be altered from their default.
mmdelim1: \001\001\001\001\n
The beginning-of-message delimiter for mail drops.
mmdelim2: \001\001\001\001\n
The end-of-message delimiter for mail drops.
This doesn't seem useful, if it ever was. If someone h
Hi David,
> > ./configure with CFLAGS including -DBUFSIZ=225.
>
> Then don't do that? :-)
Where your pioneering spirit? :-)
> I suspect that m_getfld() might be involved. I wouldn't recommend
> trying to fix it. If you want to do something, #error if BUFSIZ < 226
> or something like that?
I'
Hi Thomas,
Like Leonardo, I'm happy with rss2email(1). With the death of Aaron
Swartz, its maintainership has bounced around a little and last I looked
it had atrophied after someone converted its data store to shiny JSON
format from Python's nippy pickle, with a tedious slowdown in
performance.
Hi,
I can get git to fail test test/inc/test-eom-align if I alter NMH_BUFSIZ
from 8192 to 1024, and ./configure with CFLAGS including -DBUFSIZ=225.
The email created by inc(1) has an extra linefeed at the end. I suspect
it's the blank line that's terminating the email in mbox format.
--
Cheers,
Hi David,
> uip/fmttest -raw \
> -format '.%-7(putstrf{text}).%7(putstrf{text}).\n' foo
>
> .foo.foo.1.6-branchpoint-133-g11e2fb2d
> .foo.foo.1.6-branchpoint-134-g92128dac
> .foo.foo.1.6-branchpoint-1314-gab6e5468
>
> test/format/test-ri
Hi Tom,
Out of interest, Mailman sent the email here with
Subject: Re: [Nmh-workers] [pick -to] apparently failing for long 'To:'
header << Thanks for the fix! /No body; end of msg.
Is that because you edited the subject your side, or some program
corrupted something? The `<<' looks MH
Hi David,
> > You introduced, IIRC, NMH_BUFSIZ as min(8192, BUFSIZ).
>
> max(8192, BUFSIZ)
Yep.
> > That would seem sufficient for one logical header over multiple
> > physical lines for the moment? It could be used as the value of
> > LBSIZE, etc., to minimise diff noise as it's just a tempora
Hi David,
> Tom wrote:
> > $ pick -to mytkhcsh
> > pick: no messages match specification
>
> That's due to this hard-coded limit in picksbr.c:
>
> #define LBSIZE 1024
> #define ESIZE 1024
scan(1) has similar, but different.
/*
* Buffer size for content part of header fields.
Hi David,
> > > I noticed that the altstr = NULL; in cptrimmed(), line 197, is
> > > inside the w >=0 block. I think it should be outside.
> >
> > The else block for that condition effectively returns so the
> > un-NULL'd altstr isn't used again. (They should be swapped. :-)
>
> That's in cpstr
Hi Howard,
> Silly question. I don't see any mention of buffer cache effects being
> worked around.
No, good question...
> Are you running a scan, tossing the results, then rerunning the scan?
In effect, yes. I get the ltrace command running just as I want, LC_ALL
set, scan(1) with the right o
Hi,
I've only recently upgraded to 1.6 in the last year or so from a circa
2010 version, and nmh has felt sluggish on this Intel Atom D525. :-)
ltrace(1)'s -c option to count library calls is a simple summary of
what's happening, so I decided to compare that across a few versions.
Here's the hea
Hi David,
> Your patch looks good.
I've learnt how to only push the first few commits too. :-)
> I noticed that the altstr = NULL; in cptrimmed(), line 197, is inside
> the w >=0 block. I think it should be outside.
The else block for that condition effectively returns so the un-NULL'd
altstr
Hi David,
> > it seems quite possible to me that the wcwidth() of a `mbtowc() < 0'
> > could be -1
>
> wcwidth() should be negative only if wide_char is non-printable. The
> code checks if iswcntrl() or iswspace()
But only by the time wide_char may have been written by a second
mbtowc(). If the
Hi,
80a9e99f7078199500d2d53c8d77d1b92af06fbc added an assert(3) as part of
the -width-overflow fix for Valdis's email.
Bad news: Yesterday, I got two aborts in a row when running `scan +foo'
from git. I then viewed the source, and after that it wouldn't happen.
:-( Good news: A code dump was sq
Hi Chris,
Ken wrote:
> Should be as simple as "./configure && make && make install"; nmh has
> always used autoconf. If that doesn't work, then let us know.
There's also http://git.savannah.gnu.org/cgit/nmh.git/plain/build_nmh
that can be wget(1)'d, as described there, and run to duplicate the
c
Hi kre,
> > 2017-04-23 isn't valid input,
>
> Why? Looks like a fairly rational way to write dates to me (20170423
> might be more standard, but the extra punctuation makes it much easier
> to read).
Sorry, the context is a lexer that's only intended for Date headers, and
similar sources. I agr
Hi Ken,
Are you planning to alter ap(8), dp(8), and fmtdump(8), man pages, and
possibly command output, to warn they're deprecated before 1.7 is
released? I think the new fmttest(1) does everything they do?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
__
Hi again,
> So are all ADJUST_NUMERIC_ONLY_TZ_OFFSETS_WRT_DST's effects cancelled
> out? Setting it to zero passes all tests and suggests it can be
> deleted along with the code it wraps?
Changing ADJUST_NUMERIC_ONLY_TZ_OFFSETS_WRT_DST from 1 to 0 passes all
tests because it's tested with #ifdef
Hi,
One rabbit hole led to sbr/dtimep.l, why is lost in time. It looked odd
to me so I gave it a poke.
$ uip/fmttest -date '2017-04-23 09:16:42 +0100 Sun'
04 Sun 2023 09:16:42 +0100
Then I tried nmh 1.6-3's.
$ fmttest -date '2017-04-23 09:16:42 +0100 Sun'
04 context 2023 09:16:
Hi,
I committed 62ee157e2dd14a1aec566d0370a1275654abd143.
uip/sortm.c: Remove unused variable and dlocaltimenow() call.
read_hdrs() has a auto `struct tws tb'. It's only use is as the
destination for dlocaltimenow()'s result. Remove the variable. Also
remove the dlocaltimenow(
Hi David,
> > I wonder if there's anything listed as deprecated in NEWS for 1.6
> > and earlier that remains to be axed for 1.7. A few spot checks
> > suggests lots of them were done just after 1.6's release.
>
> Right, Ken and/or I tried to do that. I don't think that any other
> deprecated fea
Hi David,
> I'd prefer to wait for the release after 1.7.
There's always one! :-)
> I use mhn to get different behaviour from mhshow without a separate
> profile. I could adapt to the loss, of course, but others might be
> still using it, too. I think it should be removed at the beginning of
Hi Ken,
> Sigh. If we could get Valdis to crank out a new exmh release that had
> switched to calling mhbuild instead of mhn, I'd say yes. Valdis?
What if we threatened to release the Lyndon?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Hi David,
> Agreed. whatnowsbr.c has corresponding relics.
77bd4fc7347961a3436393f4de70b0acca475ecc gets rid of both.
I think that's all the deprecated stuff that can go because it was
stated in 1.6 now deleted ready for 1.7. Except mhn, which has been
stated as deprecated in its documentation
Hi David,
> > Talking of 1.7, I think there are some things that were marked
> > deprecated in 1.6 that could get the chop before 1.7...
>
> Such as?
Well, that was just based on a little search the other day when I was
looking for example of how to deprecate something. One is
$ git blame -
Hi Ken,
> I'm an outlier, in that I still prefer using hard-tabs that are
> displayed to 8-space tabs stops.
...then four spaces for a half-tab. `:se ts=8 sw=4' in vi.
> However, if we want to officially go forward and say "no ^I at all in
> the source code", then I'm fine with that.
OK, I'll
Hi,
nmh's source has lines where a tab immediately follows a space that
isn't in an eighth column, i.e. the space isn't having an effect.
This inconsistency is a bit of a pain when it comes to regexps to search
and manipulate the source whilst maintaining indentation.
I'm happy to make all those l
Hi Bob,
> The example shows the correct order in defining sgroup and fred,
> though the explanation below the example is incorrect (and is
> identical to the latest version in Savannah).
Thanks for the research. I've pushed
d8c4005c956790595943210509eb8daace570470 that fixes the example's order
Hi,
Lyndon wrote:
> > Larry Hynes wrote:
> > Do I care if the date on the man page changes, so long as this gets
> > corrected? No.
>
> That's fine. Those of us lamenting the loss of consistent, concise,
> and relevant manpages do.
Hear, hear. I've now committed all of Larry's patch emails to
Hi Bob,
I agree the man page example doesn't seem to match the page's
definition, but I think the example and the explanation that follows is
wrong.
$ sed 4q ~/mail/aliases
x1: x2
x2: x...@example.com
x3: x...@example.com
x4: x3
$
$ ali | grep '^x[1-4]:'
x1: x...@e
Hi Ken,
> Ah, this IS documented, though! From mh-alias(5):
>
> UNIX file names. UNIX-group is a group name or number from the
> system's group database.
Yes, sorry, I did see that but then it got flushed out the cache as I
tried to track the code. :-)
> The only way you could get tha
Hi Ken,
> I think any two group-base aliases would have triggered it.
That probably depends on the implementation of getgrnam(3) and
getgrgid(3). Perhaps some didn't rely on gr_mem not changing. The
current nmh code doesn't keep using the results of one call whilst using
the results of the prev
Hi Norm,
> man mh-alias says:
>
> Alias file contents are case-insensitive, with the exception of
> filesystem path names.
Aren't the only thing that are case-insensitive the alias names it
defines, i.e. `alias' in the grammar? `alias-file' is a Unix file name.
As is `file'. `UNIX-group' is
Hi Johan,
> > > This alias file is enough to cause this:
> > >
> > > n1: =?iso-8859-1?Q?gnillen?=
> > > n2: =?iso-8859-1?Q?gnillen?=
> >
> > According to mh-alias(5), that's looking up a Unix group called
> > `?iso...'. Though I agree post(8) shouldn't SEGV.
>
> Hah! Didn't know that (should re
Hi Johan,
> This alias file is enough to cause this:
>
> n1: =?iso-8859-1?Q?gnillen?=
> n2: =?iso-8859-1?Q?gnillen?=
According to mh-alias(5), that's looking up a Unix group called
`?iso...'. Though I agree post(8) shouldn't SEGV.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
Hi Ken,
> next(1)/prev(1) would NOT, because it would need to know the next
> message number.
One thought, next(1) could speculatively stat(2) `43' and fallback to
readdir(3) if it's not there. It could do N stat()s, e.g. three, before
giving up.
--
Cheers, Ralph.
https://plus.google.com/+Ralp
701 - 800 of 1614 matches
Mail list logo
