Re: [nmh-workers] The State of exmh.

Hi, > Thanks, I now have > > $ b2sum exmh-2.9.0.tar.gz | cut -c-42 > a097b2e5c5cd44dd6d84e239bf6e674584e9eb4952 Reading through the notes, it appears metamail is pretty vital for display of MIME messages. (In particular, I was interested to see how exmh handled text/html.) metamail

Re: [nmh-workers] The State of exmh.

Hi Ken, > Even being on the list ... it's a pain. Because to access the list > archives I have to remember my "list password" Because there's so little value in the Mailman subscription password, I let Firefox remember them. > I mean, I don't get it ... why not make them public? I'm on a

Re: [nmh-workers] The State of exmh.

Hi valdis, > I'm tagging the current git tree as 2.9.0 and pushing out the tarballs Thanks, I now have $ b2sum exmh-2.9.0.tar.gz | cut -c-42 a097b2e5c5cd44dd6d84e239bf6e674584e9eb4952 -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers

Re: [nmh-workers] The State of exmh.

Hi Tom, > The last I heard on the topic was per attached. Ah, thanks. I see 2.8.0 at https://sourceforge.net/projects/exmh/files/exmh/ > valdis wrote: > > Finally beat 'git cvsimport' into submission That reminds me of Eric Raymond's reposurgeon that Bill Wohler used for coverting the mh-e

[nmh-workers] The State of exmh.

Hi, Where does one go for exmh these days? Google's top hit is http://exmh.sourceforge.net/ and that says the current web site is http://www.beedub.com/exmh/. There, `2.7.2 released January 7, 2004' headlines and the tar file is beside it. But Debian ships 2.8.0 on its stable version and in

Re: [nmh-workers] Need help with sending mail

Hi Ken, > Even Ralph (RALPH!) admitted he doesn't always read to the end of the > post(8) man page all of the time :-) I think that's because I wade through the DESCRIPTION, searching for an option or two amongst the verbose prose, and then don't skip to the end unless I think SEE ALSO might be

Re: [nmh-workers] Need help with sending mail

Hi kre, > We should not need more than that, though the message could be moved > (or duplicated) earlier in the man page to make it even harder to > miss. Given I'm one who consistently misses the existing documention in post(8) when I reply to users having problems with post, due to not reading

Re: [nmh-workers] Need help with sending mail

Hi David, > Should we add a warning to the profile parser for post, whom, et al., > entries to note that they're ignored? I don't think whom(1)'s entry is ignored? Maybe I'm interpreting that wrongly. $ cat >.mh_profile path: . whom: -vote-for-ken ^D $ HOME=$PWD mhparam

Re: [nmh-workers] Need help with sending mail

Hi Jay, Ken wrote: > If that doesn't work then please post the output from -snoop. Look out: (Beware that the SMTP transaction may contain authentication information either in plaintext or easily decoded base64.) ― send(1). -- Cheers, Ralph.

Re: [nmh-workers] Need help with sending mail

Hi Jay, > Adding -verbose to send or post does not provide any more detail. Try send(1)'s `-snoop'. > I've been googling for over a week. Feel free to ask these kind of user questions here sooner than that. :-) For clarity, the output of `mhparam version' is handy to us. > post: -mts smtp

Re: [nmh-workers] [mhical] accepting google calendar meeting invitation

Hi David, > I wonder if Google needs the DESCRIPTION in the reply. mhical strips it. Could me. Google put an odd warning it in given it's just a description. You'd think they'd key off just the UID. Please do not edit this section of the description. I noticed there were two vCalendar

Re: [nmh-workers] [mhical] accepting google calendar meeting invitation

Hi Tom, > mhical -reply accept < .../invite.ics > /tmp/invite.ics What's `mhical -version' say? Any chance we can see the `.ics' before and after, even if you redact the private parts? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers

Re: [nmh-workers] Test

Hi Kevin, > I think my incoming email is work now. Just testing. It's all been find from Mailman's point of view since you said it was fixed. If you want test replies without bothering the subscribers, mhmail nmh-workers-requ...@nongnu.org <

Re: [nmh-workers] Email VERY slow (about 20 hour delay) leaving google mail server(s)

Hi Kevin, > What trouble is the nmh-workers list seeing with regard to my email > address? As an example, Mailman saw a bounce in trying to send your subscription a copy of your email to the list. :-) This is a Mailman mailing list bounce action notice: List: nmh-workers

Re: [nmh-workers] procmail/rcvstore & message file format

Hi Richard, > Is there a proper way to use procmail and rcvstore that yields correctly > formatted RFC822 message files? I use neither these days so there might be a way I don't know, but procmail is happy to deliver directly to MH folders if that helps. Give the folder's path with `/.'

