In message <20120424214609.68b674c...@db.pthbb.org>, Jerrad Pierce writes:
>>Maybe we should simply reserve # as a profile component and document "#:"
>>as the .mh_profile comment character(s) rather than leave it as a puzzle.
>Makes sense to me. If documenting, point out that you cannot have blank
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
>Yes, that seems sensible to me for a feature that is (I assume) rarely used
>on this platform.
Anthony,
Could you try out the following patch? If it works for you, then I'll put
it in the next release candidate.
--Ken
diff --git a/configure.ac b/configure.ac
index af186fe..26b2606 100644
--- a
Norm wrote:
> Is there a way that scripts can use locking compatibly
> with the locking used by the local nmh installation. If
> not there should be. If so, is it documented, if not it
> should be.
Not currently. It wouldn't be hard to add utilities to
help. But I'd rather invest effort at a h
>Is there a way that scripts can use locking compatibly with the locking
>used by the local nmh installation. If not there should be. If so, is
>it documented, if not it should be.
Locking in nmh is a bit of a mess; there's conflation between "locking
the mail spool" (which a script shouldn't ca
GRIPE:
>From time immemorial, in the pick man page, the definitions of -after and
-before have been at best ambiguous and at worst wrong.
Here is my stab at a correct definition:
The only messages considered will be those for which the relevant date
field exists, has a valid format, an
On Wed, 25 Apr 2012 08:55:00 -0700, n...@dad.org said:
> The only messages considered will be those for which the relevant date
> field exists, has a valid format, and defines a date that is
> chronologically strictly after {before} the date specified.
>
> This assumes that the fiel
Norm, I had no idea you had so many things backed up :-)
> The only messages considered will be those for which the relevant date
> field exists, has a valid format, and defines a date that is
> chronologically strictly after {before} the date specified.
I'm looking at the man page ..
On 2012-04-25, at 1:48 AM, Oliver Kiddle wrote:
> The stuff in /usr/xpg4/bin would be POSIX compliant but frankly, it is
> easier to adjust scripts to work with Solaris' /bin/sh (as David has now
> done) than to have it dig around trying to find the POSIX stuff.
It's more than just sh, though.
>Those would rock. Extending it to "-before 7daysago" or "-after 1yearago" and
>similar would be even better (I'm often trying to find a message that was
>between 6 months and a year ago, or some such)
Today you can do:
pick -before -180 -and -after -365
if you want to pick all mess
Hi Norman,
> Particularly, for use in connection with sortm, there ought to be a
> straightforward way of selecting precisely those messages for which a
> validly formated, relevant date field exists and has a valid format,
> or if you prefer those not having a validly formatted, relevant date
> f
>$ p -before '01 Jan 1960'
>pick: unable to parse date field in message 6608, matching...
>6077 hits
>$
>
>Again, it matched, but why did every other email get treated as being so
>old?
Underflow on time_t? I'd have to look at how dparsetime() worked, but
I suspect since that's b
Hi Ken,
Ken Hornstein writes:
>>Yes, that seems sensible to me for a feature that is (I assume) rarely used
>>on this platform.
>
>Anthony,
>
>Could you try out the following patch? If it works for you, then I'll put
>it in the next release candidate.
Tested, it works here. Thanks.
--
Anthony J
On Wed, 25 Apr 2012 11:28:05 -0500, Ken Hornstein said:
> Today you can do:
>
> pick -before -180 -and -after -365
"D'Oh!" -- H. Simpson.
Thanks for shaking that fact loose from some overly stubborn neurons. :)
pgpsvqZEQDFnO.pgp
Description: PGP signature
>>Could you try out the following patch? If it works for you, then I'll put
>>it in the next release candidate.
>
>Tested, it works here. Thanks.
Great! That change has been pushed to master and 1.5-release; it will be
in the next release candidate.
--Ken
__
Ken Hornstein writes:
>>Makes sense to me. If documenting, point out that you cannot have blank lines,
>>hence my use of "#:#" To separate blocks, although if someone were so inclined
>>they could also do "#:{" ... "#:}" :-P
>
> Done, and done.
I wouldn't document a separator as #:#. I mean, doe
>I wouldn't document a separator as #:#. I mean, does the sh man page say
I wonder if allowing empty values is something new? I suspect there must
have been a reason I put that there, but then again I started out with MH 6.8
I never bothered to go back and check if I could save those odd bytes :-P
17 matches
Mail list logo
