> Sure, mutt(1) for one when you `bounce'.
Heirloom mail for another; it has `resend' and `Resend' commands; the
latter adds no headers.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-
Hi,
Paul Fox wrote:
> i'm not convinced that introducing a directory level might not be a
> good idea: i.e., a message might have the message file itself ("53")
> and a directory which mh would currently ignore ("53.mime"). the
> directory could then contain lots of stuff that would clutter the
Hi,
Lyndon Nerenberg wrote:
> > "Host part" is pseudo, it's after the @ and can include most ASCII
> > printable characters.
>
> Just read, say, 64 bytes from /dev/random and base64 encode it.
Would /dev/urandom suffice? Entropy can be in short supply in some
environments, e.g. VMs, and given i
Hi Jon
> ra...@hep.wisc.edu writes:
> > and just sent a PDF with the msg body in plain text via...
...
> > I expected, would have liked to have sent, is the msg body as plain
> > text.
> >
> > What I actually received was the msg body encoded as
> > application/octet-stream in base64.
>
> What's
Hi Paul,
> ra...@hep.wisc.edu wrote:
> > "-clobber auto" please!?
> > incremented file names
> > like Firefox download does
> > "fu.gif" -> fu.gif fu(1).gif etc
>
> oh, nice. that would be much better than the wget behavior:
> fu.tar
> fu.tar.1
> fu.tar.2
But can Firefox only do
Hi rader,
> I'm mostly interested in answering the question "which folder did the
> recent msg FROM so-and-so@somewhere go into?"
I haven't been following the thread, having not used procmail in years,
but would this do? (Untried.)
for f in `folders -fast`; do
pick -seq lp -from foo
Hi Norm,
> Of historical interest:
>
> Whatnow now has features not available to shell users. This
> represents, the perhaps inevitable, denouement of an argument I lost
> decades ago. I believed then, and believe now, that the whatnow
> feature was a mistake; that the correct in terface between
Hi,
David Levine wrote:
> Let's assume the user's shell is bash. whatnow does this:
>
> bash -c "ls ;"
My binary may be old but
$ strings `which whatnow` | grep SHELL
$SHELL -c " cd %s;ls
$SHELL -c "cd;pwd"
$SHELL -c "cd %s;cd %s;pwd"
$SHELL -c "ls %s"
$SHELL -c " cd
Hi Norm,
> ~ cat /t/,a
> /home/norm/Downloads/SoundShot.tgz
> /home/norm/Downloads/SoundShotA.png
> /home/norm/Downloads/SoundShotB1.png
> /home/norm/Downloads/SoundShotB2.png
...
> ==
> What now? attach $(< /t/,a)
> /bin/bash: line 1: /home/norm/Downloads/SoundShotA.png: Permission denie
Hi David,
> > what's happening is
> >
> > execve("/bin/sh",
> > ["sh", "-c", "$SHELL -c \" cd /tmp;ls `seq 1 5`\""], ...) = 0
> > execve("/usr/bin/seq",
> > ["seq", "1", "5"], ...) = 0
> > execve("/bin/bash",
> > ["/bin/bash", "-c", " cd /tmp;ls 1\n2\n3\n4\n5"],
Hi Ken,
> I look at this and I can't help thinking that's the wrong answer;
> getting shell quoting is hard enough, but having to double-quote it?
> That just seems like a mistake to me.
Well, it's sh it needs quoting from, not $SHELL, so it is known what
needs quoting, unlike the unknown quoting
Hi,
> David Levine 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 wonder if whatnow's `attach foo' atta
Hi David,
> Maybe this is another argument for adding -d to the ls command. But
> -d conflates not descending into directories with not dereferencing
> symbolic links, so the display (alist) will show links.
That too is probably wanted? If I attach foo that's a symlink to bar by
naming foo then
Hi David,
> Does POSIX ls support -- ?
Absolutely.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html refers
to
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02
which says
Guideline 10:
The argument -- should be accepted as a delimi
Hi David,
> With auto and suffix, n is one beyond the existing file with the
> highest number in the same form.
I think it's more that n is the first number from 1 that isn't already
used? So with foo.{1,2,3,9} it's foo.4.
Cheers, Ralph.
___
Nmh-work
Hi David,
> > > With auto and suffix, n is one beyond the existing file with the
> > > highest number in the same form.
> >
> > I think it's more that n is the first number from 1 that isn't
> > already used? So with foo.{1,2,3,9} it's foo.4.
>
> You're right. As you might expect, the code just
Hi David,
> > Strictly speaking, I wonder if it should be attempting to open(2)
> > each contender with O_CREAT | O_EXCL until one succeeds, at which
> > point it has the file descriptor to use. Unlikely to be an issue
> > with interactive use but perhaps with some procmail-type handling?
>
> Go
Hi,
Once again I've been bitten by a lone `sortm' defaulting to `all' when I
intended to do `sortm lp'. On a folder of some 20,000 emails that quite
perturbs incremental backups! `rmm' doesn't default to `all' so I'm not
sure sortm should; it's too destructive as the old order may not be
reprod
Hi,
Joel Uckelman wrote:
> Thus spake Ken Hornstein:
> > Hm. I guess to me "sortm" defaulting to "all" makes sense; I mean,
> > don't you want to that the vast majority of the time? (I'm guessing
> > "lp" is a sequence you created?). And I guess I always figured the
> > order of messages was ep
Hi Paul,
> i almost never sort an entire folder -- usually i just sort the unseen
> sequence, or some other small batch of messages.
Your jib has a fine cut, sir.
> rather than changing the default behavior by default, how about adding
> an option to change the default behavior. :-)
> sortm
Hi Paul,
> kevin wrote:
> > I have two use cases for sortm
> >
> > 1. sortm +folder
> > 2. sortm -textfield subject -limit 0 +folder
>
> does that actually work for you?
I think so. Initial conditions:
$ type sortm
sortm is hashed (/usr/bin/mh/sortm)
$ g -w sortm ~/.mh_pro
Hi Paul,
> i've recreated your test case, and the '-limit 0' test still gives
> reverse date sort:
> $ s
> 1 Thu, 03 Oct 2012 00:12:00 + A
> 2 Thu, 02 Oct 2012 00:12:00 + A
> 3 Thu, 02 Oct 2012 00:12:00 + C
> 4 Thu, 01 Oct 2012 00:12:00 + B
> 5 Thu,
Hi,
How does one clear `cur' for a folder? It can be set with `folder 42'
though the mandatory line of output is annoying. It can be listed and
set with mark, e.g. `mark -seq cur -list', but not deleted; attempts do
nothing.
I wish to clear it in a script so a later habitual `rmm' will complai
Hi David,
> > How does one clear `cur' for a folder? It can be set with `folder
> > 42' though the mandatory line of output is annoying.
>
> I just redirect the output to /dev/null.
Me too, in the expectation it contains just that one line.
> There is a folder -noprint, currently undocumented.
Hi David,
> > Perhaps have mark work on it as it already partially does. `mark
> > -seq cur -delete all'.
>
> How about this, Ralph? Instead of setting "cur" to 0, it ends up
> removing it from .mh_sequences. That's the same state as never having
> set cur.
Sounds good.
> @@ -80,8 +80,14 @@ s
Hi Paul,
> jerrad wrote:
> > I don't really understand how relative numbers are useful, but if
> > they are to be introduced why not use the same signifier as for
> > folders? i.e; @
> >
> > cur@2 = cur+2 cur@-4 = cur-4
...
> i'm also not sure how '@' relates to folders.
Perhaps Jerrad was ref
Hi Paul,
> > folder +inbox
> > refile @example last# Means +inbox/example.
>
> huh. i believe you, but you might have just found a bug in the man
> pages. :-) i can find no mention of such a feature.
Me neither. Historically,
$ g -B3 TSUBCWF docs/ChangeLog_MH-3_to_MH-6.6
Hi Jerrad,
> Commands which take a folder name (inc, refile, scan, sortm, ...)
> will accept the folder name in two formats: '+folder' and
> '@folder'. '+folder' specifies a folder underneath the Path
> defined in your nmh profile e.g; with the default '''Path:
> Mail''', '+fo
Hi,
Working my way back through the parents to see what man pages were
on-going I came across some changes to the use of printf(1) in
uip/mhmail committed by David Levine.
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=342e35519e925ac0d7b24953bc45028241a7d122
It's a brief diff but has
Hi steve,
> > I would not be so sure about 2) ... I know that Cyrus IMAP used to
> > reject mail messages with headers that contained non-ASCII
> > characters. And to me the biggest problem is the encoding contains
> > the only place where the character set is listed. The only times
> > I've see
Hi David,
> sortm always issues a warning for each message that is missing a
> "Date:" field, has a "Date:" field that cannot be parsed, or has a
> format error in any header field. With the -check switch, sortm
> inhibits all modifications to the folder if there any such messages,
"there any".
Hi,
David wrote
> While terminfo or something higher level, more generic, etc., would be
> nice, we're so close now to supporting ANSI escapes that I'd like to
> (and am going to :-) get them to work. It doesn't preclude adding
> something else, of course.
I'd worry implementation is rushing ahe
Hi Ken,
> for example, man outputs "bold" text by doing overstriking with ^H and
> less knows how to deal; I don't know if that was planned as much as it
> is an artifact of history.
man (nroff) gets bold by overstriking because moving the teletype's head
back and putting down more ink is the bes
Hi Paul,
> why do scan and inc already link against termcap?
$ ltrace -l /lib/libncurses.so.5 scan -clear last >/dev/null
tgetent(0, 0x7fff5bd4348c, 2, 2, 0x414e40)
= 1
tgetflag(0x
Hi Lyndon,
> You can get the sequences out of terminfo without having to use the
> full blown curses interface. (tparm() if memory serves).
Agreed.
$ tput setb 3 | hd
1b 5b 34 36 6d|.[46m|
0005
$
> And by using terminfo, you make
Hi steve,
> When I'm running MH-V on localhost's display, I then do 'v' to have
> MH-V execute "mhstore" to save the image attachment and do e.g.
> "firefox -browser file:///home/rader/.mh_cache/23.2.jpeg &" to bring
> it up in my browser.
Is -browser needed?
> When I'm remote and have fast X11
Hi steve,
> Playing around with my (poor ol?) Firefox 3.6.13 on SL54, it seems
> that firefox -browser doesn't work right: it opens the URL in a tab
> and opens a new window with the startup home page! So I guess that
> should change to just "firefox"?
Yep. Or xdg-open(1).
> > What's the diff
Hi,
I occasionally use Gmail for my non-main account and recently replied to
an email that I had written, the last on a thread. Gmail didn't To: me,
as nmh does, but kept the recipients of the original for To: and CC:.
Perhaps nmh's replcomps could be altered to do a similar test; at the
moment
Hi David,
> > I occasionally use Gmail for my non-main account and recently replied to
> > an email that I had written, the last on a thread. Gmail didn't To: me,
> > as nmh does, but kept the recipients of the original for To: and CC:.
> > Perhaps nmh's replcomps could be altered to do a similar
Hi Ken,
> The current tools, "ap", "dp", and "fmtdump", all live in $(libdir).
> I understand doing this for backend programs designed to be called by
> other programs, like post & mhl. But I never understood why those
> programs were installed there. Should this hypothetical test program
> be i
Hi David,
> Ralph wrote:
> > Is there a distro that puts nmh in /usr/bin and not /usr/bin/nmh?
>
> Fedora puts the main commands in /usr/bin/. And as Joel noted, the
> ancilliary commands in /usr/libexec/.
Thanks. So I think ap/dp/... should stay out of PATH by not being
prompted to /usr/bin o
Hi Ken,
> fmtdump, I think that's one that could go into $(bindir);
> I don't think there's much of a conflict there.
It's effectively debug for format authors rather than an everyday
command. Is its functionality easily made available at the
function-call level to commands that use formats?
Hi,
This isn't the latest nmh but may still be an issue. Consider...
$ folder
test1+ has 2000 messages (1-2000).
$ cd `mhpath`
$ ls | tr 0-9 d | sortuniq-c
9 d
90 dd
900 ddd
1001
$ rmm all
rmm: more than 998 messages for rmmproc exe
Hi David,
> https://savannah.nongnu.org/bugs/?15215
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268744
That's one of mine. :-)
> pick currently handles multiple-line header fields by:
> 1) replacing each newline with a space, and
> 2) leaving leading whitespace on continuation lines inta
What-ho Ken!
> >rmm: more than 998 messages for rmmproc exec
>
> So ... looks like this has been that way forever. Right now all calls
> to execve() and friends are limited to MAXARGS arguments (which is
> currently defined as 1000). Ok, 1 for argv[0], one for the trailing
> NULL, that's ho
Hi Jeff,
> > Feeding rmmproc filenames on stdin is the normal workaround, LF or
> > NUL terminated.
>
> Changing the way rmmproc is called would break all out existing
> scripts.
Clearly, yes. There'd be to be some indication that the rmmproc desired
it, or a run-time test done to show it copes
Hi David,
> Or bail out and let the user do that manually? Is this something
> that people do often? Personally, if I tried to rmm a large number
> of messages, it would be a mistake.
It bites refile(1) as well as rmm(1), rmmproc is used both times, but
not sortm(1), there the old order is just
Hi Ken,
> But let me suggest a counter-proposal; I was thinking of making the
> yet-unwritten fmttest program do all of the work that ap and dp
> currently do. Also, it could take care of the work that fmtdump does
> as well. How about we leave fmtdump in it's current purgatory but
> have the us
Hi Paul (Fox),
> so, i've stumbled over rmmproc's limit in the past (and, like others,
> have quietly, manually, done it in chunks instead), but i don't think
> i've ever seen a similar limit with "rm". and now i'm wondering, why
> not? certainly this works just fine:
>
> $ mkdir /tmp/many
Hi Paul (Fox),
> but looking at rmm.c, refile.c, and folder_delmsgs(), i don't think
> that issue applies. the patch below fixes the problem, and makes
> rmmproc and refile do the right thing (well, at least, the modern
> thing). NB: i didn't test to the limit where execvp should return
> E2BIG.
Hi,
Paul Vixie wrote:
> On 2012-11-27 1:09 AM, Ken Hornstein wrote:
> > So for this hypothetical rmmpipe ... should the filename separator
> > be a newline or a \0?
>
> if we want to allow newlines in filenames we'd have to allow -0 (like
> xargs does) to change the format. this would be a burden
Hi Paul,
> > When you say it makes refile `do the right thing', do you mean
> > refile doesn't create copies of the emails if the future rmmproc
> > can't be invoked? I'm guessing not from the patch's brevity. :-)
> > That means the user is left with many duplicate emails, most likely
> > w
Hi,
David Levine wrote:
> Paul F. wrote:
> > (one way to reduce the likelihood of this, and of the original
> > overflow issue, might be to pass the message arguments to rmmproc in
> > the same form that they were received by refile. currently "refile
> > all" causes a call to rmmproc with a full
Hi David,
> > > Is `scan +/tmp/foo' documented anywhere, i.e. the ability to treat
> > > any directory as a folder, not just one under Path? And `@..'
> > > after that..
>
> How's this:
>
> Commands which take a folder name (inc, refile, scan, sortm, ...)
Three's enough? "(inc, refile, sc
Hi Ken,
> • Make sure you run mhbuild ("mime" in whatnow) on a message with
> UTF-8 characters, it will take care of the right magic. Although it
> always picks quoted-printable as the encoding, which I'm personally
> not happy about.
Something I picked up from the list... I don't build MIME em
Hi Paul,
> is there a way using mh tools to at least detect that there's more to
> the non-text part that might be interesting?
You mention the non-MH munpack, are you aware of mhlist(1) and
mhstore(1)? Building something around mhlist should be possible.
Cheers, Ralph.
___
Hi Norm,
> That's disconcerting. For more than a decade now, the default for my
> editor was for no line wrapping. I inserted new lines to generate my
> own formatting. But some recipients complained that my Emails are
> "jagged". This was caused by their Email client inserting its own line
> endi
Hi,
Lyndon Nerenberg wrote:
> Ken wrote:
> > > What's wrong with QP? Are you advocating for Base64? If so, why?
> >
> > Well, since you're asking ... I'm advocating 8bit. Or really, make
> > the encoding user-selectable.
>
> Oh :-) I don't usually think of 8bit as an 'encoded' form :-)
>
> I
> > obiwan-[~] mcr 3690 %echo $LANG
> > C
> > obiwan-[~] mcr 3691 %env | grep LC
> > LC_TIME=en_DK
> > LC_ALL=C
>
> I think (assuming your tablet is UTF-8) want a LC_CTYPE=en_CA.UTF-8 in
> there. Or something close to that.
Mine's
$ locale
LANG=en_GB.utf8
LANGUAGE=
LC_CTYPE="en_
Hi Lyndon,
> Ralph Corderoy wrote:
> > Is an override required? It could always try to send 8-bit...
>
> Which could fail if the system has an MTA that doesn't do 8bit.
The RFC covers what to do in this case; either downgrade to 7-bit or
fail to pass it on with an error.
Hi Paul,
> i'm happy to prepare a patch to add "-nosequence"... unless i'm
> missing something and it's unnecessary.
Does HISTORY in mh_profile(5) help?
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailm
Hi Ken,
> Paul wrote:
> > i'm happy to prepare a patch to add "-nosequence"... unless i'm
> > missing something and it's unnecessary.
>
> Seems to make sense to me.
Would a more general -noprofileparam be a more useful addition to
argument processing? That way, pick, scan, etc., when used in s
Hi David,
> Paul F. wrote:
> > Ralph wrote:
> > > > i'm happy to prepare a patch to add "-nosequence"... unless i'm
> > > > missing something and it's unnecessary.
> > >
> > > Does HISTORY in mh_profile(5) help?
> >
> > no, not on first (and second and third) read. should it?
>
> I agree that i
Hi,
Earl wrote:
> The lack of following of standards even occurs at Google. GMail fails
> to format text/plain in a fixed-font.
Neither does it display Resent-{To,From,...} headers created by dist(1).
Nor have I found out how to `forw -mime' an email from it.
Cheers, Ralph.
___
Hi Bill,
> How about
>
> $ MH= pick -sequence foo
My mh_profile(5) doesn't explain the significance of a defined but empty
$MH. A quick test here suggests the same .mh_profile is opened with no
$MH defined or an empty one.
Private sequences specific to a script's context is the only way I
Hi Ken,
> How should we interact with a user's editor and any MIME formatting we
> need to do? Sigh. Nothing obvious pops out at me; I'm open to
> suggestions.
I've never bothered with whatnow's attach and friends; they don't seem
very MH, adding a little shell inside whatnow.
The
#appli
Hi Paul,
> $ mhlist
> msg part type/subtype size description
>
> 123 multipart/mixed 7746
> 1 multipart/alternative 7287
> 1.1 text/html 3850
> 1.2 text/plain
One more thought...
> it would be nicer if there was a more default-using, perhaps like
> whatnow's attach,
>
> #attach /tmp/foo.pdf
>
> It should perhaps allow the [description] syntax.
One thing I currently find a pain on occasion is the lack of `undo'.
One silently `mime's at the whatnow
Hi Lyndon,
> Let me rephrase that. I know (hope?) we aren't ditching 7but support.
> My point is that 7bit and friends will be here almost forever, so
> there is no purpose to be served in arguing about supporting them.
Sure there is. The number of 7-bit MTAs is tiny and becoming ever
smaller.
Hi Oliver,
> Sounds like you need Jerry Peek's "original" script:
> http://rand-mh.sourceforge.net/book/examples/mh/bin/original or
> http://oreilly.com/openbook/mh/s-origin.htm
Thanks! Seeing they just do a simple rename from ,42.orig back to 42 is
enough. I can do that manually rather than ne
Hi markus,
> Please have a look at my master's thesis as it will answer many
> questions.
Thanks for telling us about this markus, an interesting read. (I liked
that it was done with troff and friends too. :-)
Cheers, Ralph.
___
Nmh-workers mailing
Hi David,
> Would it make sense to toss it all and use mmap()? Conceptually, it
> doesn't seem like a difficult problem to parse header fields and maybe
> a body and just hand back a pair of pointers and the state indication.
I'd be -1. It doesn't seem like it's worth deviating from the file I/
Hi Lyndon,
> On 2012-12-11, at 6:26 PM, Ken Hornstein wrote:
> > Well, this isn't exactly the fault of git, per se ... it's the
> > post-receive hook script, and we don't manage the repo so we can't
> > change that.
>
> And there's my bitch.
You've quite the harem. ;-)
Cheers, Ralph.
Hi,
Lyndon wrote:
> > Seems like adhering to Postel's law here is reasonable.
>
> As for what other mailers do, they are not MH and we are not them. We
> don't need to emulate their stupidity.
I agree with Lyndon. Unless we find a major MUA has taken to spewing
this errant guff, making it a
Hi Tethys,
> Printing a warning and assuming 8bit would seem to have few downsides
> to me.
AIUI we know of two emails that are broken. That doesn't seem enough to
warrant changing the code to not match the RFCs and opening the door a
bit more, encouraging further forgiveness of broken input. M
Hi,
Harald Geyer wrote:
> Actually the KMail bug tracker has accumulated a few tickets about
> this over the years - mostly submitted by peope using nmh.
One seems to be https://bugs.kde.org/show_bug.cgi?id=296629
Cheers, Ralph.
___
Nmh-workers mailin
Hi Ken,
> Maybe changing the error message a bit would be useful?
Yes, I agree with David's suggestion. Options include: state the RFC
bit being violated so the user can cite it at the miscreant; suggest
how the user edit the email to workaround; refer the user to a bit of
the documentation t
Hi Ken,
> > discard.c also has some non-portable code:
> > And it's called on the streams that post uses to talk to its smtp
> > server:
> >
> > kill (sm_child, SIGKILL);
> > discard (sm_rfp);
> > discard (sm_wfp);
> >
> > The discard()'s after killing the child process seem unnecess
Hi steve,
> Do any of you have a working example that uses troff/groff (mm
> macros?) to print four column output? I'll bet someone does.
Best off asking on the GNU groff mailing list, even if you're not using
groff but an alternative, e.g. Heirloom troff. That's where us troffers
hang out, and
Hi,
> > What nmh needs is some generic tools that can be used to fetch mail
> > via:
> >
> > 1) Local delivery from the MTA
> > 2) Fetch mail from the local maildrop
> > 3) Fetch mail from POP, IMAP and all the other methods supported by
> > fetchmail
> > 4) Accept mail from a third party program
Hi Ken,
> It occurs to me that it would be simple to add an extra element to the
> struct swit that included the value to return, so these things could
> be automatically indexed via enum (or whatever). In other words, the
> above code would convert to:
>
> enum { AUDSW, NAUDSW, CHGSW, NCHGSW, }
Hi,
> enum {
> AUDSW = 0,
Except don't put in the `= 0', it's needless noise akin to initialising
something in BSS to 0 and makes the reader wonder the writer's intent.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists
Hi Ken,
> > If the new struct member is always going to run from 0 without gaps,
> > I assume so since the current return value is an index into
> > switches, then it needn't be there?
>
> Well, it doesn't HAVE to be, that's just the way it's implemented now.
> Why keep it being an index when it
Hi Ken,
> I'm not sure that helps in this situation here, though. We have three
> distinct bits of information that need to be matched up: the option
> name, the minimum abbreviation length, and the value that needs to be
> returned. I'm not sure:
>
> X("noaudit", 0, NAUDSW)
>
> is bette
Hi Ken,
> > With X(), returning the index remains sufficient because the enum
> > will always match the array so there's no need to also store the
> > index in the struct. The two expansions of X(), enum and array,
> > could be in a central #include.
>
> I'm trying to envision how this would wor
Hi Ken,
> Even though it's a bit of hack, I like it.
And most readers can just take how the list of X() work without having
to investigate the gubbins.
> But ... it still somehow sticks in my craw the idea of returning an
> array index. It just seems wrong to me, somehow. So I'm going to
> cha
Hi Paul,
> does this solution lead to symbols that can't be found with
> simple search tools? a quick skim made me think it doesn't, but
> wanted to check. i.e., will i find a reference to, say, MARK_FOO
> in the code that i can't grep for, because it was constructed with
> name ## _FOO
> or
Hi Paul,
> it would change the auto-generated length token from LEN_MARK to
> LEN_MARK_SWITCHES, but i'm not sure that matters.
Agreed. I guess I'm use to more complex cases where different nuts and
bolts have to be added on around the parameter so it has to be just the
base.
Cheers, Ralph.
__
Ken wrote:
> I propose we hardcode a default of "more".
+1
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hi,
When repl(1) uses mhl to quote the original email's body, e.g.
body:component="> ",overflowtext="> ",overflowoffset=0
blank lines end up with a trailing space. Should trailing whitespace
always be stripped from these lines? If not, could it be yet-another
option/mhl-variable? I'd much
Ken wrote:
> > > > I propose we hardcode a default of "more".
> > > +1
> > +1
>
> As long as I'm there ... is it alright if get rid of --with-editor?
> Hardcode a default of "vi"?
+1. (Though it's optional under POSIX IIRC.)
Cheers, Ralph.
___
Nmh-wo
Lyndon Nerenberg wrote:
> I'm reminded of arguing with the USG people about why the /bin/sh on
> the 3B4000 still recognized '^' as a "pipe" character.
I miss that. Used to be handy on keyboards that didn't have a working
`|'.
Cheers, Ralph.
___
Nmh-
Lyndon Nerenberg wrote:
> > I miss that. Used to be handy on keyboards that didn't have a working
> > `|'.
>
> By 1987, '|' had trumped pre-ASCII keyboards :-)
Even if a | rune was on a key it didn't mean you could enter it from
that key or any other for a good way after that. :-)
Paul Vixie w
Hi Ken,
> Only problem with that is that "arg1" gets put into $0, which doesn't
> get expanded by $@, so it should really be:
>
> /bin/sh -c 'proc "$@"' dummyarg arg1 arg2 arg3
>
> What do others think about this? Anything I'm missing?
No, I think that's the way to approach it. There's a hist
Hi Lyndon,
> If people need 'less -aics', they can create $HOME/lib/mh-less and
> stuff that into the appropriate MH configuration location.
> Re-inventing shell command line parsing is an exercise in security
> holes, let alone frustration.
It's avoiding the shell parsing by giving the arguments
Hi Paul,
> > /bin/sh -c 'proc arg1 arg2 arg3'
> >
> > and so on, but that would involve an extra level of shell
> > interpretation.
>
> i'm not clear on what's so wrong with the above. i assume proc would
> be expanded, so you'd end up with
> /bin/sh -c 'less -aics arg1 arg2 arg3'
I th
Hi Lyndon,
> > It's avoiding the shell parsing by giving the arguments in argv[]
> > with just a thin bit of boilerplate to do the sh -c bit.
>
> But it's still not punting to the shell when the shell does it at
> least consistently. There is no reason for *mh to do this.
> Everything can be de
Hi Paul,
> couldn't one just skip the whole "what's a shell metacharacter these
> days?" issue, and just always go for door #3?
I suppose the overhead of kicking off sh is trying to be avoided for the
simple case. (Where the user knows route #3 is being taken then they
could do an exec but that'
Hi David,
> sortm: can't parse date field in message 66, using file mod time,
> continuing...
"sortm: 66: resent-date not understood; will use mtime"
"continuing..." seems superfluous.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@n
Hi David,
> > > sortm: can't parse date field in message 66, using file mod time,
> > > continuing...
> >
> > "sortm: 66: resent-date not understood; will use mtime"
> >
> > "continuing..." seems superfluous.
>
> OK, but I think that we should keep the original beginning, so:
>
> sor
101 - 200 of 1614 matches
Mail list logo