Re: [nmh-workers] Quoting non-ASCII in reply

Hi Conrad, > > Have you also tried `mhfixmsg -textcharset utf-8'? > > I hadn't, but it doesn't seem to improve my results, with or without > various combinations of -reformat and -replacetextplain. One example that doesn't work would give us more chance of helping. > Is mhfixmsg the most likely

Re: [nmh-workers] mhstore saving pdf w/o decoding filename- soln apparently: mhfixmsg

Hi Tom, > Should mhfixmsg run on each incoming message, or at least each one > with mime headers? Maybe by adding to ~/.procmailrc? I think David Levine, mhfixmsg's author, runs it on every incoming email in some way. See the two `Integration' in the man page. -- Cheers, Ralph.

Re: [nmh-workers] mhstore saving pdf w/o decoding filename (config issue?)

Hi Tom, > $ mhstore > storing message 1446 part 1.1 as file tmp/nmh/1446.1.1.txt > storing message 1446 part 2 as file > tmp/nmh/=?UTF-8?b?Y2xpbWF0ZSBmbHllciB1cGRhdGVkLnBkZg==?= > $ > > Notice the filename for part 2 is munged. Search for `2047' in mhfixmsg(1). -- Cheers,

Re: [nmh-workers] config ? re Content-Disposition: attachment; ... filename=SOME_UTF-8_CODED_STRING

Hi Tom, > What's the (config file?) fix so the string in > filename=SOME_UTF-8_CODED_STRING > associated w/below attachment headers > is properly decoded? ... > Content-Disposition: attachment; > filename="=?UTF-8?b?Y2xpbWF0ZSBmbHllciB1cGRhdGVkLnBkZg==?=" $ scan -forma

Re: [nmh-workers] multipart/related and -prefer.

Hi Ken, > My -prefer is re-ordering parts 1 and 2, as I can show with mhlist. ... > I can select the text/html in this case with > > $ mhlist -nov -prefer text/plain -prefer multipart/related ... > > Typically, the text/plain and text/html are children of the same > > multipart/alternative,

[nmh-workers] multipart/related and -prefer.

Hi, My .mh_profile has `mhshow: -prefer text/plain', but nothing for mhlist. I recently read this `Apple Mail' email with mhshow, read the plain/text, and it wasn't apparent to me there were images too. $ mhlist -nov msg part type/subtype size description 32753

Re: [nmh-workers] Reproducible build patch

Hi kre, > Thanks for pointing it out. No problem. I didn't realise you had fingers in that pie. One thing I noticed when looking at http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/parsedate.y?rev=1.32=text/x-cvsweb-markup the other day is yylex() uses any leading run of `-' and '+' to set a

Re: [nmh-workers] Reproducible build patch

Hi kre, > As I said, I know (somewhat) the -d parser on netbsd, which I know > handles the @N form, but I kind of doubt has much in the way of error > checking there. No, it calls the hoary parsedate(3),

Re: [nmh-workers] Reproducible build patch

Hi kre, > The point is that the "try this" or "try this" ... stuff in order to > find an arg sequence for date that works also allows invalid values > for the input time to be ignored, You still seem to be referring to the first version I wrote? Here's the second one again that's being replied

Re: [nmh-workers] Reproducible build patch

Hi Ken, > > It determines the style of date(1) to invoke without relying on user > > input, then when that's known it invokes it again with the desired > > number of seconds but without discarding stderr in case of problems, > > and the existing `set -e' would exit on an error. > > It occurs to

Re: [nmh-workers] Reproducible build patch

Hi kre, > > So I think `:-' is the wrong test, and `-' should be used. ... > really? Is failing (well, planning to fail, and faliing at that) > when the SOURCE_DATE_EPOCH is set to a null string, rather than > treating that as the same as not set at all really that important? It tells the

Re: [nmh-workers] Reproducible build patch

