Hi Jon,
> Things always get weird as one's installed distribution gets crusty.
> My Fedora Core 27 installation
What is Fedora Core 27? :-) Fedora 26 is the latest version, so 27
might be Fedora Devel, but then you said it's crusty as if the 27 is a
typo for something older, but they stopped ca
Hi Paul,
> by the way, this is how i move my wife's inbox into annual
> subdirectories now. when we used MH, it was simpler by far.
>
> http://www.redbarn.org/node/29
Interesting. I've done that on other's systems using the file's mtime
in the past, but perhaps I should be using the filename. I
Hi David,
> > > These arg parsing error messages are a bit odd:
> > >
> > > $ show -pref
> > > show: missing argument to -pref
> > > $ show -pref text/plain
> > > mhl: -pref unknown
> >
> > Seems to be 85bc89701 from 2016-01.
>
> I wouldn't blame that commit. Without it:
>
> $
Hi Norman,
> You are right but:
>
> show -no ambig
> mhshow: -no ambiguous. It matches
> -nocheck
> -noverbose
> -noconcat
> -notextonly
> -noinlineonly
> -noheader
Here's the `-no' things in mhshow's source.
$ git blame uip/mhshow.c | grep 'X("no'
de4636bb6 (Ken Hornstein
Hi Norman,
> show -nop also works for me, though apparently it doesn't for some
> people.
show is passing `-nop' onto another program because it doesn't recognise
it given it doesn't have `-noprefer'. For me, that program is mhl(1),
for you it's probably mhshow(1), because our configurations dif
Hi Norman,
> mhshow -nopr 170
> mhshow: -nopr unknown
Well that's odd because mhshow does know -noprefer.
$ mhshow -noprefer . >/dev/null
$ mhshow -noprefe . >/dev/null
$ mhshow -nopref . >/dev/null
$ mhshow -nopre . >/dev/null
$ mhshow -nopr . >/dev/null
$ mhshow -nop .
Hi David,
> These arg parsing error messages are a bit odd:
>
> $ show -pref
> show: missing argument to -pref
> $ show -pref text/plain
> mhl: -pref unknown
Seems to be 85bc89701 from 2016-01. It's not just -pref.
$ show -part
show: missing argument to -part
$ show
Hi David,
> > Oh, I guess that's because `scan -v' does not modify `context',
> > e.g.:
>
> Right. Neither does -help.
>
> Ken, would it be a bad idea to call context_save() in
> nmh_version_changed() if the Version context is replaced?
That's probably the same as asking if no code fiddles with
Hi David,
> > I thought the test should change to handle no iconv, iconv, and
> > ice-age iconv
>
> As in, now it doesn't handle the no-iconv case? I went that route in
> anticipation of removing support for that, with the benefit of not
> having to make the test more complicated.
Right, there's
Hi Ken,
> David wrote:
> > restores the old behavior of the test in that respect.
I thought the test should change to handle no iconv, iconv, and ice-age
iconv, but...
> Should I just spin another 1.7.1 release candidate?
...yes, please. 1.8 can revisit what tests are doing something useful
an
Hi Thomas,
> I usually send emails through my mail provider's SMTP server, but I
> sometimes send mail to my local computer. How could I specify that the
> manner of sending should depend on the recipient?
Is `sendfrom' in send(1) any help? It's sender, not recipient, but
perhaps you can alter t
Hi Ken,
> The web page that Paul posted in his reply to you has a very good
> description of how Dovecot uses Maildir; some metadata stored in the
> filename are the file's size (to avoid a stat() call)
It was probably Pike that said a cache is bugs waiting to happen. :-)
Maildir seems ill-suit
Hi,
Paul V. wrote:
> it was dovecot not cyrus-- my apologies again to all for that confusion.
> https://wiki2.dovecot.org/MailboxFormat/Maildir
Some interesting bits from there.
`Note that messages must not be modified once they've been delivered.
IMAP (and Dovecot) requires that messages are im
Hi Paul,
> note: because valgrind finds hundreds of thousands of runtime
> anomalies in even a trivial libcurl application, and because the
> suppression file syntax for valgrind doesn't permit me to say "if it
> comes from libcurl just ignore it"
Are you aware of `...' to mean `zero or more fram
Hi Paul,
> [bert] wrote back as follows, and also gave permission to be quoted
> here:
That's good of him. It was very interesting.
But getting to the point where we'd have nmh in C++ to that style,
getting those benefits, is more than s/gcc/g++/ so we'd then be
embarking on the march to `good'
Hi Ken,
> > http://lists.nongnu.org/archive/html/nmh-workers/2017-09/msg00014.html
...
> Secondly ... that message is kind of dense.
I think you mean `high in signal'. It was partially to try and document
the current state of play.
> ...the way certain sequences make things go backwards is kind
Hi Ken,
> So it would be helpful if we supported Maildir as a mailbox format,
> because then we could use nmh directly on the backend store without
> going through IMAP
Could an optional level of indirection help; mail/inbox/42 having
content that states it's not the email, but here's details th
Hi Michael,
> I believe that GO will replace C++, Java and Python in many "system
> admin" and bigger systems like GNOME and the like. C# has already
> replaced on windows for UI stuff, and GO might make inroads among
> developers that didn't like C#.
You've ignored the existing inroads Go has m
Hi,
Paul V. wrote:
> i get it. however, in cyrus imap, all my folders are in Maildir
> format, and the performance and agility benefits of having so much
> metadata stored in the file name, are unavoidably wonderful.
Can someone with Cyrus IMAP give examples of the file-name metadata.
--
Cheers
Hi Ken,
> http://lists.nongnu.org/archive/html/nmh-workers/2018-02/msg00017.html
>
> You said you had a fix to a broken test ... was that pushed to master?
> If that was commit d4814561e
It was.
> then that is a BIT of a problem, since that commit broke test-charset
> on MacOS X
...
> MacOS X
Hi Paul,
> > What specific mime related features do you have in mind?
>
> i'd like to provide the MH view via FUSE rather than files-on-disk.
> rather than using command line utilities to extract a mime part, i
> want to access it by ~/Mail/inbox/135/part1.exe or whatever.
Right, like http://man.
Hi Michael,
> I don't know if rewriting MH in go or rust would be better. I am
> half-way through each book (one in each bathroom...).
No, not Rust. Eric has summed up its problems quite a few times and
mentioned it in those three `Go's replacing C' posts I gave. It lacks
Go's pedigree, self-r
Hi David,
> > The aim would be for the existing users to have a code base that
> > allowed more rapid, stable development of new features, deprecating
> > old warts, and improving consistency.
>
> +1
>
> I'd rather see more of all the above, even if it means giving up some
> current capabilities.
Hi Ken,
> Alright, I pushed a change to master and 1.7-release that eliminates
> that call to free(). Ralph, does that solve your problem?
With 1.7-branchpoint-495-g19c69cf3, valgrind 1:3.13.0-1ubuntu3 on one
machine moans.
Source and destination overlap in memcpy_chk(0x1ffefeedc0, 0x1ffefee
Hi Paul,
> that's a knee-jerk reaction.
Very true. A regurgitation of a long-held view.
> bert hubert at powerdns found a subset he can live with, and ways to
> enforce it. basically there are no operators overloaded and no
> subclassing.
I've struggled to find something on this, e.g. a guide
Hi Paul,
> if we wanted a better code base for the same graying user population,
> wouldn't we do a gradual rewrite in some well-disciplined subset of
> C++ instead?
No, everyone has a difference subset so we won't agree. There's nothing
to enforce it automatically. No subset of C++ is nice. A
Hi Paul,
> i just don't know whether MH can attract new users through a rewrite.
That wouldn't be the aim. The aim would be for the existing users to
have a code base that allowed more rapid, stable development of new
features, deprecating old warts, and improving consistency.
For example, whil
Hi,
Do you run nmh on an OS and architecture that isn't in this list?
If so, what version of MH/nmh, OS, and architecture?
androidarm
darwin 386 amd64 arm arm64
dragonfly amd64
freebsd386 amd64 arm
linux 386 amd64 arm arm64 ppc64{,le
[I wrote this ages ago when catching up on unread list email and never
quite finished it. But if it doesn't leave +drafts now then... It's a
distraction from the current 1.7.x issue, but the list archive might
find it useful.]
Hi David,
> If you want to try the attached patch to mhshowsbr.c, it
Hi,
David wrote:
> Even this?
>
> free (comp->c_text);
> comp->c_text = str = strdup (mn->m_text);
I haven't been following closely, but if the problem is
if (comp->c_mn != &fmt_mnull)
mnfree (comp->c_mn);
no longer holds true because it also shouldn't be freed on other spec
Hi Bakul,
> And the programs I tried worked fine. Running best scan time for 200K
> messages, scan+gc takes 13.5 seconds while the regular scan 7.4
> seconds. Looking top, the GC version takes 27MB while the nonGC
> version 22MB.
Would the nonGC be before Ken's recent fix of the big memory leak i
Hi Bakul,
> Refactoring, code cleanup and fixing memory leaks are worthy goals.
> But that can take lots of time and volunteers.
True, but GC would just be papering over some of those cracks. :-)
Besides, without it the source will continue to suffer bit rot and
whatever the UI equivalent is whe
11 00:00:01 +0100
To: ra...@inputplus.co.uk
From: ra...@inputplus.co.uk
==> 5781 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
To: not-...@example.com, ra...@inputplus.co.uk
From: ra...@inputplus.co.uk (Ralph Corderoy)
==> 5782 <==
Date: Sun, 31 Jul 2011 00:00:01 +0100
Hi Paul,
> note that coverity is free for open source projects. it tends to find
> more and smaller things than are obviously fatal, but it does
> prioritize them. my friends in the freebsd project say that they run
> it once a week and chip away at the worst findings. MH could do the
> same.
Tha
Hi Ken,
> I ran it against 500k messages on the Enron corpus ... and of course
> YOU have the one email that breaks it. Sigh.
:-) Here's the first complaint.
$ uip/scan -version
scan -- nmh-1.7+dev 1.7-branchpoint-490-g42db3a2c built 2018-02-10 17:21:09
+ on orac
$ valgrind ui
Hi Ken,
> - Messages in IMAP are immutable, so if you overwrite ~/mail/inbox/42,
> in theory you should get a new UID for that message. But maybe our
> "internal" IMAP implementation wouldn't care.
So if the IMAP server noticed ~/mail/inbox/42 was different and started
calling it 314, 42 having
Hi Ken,
> It turns out this was introduced post-1.6, so I don't think many
> people have encountered it yet. Anyway, I just committed a fix (and I
> cherry- picked it to the 1.7 branch). If you could check to make sure
> that the fix works for you, I'd appreciate it.
There's good news, and bad n
Hi Bakul,
> I see there are mts/libmta.a and sbr/libmh.a libraries. Corresponding
> .c files add up to about 29K lines. uip/*.c is another 44K lines.
> That is a lot of code for manual analysis.
A lot of it is duplicate dribble pasted over the decades and it could
probably be halved in size. Al
Hi David,
> Question: I had to disable reset_comptable in the calls to
> fmt_compile() and fmt_free(), else valgrind noticed writes of free'd
> memory. Should it be enabled in the final call for mfmt?
Separate from whether it's the right thing to do, rather than know it's
the final call, I see
Hi again,
> $ for n in 1 10 100 1000 1; do
> > \time -f %M uip/scan -forma _ last:$n >/dev/null
> > done
> 2728
> 3152
> 4520
> 21712
> 150576
> $
It could be `compbuffers' guarded by
/* first-time only initialization, which will always happen the
Hi David,
> I think that we should call 1.7.1 done.
+1
There's many bugs in 1.7.1, just as with all previous versions, I just
happened to mention this one. :-)
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hi Ken,
> > I've been wondering if a long-lived MH server would be helpful.
> > `scan +inbox last:42' would connect to it, learn the message numbers
> > in inbox, and ask for the fields it wants for the format string for
> > the last 42. The server would likely have this information to hand,
> >
Hi Ken,
> Does this happen with any format string, or just a particular one?
Seems to be any.
$ for n in 1 10 100 1000 1; do
> \time -f %M uip/scan -forma _ last:$n >/dev/null
> done
2728
3152
4520
21712
150576
$
> If it's not hard to fix, would make
Hi Ken,
> one problem we run into is that reading a large mailbox just takes a
> while even if the directory is cached in memory, because of the small
> buffer size used by the readdir() call.
/me nods.
I've been wondering if a long-lived MH server would be helpful. `scan
+inbox last:42' would
Hi David,
> Ken wrote:
> > It took us a few decades to finally make our libraries be agnostic
> > to the stdio implementation; hitching our wagon to a third-party GC
> > library just seems like we'd be asking for a similar set of
> > headaches all over again.
>
> Your entire argument was very well
Paul wrote:
> unless we reinvent in a way that's an impedance match for both mime and
> imap, the likelihood of ever growing our user population is 0.000%.
I'd like DKIM support, e.g. pick(1) and mh-format(5) to be aware of
whether a signature is valid, and other attributes about it.
I think Ken
Hi Bakul,
> trunccpy() is strndup().
Yes, allowing for passing sizeof-1 instead. And the extra malloc and
free, or piece of work for the GC.
> Go-1.0 used a conservative GC and it was fast enough.
Yes, but AIUI Go's GC was built into the language's runtime and could
use knowledge produced by t
Hi Ken,
> > Yes, I like asprintf(), but it's not POSIX. snprintf(NULL, 0, fmt,
> > ...) is POSIX and returns the strlen() of what would have been
> > written, allowing a second call to do the work, again, for real this
> > time.
>
> A quick glance suggests to me that even while asprintf() is not
Hi Ken,
> I'm fine with all of the changes you mentioned, Ralph, with one
> caveat... can we document them all in a header file or the source
> code so we know which ones we should use under which circumstances?
Absolutely. I'd group the alternatives together, they'd each have their
own descrip
Hi Paul,
> > As for the related snprintf(), etc., well, at least destination is
> > NUL terminated, even if the truncation could cause data loss. They
> > too need looking at and replacing in time.
>
> uvsnprintf() could be implemented in terms of asprintf(), strlen(),
> strcpy(), and free().
Ye
Hi,
Valdis wrote:
> I'd be quite surprised if we don't have at least one off-by-one error
> in there.
Separate from those errors, a lot of the code doesn't care if the char[]
ends up unterminated and continue to use the result assuming it is.
IOW, it assumes the char[] is `big enough', and at 8 K
Hi Ken,
> > By all means make ndbm.h optional, it's pretty useless for a
> > conforming program, but at the moment it doesn't seem to be causing
> > ./configure trouble to porters.
>
> Well, look through the archives ... you'll find a number of people for
> whom it causes problems
Yes, some of th
Hi David,
> Until commit 523641d22, that test did a simple check of actual and
> expected, regardless of iconv support. Maybe it should have stayed
> that way?
Yes, that's the conclusion I've come to.
commit a05f0ee61f14e6d56d065c1e7c050714a687f793
decode_rfc2047(): Stop unused-var
Hi Ken,
> Alright, so, question time ... do we want to fix the broken test for
> 1.7.1?
I have a fix. Will push to master soon.
> We've already decided, I believe, that iconv will be manitory going
> forward;
Don't think David commented?
> the only problem (AFAIK) is that the tests for when w
Hi Ken,
> > True, but `it's POSIX' and that was used for iconv to make it
> > mandatory. And optional means the code and the tests have to be
> > that bit more complex.
>
> If this was used in more than one tiny location, I'd find this
> compelling. But it's not quite the same as our use of icon
Hi Ken,
> I think part of this was because we always made it a requirement so we
> tried to find it whereever it was.
And systems were a lot more varied a decade or more ago. Even Cygwin
may have fallen into line by now. :-)
> If we just made it optional then the few people who cared would be
Hi,
> > > CONFIGURE_ENV= ac_cv_header_db_h=no \
>
> I think it was for an older version of nmh's configure script.
Todd later pointed out privately that 2005's 0cd75fec removed the need
for the above.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lis
Hi Ken,
> If there is ONE bit of code that has caused us a huge amount of
> consternation relative to it's use in nmh, it is the db/dbm code. It
> is ONLY used by slocal to suppress messages with the same Message-Id.
I had a look. It looks up Message-ID, if found then it verbosely shows
its val
Hi Ken,
> > (I would search nmh-workers archive, but the search is broken; I'll
> > ping them.)
>
> Hm, I just tried it out and it worked fine for me.
I remembered before pinging them that it's a known bug with Namazu.
Starting at http://lists.nongnu.org/archive/html/nmh-workers/ and
searching f
Hi Todd,
> CONFIGURE_ENV= ac_cv_header_db_h=no \
Out of interest, is that steering configure to not probe for db.h and
move on to another? Anything nmh should be doing better to avoid the
need for this and work better elsewhere?
(I would search nmh-workers archive, but the search is br
Hi Ken,
> I think if you use CPPFLAGS (and probably LDFLAGS) to point to the
> headers and the library location, the right things should happen.
Right, and I checked `./configure --help':
Some influential environment variables:
...
CPPFLAGS(Objective) C/C++ preprocessor flags,
Hi Ken,
> > You're thinking those without it, e.g. Andy, could easily get iconv
> > with a package install?
>
> Yeah ... I am kind of surprised OpenBSD doesn't ship with iconv
If I'm looking in the right place,
http://openports.se/converters/libiconv suggests it's no longer a
package but a LIB_DE
Hi Ken,
> > > No, it does not attempt the printf because ICONV_ENABLED=0
> >
> > OK, so that's it: the test doesn't handle that case properly.
>
> This begs a larger question ... should we just specify iconv as a
> requirement for the next release?
You're thinking those without it, e.g. Andy, c
Hi Ken,
> Bakul wrote:
> > May be the current -help option of most commands with some post
> > processing is good enough?
>
> I have thought about that ... but AFAIK we have never committed that
> the "help" output be stable. Really, I think a few extra switches
> would make it a lot easier AND w
Hi Andy,
To recap, the previous mailing-list discussion was around
http://lists.nongnu.org/archive/html/nmh-workers/2018-01/msg00130.html
and
http://lists.nongnu.org/archive/html/nmh-workers/2018-01/msg00126.html
The former's suggestion, with correction, got committed as 695ed941.
> if [ $iconv_e
Hi Paul,
I've made a note of your and Ken's suggestions.
> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
Having every program, clang, nmh, vim, etc., implement --autocomplete
seems a poor solution. The bash script they provide has knowledge of
some of clang's options so
Hi Ken,
> But what if you want to put an IP address? Can't use a ':'
> because that conflicts with IPv6. You can then try something like:
>
> server: [ff80::1]:25
>
> or:
>
> server: ff80:1/25
I don't programmed with IPv6 so did some reading. For future reference,
https://tools.ie
Hi David,
> Agreed, this needs a good cleaning.
I'd like to see a lot of the noddy `-foo sets bool foo, -nofoo clears
it'-case processing in a switch disappear into a central, new,
option-processing routine.
> > $ post '-sasl -user' -foobar
> > seen -sasl
> > post: -foobar unknown
>
Hi David,
> I just committed that fix to master, please review.
Looking at 28ebf6bb..ff7b97ca, I was puzzled by the macros to make
switches disappear. This doesn't affect your patch; it's a general
nmh-wide issue.
#ifndef OAUTH_SUPPORT
# define OAUTHminc(a) (a)
#else /* OAUTH_SUP
I wrote:
> +echo 'iconv complaint not found'
> +sed l "$actual"
> +failed=1
That should be «sed -n l "$actual"».
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hi Andy,
> So it's entering this:
>
> if [ $iconv_elides_question_marks -eq 1 ]; then
> check "$expected" "$actual"
> else
> grep "Can't convert .*us-ascii to UTF-8" "$actual" >/dev/null ||
> failed=1
> fi
convert_charset() in uip/mhshowsbr.c is expected to call
iconv_open("UTF-8", "?u
Hi David,
> run mhfixmsg under ltrace or something similar to see exactly what
> file it's trying to open.
strace -fe open,openat mhfixmsg
> Yes, via mhfixmsg-format-text/html.
It seems mhfixmsg is quite close to being able to have me run it by
another argv[0] to provide a separate set of .
Hi,
David wrote:
> [Ken] also noted that he's had problems with insertion of '!' in long
> lines of HTML.
Sendmail has been splitting a long line that violates the RFCs at that
point by inserting a `!'. It happens without caring what the line's
content type or encoding is, or if it's MIME.
One
Hi Andy,
> Thus said
Spake? :-)
> > Can't get the warning here with gcc 7.2.1 20171224 and `-std=c99
> > -pedantic -pedantic-errors -Wall -Wextra -Wformat=2
> > -Wno-format-nonliteral'.
It occurred to me that an -O option might make it do more analysis and
trigger the warning so I tried -O{0..
Hi M,
> even pcc can handle C99 these days! :-)
That's nice. And Arch has it in its AUR repository. I've added it to
the list of build variations to try and set up someday.
> I've seen only one problem when using nmh compiled with pcc, and I
> think it's legitimately a bug in nmh rather than a
Hi David,
> Because all of the tests are Bourne shell scripts, this can be used to
> help isolate where a test goes awry:
>
> sh -x test/ali/test-ali
I had a failure recently that didn't give much clue. Turns out the
command run by run_prog() was SEGVing, `set -e' was in force, stderr was
be
Hi Andy,
> first named test failure: replacement character in parameter value
> FAIL: test/mhshow/test-charset
The vital lines of interest are in the lead up to that. Should be
something starting with a context diff.
*** /tmp/nmh/test/testdir/9794.expected Tue Jan 23 11:09:32 2018
-
Hi Andy,
> uip/fmttest.c: In function 'main':
> uip/fmttest.c:123: warning: 'outputsize' may be used uninitialized in this
> function
>
> Looks like this one will require even more investigation to
> discover whether the warning is just a red herring or not.
It is. Summarising the flow:
Hi Andy,
> This may be a known issue (or not an issue at all):
>
> uip/post.c: In function 'putadr':
> uip/post.c:1239: warning: 'shlen' may be used uninitialized in this function
>
> From a cursory look, it could be uninitialized if the savehdr
> parameter is NULL
Yes, but shlen is only written
Hi Steven,
> ...so when a message clearly contains
>
>Content-Transfer-Encoding: base64
>
> shouldn't that mean we don't need to test the decoded content to see
> if it's binary or not? You just said in your previous message that
> there's no line length restriction in the content after decod
Hi Andy,
> first named test failure: replacement character in parameter value
> FAIL: test/mhshow/test-charset
Interesting.
> Maybe the environment variable to not clean up corrupted the test
> environment and I need some way to clean it up? I can rerun ``make
> check'' multiple times a
Hi Paul and Bakul,
> > Paul wrote:
> > > Ralph Corderoy (7):
> > > fmttest.c: Avoid `++' with bools, silencing compiler warnings.
> >
> > i hate that perfectly reasonable, traditional idioms have to be
> > avoided for this reason.
>
> No
Hi Steven,
> David wrote:
> > That's not right, it should be:
> >
> > while ((pp = strchr (pp, ''')) && buflen > 3) {
>
> That's what I thought based on your patch.
That's not what David wrote. :-)
Rewinding time, he sent a patch to the list. (BTW, David, your patches
have had zero lines
Hi Steven,
> > > (Currently I'm doing this by creating a second profile file
> > > with a different value for mhshow-show-text/html, and
> > > selecting that by changing the value of $MH; I consider this
> > > to be ugly, but it works, and it's the only thing I could
> > >
Hi David,
> I'm not sure there's a good way to fix this. Maybe this?
>
>'SEAO - Résultats d'"'"'ouverture (002).pdf'
I realise there's a lot more conversation that occurred on this, but the
idiom to write a ' within a '-quoted string is to exit it, escape a
quote with backslash, and then re-
Hi Paul,
> > so `-nopri' would be needed to be unambiguous if it were to become
> > the common option across nmh commands. That's tedious, and doesn't
> > obviously say `be quiet', ending in an `eye' sound, not an `ee', so
> > the `...nt' would be added anyway.
>
> you kind of lost me in that las
Hi Paul,
> Valdis wrote:
> > Ralph wrote:
> > > That quickly bores. -noprint doesn't seem a good fit for a
> > > general `please be quiet'. If folder's regaining that
> > > functionality then perhaps it's the opportunity to use a more
> > > general, positive rather than negative, option? Especi
Hi Paul,
> David wrote:
> > Yeah, looks like it's always (at least since 1989/06/26) been that
> > way.
`git grep noprint' suggests 6.8 removed it from the documentation
because it didn't work.
> but that still prints the folder name, doesn't it? i think -noprint
> might be totally silent. (of
Hi Ken,
> > Makefile.am currently has:
> >
> > nmhetcdir = @sysconfdir@/nmh
> > nmhlibexecdir = @libexecdir@/nmh
BTW, Makefile here has
pkgdatadir = $(datadir)/nmh
pkgincludedir = $(includedir)/nmh
pkglibdir = $(libdir)/nmh
pkglibexecdir = $(libexecdir)/nmh
so maybe our
Hi Ken,
> Yes, it does say at the end of that section that it "might be useful"
> to group a large number of files into a subdirectory. I would suggest
> that means, "it's up to you".
You'd still prefer files directly in /etc? They've no consistency on
their naming, nothing to tie them into nmh
Hi Ken,
I'm catching up on the list. It's a bit weird. Disagreement and I'm
hardly involved. :-)
> >If your program installs a large number of files into one of the
> >standard user-specified directories, it might be useful to group
> >them into a subdirectory particular to that pr
Hi Ken,
I'm jumping in at the end because I haven't been able to keep up with
recent emails...
> Like I said, I only have a beef with sysconfdir; I'm fine with a
> hardcoded appending for libexecdir.
I took all files that matched /etc/* here and looked up their package.
These are the packages th
Reversal of commit 1353a95720e4049e5f8357cd009b76c0450ec39f.
Makefile.am | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
commit 0e593b90e45687680b8ea9eb6c7643b44abde0fb
Author: Ralph Corderoy
Date: Mon Nov 27 15:20:44 2017 +
test-mhfixmsg: pwd(1
Hi Ken,
> I think we should do a 1.7.1 release, since there are more bugs in 1.7
> than I would prefer.
+1
> So, candidates for 1.7.1 fixes?
Does this generate the list I should peruse? Lines starting `=' are
already in both.
git log --oneline --cherry 1.7-release...master
If so, I'll de
Hi David,
> %(kilo) and %(kibi) can produce partial output
Yes.
$ for w in {1..8}; do
> fmttest -raw -forma '%(void(compval{text}))%(kibi{num})|' \
> -outsize $w 123456
> done
1
12
120
120.
120.6
120.6K
120.6Ki
120.6Ki|
$
And faulty it loo
Hi David,
> Ralph wrote:
> > Do not expect the user to include the subdirectory name in the
> > value of any of the variables listed above. The idea of having
> > a uniform set of variable names for installation directories is
> > to enable the user to specify the exact same value
Hi David,
> The change was intentional, IIRC. Better to truncate than show part
> of a number.
Right, back in 2014, I think.
> The parentheses in your format would reveal it, but without them, the
> output could be misleading with truncation.
This reproduces Tom's experience AIUI.
$ fmtte
Hi Andy,
> To get these to run I would probably have to include additional
> software from ports or perhaps some different command-line options to
> configure. I see that OpenBSD's port Makefile for nmh runs:
>
> CONFIGURE_ARGS= --libdir='$${exec_prefix}/libexec' \
>
Hi Valdis,
> And I was wondering what use case you had where you were searching for
> something where having the : was a problem.
Ah, well, say a subject starting `foo'.
Given the template is `^%s[ \t]*:.*%s' the simple `pick -sub ^foo'
fails because `^subject[ \t]*:.*^foo' has two `^'.
«pick -
Hi Valdis,
> > So for any of the List-* headers, regardless of whether anything is
> > after the colon, it's
> >
> > pick --'list-[^:][^:]*' '$'
>
> Are there any list headers that won't work for? They're all of the
> form 'name: value'.
>
> Or were you wanting to go introspecting in the body
501 - 600 of 1614 matches
Mail list logo
