Re: [Nmh-workers] Nabbing /usr/bin Space.

Hi Mark, > Or were you thinking that /usr/bin/nmh would have functionality that's > not available in any other executable, rather than just being a > front-end, and there wouldn't be a stand-alone program 'mmdfunburst'? Yes, new exclusive functions rather than a veneer front-end. -- Cheers,

Re: [Nmh-workers] Nabbing /usr/bin Space.

In the message dated: Thu, 25 May 2017 19:49:43 +0100, The pithy ruminations from Ralph Corderoy on were: => Hi Mark, => => > Do you mean /usr/bin/mh as a sub-directory? => => No, a new executable, e.g. `mh foo', `mh bar'. OK, got it. => > I'd think that "unpackf" (or "burstmmdf") might be

Re: [Nmh-workers] Nabbing /usr/bin Space.

Hi Mark, > Do you mean /usr/bin/mh as a sub-directory? No, a new executable, e.g. `mh foo', `mh bar'. > I'd think that "unpackf" (or "burstmmdf") might be better off in > /usr/libexec/nmh. Seems off to bury a command a user would want to run off-PATH over there? -- Cheers, Ralph.

Re: [Nmh-workers] Nabbing /usr/bin Space.

In the message dated: Thu, 25 May 2017 18:57:42 +0100, The pithy ruminations from Ralph Corderoy on <[Nmh-workers] Nabbing /usr/bin Space.> were: => Hi, => => It's the "nmh" project, used in URLs, mailing lists, etc., but MH is => still prevalent in command names, ~/.mh_profile, etc., which is

[Nmh-workers] Nabbing /usr/bin Space.

Hi, It's the "nmh" project, used in URLs, mailing lists, etc., but MH is still prevalent in command names, ~/.mh_profile, etc., which is fine. We've lots of user commands, and have created ones that seem to potentially tread on others' toes a bit with their genericness, e.g. new(1). We've also

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Ken Hornstein writes: >>No, it always was in band - the 4-SOH sequence was searched for in all >>lines of the message, and SOH has always been a possible character in >>e-mail. Just even more unlikely years ago than it is now. > > You know, I _was_ going to disagree here but