> So I think `:-' is the wrong test, and `:' should be used. I mean, of course, `-', as I did: > now="${SOURCE_DATE_EPOCH-$(date +%s)}" -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Reproducible build patch

Hi Ken, > We received the following bug report today: > > http://savannah.nongnu.org/support/?109535 > > It seems to me like reproducible builds are probably a pretty good > idea Yes. > and nmh should support them, and the patch looks relatively small. It tinkers with the hostname too.

Re: [nmh-workers] How big a message should I accept?

Hi David, > http://www.maths.tcd.ie/~dwmalone/smtpsize.png Interesting, thanks. So the 50 GB (GiB?) bucket halves in the two years from 2016 to 2018? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Problem With inc Not Sending Passwords After Upgrade To 1.7.1

Hi Darren, > Password ([machine]:[name]): [PASSWORD] > => PASS (null) ... > It works if the password is put in a netrc file; it doesn't work if > the password is typed at the prompt. This is my fault from 2016-10-16. In sbr/ruserpass.c's ruserpass(), the last interesting statement should be

[nmh-workers] mhbuild(1)'s `-check' Belongs to Another.

Hi, mhbuild(1)'s `-check' adds a `Content-MD5' header to each part. Consider it's run by whatnow(1) due to `mime', and that's followed by an `edit', allowing the user to actually edit what's covered by the digest. I think the addition of `Content-MD5' should be in the outgoing pipeline once the

[nmh-workers] Old MH Source.

Hi, I thought the archaeologists here would be interested in some fragments of old MH source that isn't in nmh's git. https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/mh Thanks to Noel Chiappa, who pointed it out on another list. There might be older, more complete, source kicking about;

Re: [nmh-workers] mhshow and Headers

Hi Martin, > > /usr/lib/nmh/mhl \ > > -form <(printf '%s\n' from:decode : body:nocomponent,format) \ > > -fmtproc true \ > > `mhpath +foo all` ... > I tried it on a folder with 2161 messages and it is not showing the > body which is good but it is blowing up on the

Re: [nmh-workers] mhshow and Headers

Hi again Martin, > if there is a way to temporarily shut off the generation of the body, > we should have only headers that need to be blocked. This doesn't display the body for me. /usr/lib/nmh/mhl \ -form <(printf '%s\n' from:decode : body:nocomponent,format) \ -fmtproc

Re: [nmh-workers] mhshow and Headers

Hi Martin, > Sometimes, there are other ways to solve the same problem > so any suggestions are welcome. export LC_ALL=C sed -s $' /^$/,$d /^From /d /^[ \t]/d s/[ \t]*:.*// ' `mhpath +foo all` | tr A-Z a-z | sort | uniq

Re: [nmh-workers] The message Body Shows but the Subject doesn't Decode.

Hi Martin, > One diagnostic I did do was to try to determine which filter is being > called by using strace. strace -e trace=desc but mhl got called so I > didn't see any way to slip the %(decode{subject}) directive in to give > us decoded output rather than raw data. Search for `Subject' in

Re: [nmh-workers] can comp return the filename of the newly created draft?

WD >profile $ export MH=$PWD/profile $ mhparam draft-folder $ comp -noedit -nowhatnowproc Welcome to nmh version 1.7+dev ... Press enter to continue: $ ls context draft profile

Re: [nmh-workers] Cleaning up old messages

Hi Peter, > I've done some poking into it, and I know I can go from folder to > folder, delete all the messages, and then use some external shell > command to really delete them, but frankly, this is a bit overwhelming > for me. Is there a way (or a script that comes close to) letting me > just

Re: [nmh-workers] Help!

Hi Cyber, Do you know your email to the list had three `from' headers? From: =?UTF-8?B?zrs=?= From: Ruben de Bruin From: Cyber I can tell it meant a lot of list subscribers didn't receive your email due to rejections pointing at RFC 5322. -- Cheers, Ralph.

Re: [nmh-workers] Help!

Hi Norm, > The same. But I assumed that the message had more content that I'm not > smart enough to access. I also tried mhshow and mhlist. No, it's not there. You're seeing everything. Ask your correspondent if they know they sent an `empty' email. -- Cheers, Ralph.

Re: [nmh-workers] Help!

Hi David, > > The email you've attached has little in it. ... > > 8711 multipart/alternative 2616 > > 1 text/html 1118 > > 2 text/plain 451 > > Odd, I get: ... > 4681 multipart/mixed 9200 > 1

Re: [nmh-workers] Help!

Hi Norm, > Would some kind soul please tell me how to read the attached. The email you've attached has little in it. $ mhlist -nov msg part type/subtype size description 8711 multipart/alternative 2616 1 text/html 1118 2

Re: [nmh-workers] mts.conf relative sendmail option

Hi Ken, > > Yes. sendmail had to be run as /usr/lib/sendmail IIRC, so not in > > PATH normally ... > So I really can't justify (or coherently explain) why one invocation > of sendmail uses execvp() and the other does not. Yes, I'm not arguing that PATH shouldn't be used today, I'm just

Re: [nmh-workers] mts.conf relative sendmail option

Hi Ken, > > I think execvp(3) is being used, so PATH is searched? > > In fact ... it is not. Sorry! > I suspect that it was intended Yes. sendmail had to be run as /usr/lib/sendmail IIRC, so not in PATH normally, and Arch's exim and esmtp package both still provide a /usr/lib/sendmail, for

Re: [nmh-workers] mts.conf relative sendmail option

Hi Cyber, > I use NixOS So there's no /bin, etc., as we know it. > sendmail: sendmail > it complains that it cannot find the file. I think execvp(3) is being used, so PATH is searched? > Right now I am using a very ugly hack, I have made an executable > sendmaill file in my home directory

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi David, > Alright, the user could call a script to sanitize the URL. > Or not display it, such as by prepending with /bin/true. This seems to work here. nmh-access-url: printf '\e[31;1mexternal-body: %q\n' -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi David, > nmh-access-url: echo ^[[31\;1mSuppressed loading of Thanks. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Anthony, > - It leaks the IP address of my mail client simply by reading an > email. IIRC that was the motivation for me trying it; how many distinct IP addresses hit the URL. Related to your point, I could know the recipient viewed the email three times a couple of days ago, once from

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Anthony, > Part of EFAIL was that the mail client downloaded bits from the > Internet and interleaved them seamlessly into the message. IIRC it was that different adjacent parts were catenated if both text/html before being sent to something to interpret the HTML. This meant the join could

Re: [nmh-workers] sndmail program with parameters?

Hi Eduardo, > send: -mts sendmail/pipe -sendmail "/usr/bin/msmtp -C /path/to/rc" > > however, send is interpreting -C as an argument to istself, rather than taking > everything between quotes as the argument to -sendmail. Is this expected? Yes, unfortunately. mh_profile(5) says Shell

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi, Michael Richards, message ID <2726.1527268876@localhost>: ~ > And given EFAIL, it seems that we were wise. Or not? I've been surprised by the odd bit of decoding nmh has done for MIME parts, giving a text summary of the content. I

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Jón, > Ken writes: > > I've seen a distressing number of times when the text/plain version > > of a multipart/alternative message is not useful. Yesterday's fun was working out why a `reset your password' URL didn't work. Fill in the web page, submit, `Please correct the highlighted errors',

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Tom, > > sed 's/$/\n/' "$@" | > > Another idiom is: sed -eG. Oh yes, that's better. > > fmt -su | > > Interesting switches for fmt. Well, I thought you could play around with what you prefer. It's GNU fmt, which has annoying behaviour. Bring back _Software Tools_! $ yes foo |

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Andy, > > you're probably one of the few people who actually USES the > > text/plain > > Count me as another one of those few people #MeToo. Given mhshow(1)'s -prefer, it's quite easy. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Tom, > For the yahoo email client, no word wrapping is added to the received > email, ie. there are no '\n's within the received paragraph (unlike > gmail). Most importantly, for the yahoo client, each paragraph in the > body of the original has to end in '\n\n\n' in order for there to be a >

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

Hi Tom, > I have saved two example emails Can we see a part of the body from the mail's file for the detail. If it's sensitive, run it through tr A-Za-z a <`mhpath .` | tr 0-9 0 SMTP has a line-length limit and some MTAs, e.g. Sendmail, will forcibly split lines that are too long,

[nmh-workers] The neatmail MUA.

Hi, I came across https://github.com/aligrudi/neatmail#readme from knowing about the author's re-implementation of troff and thought its design might be of interest to the list, e.g. it seems one gets a scan listing and annotates it with actions. -- Cheers, Ralph.

Re: [nmh-workers] bug report -- message does not go away

Hi edo, > > It looks like you need to make sure your MH installation is > > completely consistent; it looks like stuff in your path is still > > depending on things in /usr/bin/mh. > > I agree, but I'm not sure where to take this You've upgraded to Ubuntu 18.04 and

Re: [nmh-workers] Autocrypt

Hi Thomas, > I have been meaning to implement Autocrypt [1] in my nmh configuration Thanks for the pointer. I've only read up to https://autocrypt.org/level1.html#the-autocrypt-header so far, but note Autocrypt: addr=a...@b.example.org; [prefer-encrypt=mutual;] keydata=BASE64 ...

Re: [nmh-workers] inc only incorporates one email from spool

Hi kre, > Are you sure you're not getting all of them, incorporated as a single > message? I think you're right. I wonder how fetchmail and procmail are being made to work together. > As I recall (have not done this for a very long time) procmail deletes > the 'From ' lines from messages (or

Re: [nmh-workers] inc only incorporates one email from spool

Hi Scrump, > When I incorporate mail with > inc +inbox -file ~/mail/spool > I only get the oldest (first at the top of the spool file) email > incorporated into my inbox. That's wrong behaviour. > Is this normal? No. > It doesn't seem to behave like that on linux, it incorporates all the >

Re: [nmh-workers] Since the (automatic) upgrade to 1.7.1 on CentOS 7.4.1708, send doesn't work

Hi Kevin, > I live in emacs and never type nmh commands. I've been using MH-E > since the 80's. I do know about inc, show, rmm, etc. But I've never > composed an email with nmh (or mh, before it). Thanks for letting us know. It's good to understand your kind exist as we tweak nmh and

Re: [nmh-workers] Since the (automatic) upgrade to 1.7.1 on CentOS 7.4.1708, send doesn't work

Hi Ken, > I was just thinking you could have run 'send' outside of MH-E with the > -snoop flag. Perhaps MH-E users can live in its silo, never venturing out, and not getting near a whatnow(1) prompt, or running send(1)? Maybe some nmh users are first and only MH-E users, rather than using nmh

Re: [nmh-workers] Since the (automatic) upgrade to 1.7.1 on CentOS 7.4.1708, send doesn't work

Hi Kevin, > I use MH-E. I have no idea how long it would have taken to augment > the send command line by looking at the MH-E sources. I've not used that. I did find https://www.gnu.org/software/emacs/manual/html_node/mh-e/Sending-Message.html#Sending-Message that suggests `mh-send-prog'

Re: [nmh-workers] Since the (automatic) upgrade to 1.7.1 on CentOS 7.4.1708, send doesn't work

Hi Kevin, > post: problem initializing server; [BHST] no servers available (use > -snoop for details > send: message not delivered to anyone > > Ideas on how to debug this? It's probably http://git.savannah.nongnu.org/cgit/nmh.git/tree/NEWS?h=1.7.1#n53 send(1) describes the `-port'. The

Re: [nmh-workers] nmh 1.7.1 for Fedora and RHEL

Hi again Jon, > Having `post: -port 25' in your profile David's pointed out off-list that post(8) doesn't read the profile, but send(1) does and passes its -port onto post, so that's what would be needed. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers

Re: [nmh-workers] nmh 1.7.1 for Fedora and RHEL

Hi Jon, > > > but I had smtp as mts in mts.conf and that doesn't work. Changing > > > it to sendmail worked. ... > > - post now defaults to port 587 on 'smtp' message submission. > > Don't override the port. If your local MTA doesn't listen on TCP port 587, `submission', and only 25 then

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Valdis, > > What is Fedora Core 27? :-) Fedora 26 is the latest version > > Fedora 26 is ancient history.. :) > > [~] cat /etc/redhat-release > Fedora release 29 (Rawhide) Yes, Jon Steinhart also pointed out I was wrong privately, to share the credit. I took it from

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Steffen, > Ok, i do not have Spinellis repo locally (yet), it is too big. > (How large is it in the end, Ralph?) 1.5 GiB. Too large to pull home with ADSL. I've a VM out on the Internet that has fast connectivity and I copied it there. But don't worry about replying after a delay. I've

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Steffen, > > mail(1) had the `~e' escape and then added a `~v' one, with VISUAL > > and EDITOR environment variables echoing the cpp(1) macro names of > > the default values. Kurt Shoens, k...@ucbvax.berkeley.edu, is down > > as the author in BSD-1-253-gc145e9e0ab5 of > >

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Ken, > > so a program like mail would offer two escapes (~e vs. ~v) to let > > yo invoke either. > > So ... I guess programs would look at the terminal and if your speed > was 9600 baud or greater, you'd use VISUAL, and if it was slower you'd > use EDITOR? No, AFAIK it was always the user's

Re: [nmh-workers] Unnecessary dependency on vi???

> I've been using (N)MH since 2,000 Quick lads! A new user! Don't let him get away! -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Bakul, > Initially I used vi and Mail but later switched to e and mh -- may be > because @ Fortune we now had Dave Yost and Rick Kiessig they'd both > worked at Rand and on at least the Rand Editor. https://en.wikipedia.org/wiki/E_Text_Editor isn't RAND's text editor, unfortunately, though I

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Ken, > Paul Vixie wrote: > > prompter is what i was thinking of. Well remembered. I've used that too a long time ago. For quick short emails I prefer the imperative style of giving recipients and subject on the command line rather than interactive of being prompted as that's a bit slower. >

Re: [nmh-workers] Unnecessary dependency on vi???

Hi David, > > sensible-editor(1) that programs can fall back on. > > That Debian package is available (sensible-utils) on Fedora. If a > suitable editor can't be found via VISUAL, EDITOR, etc., it falls back > to nano. It tries $VISUAL . ~/.selected_editor # Maybe run

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Andy, > I generally don't set VISUAL or EDITOR unless I absolutely have to > (e.g. on Ubuntu which defaults to nano) That reminds me: Debian, and Ubuntu, have /usr/bin/editor and sensible-editor(1) that programs can fall back on. What that is can be set system-wide, or per user.

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Paul, > i set VISUAL to /usr/local/bin/jove, Don't forget this is a public mailing list. > why would our build or install dependency list include any editor? Fedora's is changing from an install dependency on /usr/bin/vi to a Suggests one. I haven't checked what the other distributions do.

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Paul, > i thought we were talking about (the fedora equivalent of) > /etc/alternatives, not installed pathname: Nope. > surely the nmh package requirement isn't on a a specific provider of > {/usr}/bin/vi, is it? Yep. Please examine

Re: [nmh-workers] Unnecessary dependency on vi???

Hi Paul, > > An aside: Does any package other than vim provide /usr/bin/vi? I > > think the command might be `dnf provides /usr/bin/vi'. I expect > > it's a bunch of different sized vim-based packages. > > vile is another vi alternative, on all linux distributions, and at > least some of the

Re: [nmh-workers] Unnecessary dependency on vi???

Hi David, > > (I think under debian/ubuntu, the vi dependency would be a > > "suggested" installation, not a requirement.) > > I don't know of a good way to do that in a Fedora RPM spec. I don't > consider mentioning it in the rpm description to be "good". I've been poking about. Here's some

Re: [nmh-workers] Unnecessary dependency on vi???

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

Re: [nmh-workers] [Nmh-workers] nmh on Maildir.

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.

Re: [nmh-workers] [Nmh-workers] show Passing mhl Unknown Options.

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: > >

Re: [nmh-workers] On the other other hand

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

Re: [nmh-workers] On the other other hand

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

Re: [nmh-workers] [Nmh-workers] Third release candidate for 1.7.1 is now available

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 .

Re: [nmh-workers] [Nmh-workers] show Passing mhl Unknown Options.

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

Re: [Nmh-workers] Third release candidate for 1.7.1 is now available

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

Re: [Nmh-workers] Blockers for 1.7.1.

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,

Re: [Nmh-workers] Blockers for 1.7.1.

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

Re: [Nmh-workers] Using different transport methods depending on receipient

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

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

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

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

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

[Nmh-workers] Valgrind Suppression.

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

Re: [Nmh-workers] C++

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

[Nmh-workers] Sequence Notation Torture.

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

[Nmh-workers] nmh on Maildir.

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

[Nmh-workers] Go versus Rust.

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

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

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. --

[Nmh-workers] Blockers for 1.7.1.

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

<    1   2   3   4   5   6   7   8   9   10   >