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

[Ralph Corderoy]

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, Ralph.
https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[bergman]

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 better off in
=> > /usr/libexec/nmh.  
=> 
=> Seems off to bury a command a user would want to run off-PATH over
=> there?

Not really, if:
/usr/bin/nmh mmdfunburst 

really does
exec(/usr/libexec/nmh/mmdfunburst)

Wasn't your intention to stop polluting /usr/bin with more
executables...otherwise, where would you keep 'mmdfunburst'?

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'?

Mark

PS.
I do like the idea of a command named "*funburst".

=> 
=> -- 
=> Cheers, Ralph.
=> https://plus.google.com/+RalphCorderoy
=> 
=> ___
=> Nmh-workers mailing list
=> Nmh-workers@nongnu.org
=> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=> 
-- 
Mark BergmanBiker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 
Stagehand
'94 Yamaha GTS1000A^1 2015 Aprilia 
Caponord
berg...@panix.com  
https://www.flickr.com/photos/rmsppu

http://wwwkeys.pgp.net:11371/pks/lookup?op=get=bergman%40panix.com

I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman 

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ralph Corderoy]

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.
https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[bergman]

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 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 got functionality to pension off like MMDF
=> mailboxes.  I was wondering if we should nab /usr/bin/mh whilst it's

Do you mean /usr/bin/mh as a sub-directory? That's verboten in the Linux
Filesystem Hierarchy Standard.

=> still available.  This lets us have sub-commands for the more obscure
=> tasks in the future, e.g. converting a mailbox from MMDF to something
=> else, without further polluting /usr/bin.

I'd think that "unpackf" (or "burstmmdf") might be better off in 
/usr/libexec/nmh.


Or did you mean

/usr/bin/mh
/usr/bin/nmh

as executables? If so, I'd imagine that they'd function somewhat like svn:

with no arguments, they bring up a high-level help/usage message,
very similar to 'man nmh' (maybe even exec(man nmh))


with arguments consisting of existing commands, they'd exec() the [n]mh 
command:

/usr/bin/nmh inc
/usr/bin/nmh show -noshowproc last +inbox

Kind of training wheels for the teeming masses who are just starting to use 
nmh. :)

=> 
=> I say still available, that's based on a list of `*mh' files in Debian's
=> stable's packages.
=> 
https://packages.debian.org/search?searchon=contents=mh=path=stable=any
=> 
=> -- 
=> Cheers, Ralph.
=> https://plus.google.com/+RalphCorderoy
=> 
=> 
-- 
Mark BergmanBiker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 
Stagehand
'94 Yamaha GTS1000A^1 2015 Aprilia 
Caponord
berg...@panix.com  
https://www.flickr.com/photos/rmsppu

http://wwwkeys.pgp.net:11371/pks/lookup?op=get=bergman%40panix.com

I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman 

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ralph Corderoy]

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 got functionality to pension off like MMDF
mailboxes.  I was wondering if we should nab /usr/bin/mh whilst it's
still available.  This lets us have sub-commands for the more obscure
tasks in the future, e.g. converting a mailbox from MMDF to something
else, without further polluting /usr/bin.

I say still available, that's based on a list of `*mh' files in Debian's
stable's packages.
https://packages.debian.org/search?searchon=contents=mh=path=stable=any

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Fairbairn]

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 Robert is, as he almost
> always is, 100% correct.  4-SOH is not valid in an email HEADER
> (mostly), but it is certainly valid in a message BODY, and this goes all
> the way back to RFC 822.  There were some minor changes along the way
> (RFC 822 said NULs were valid, but RFC 2822 said they were not), but SOH
> has always been a valid character in email bodies; MIME didn't change
> this one bit.

Well, gosh. I stand corrected; I should have read RFC 822 before
making that decision (back whenever it was). I can only assume
that I had based it on what I thought was allowed in mail before
RFC822. If I had been designing SMTP I wouldn’t have allowed all
128 ASCII characters. The first 8 would have been forbidden, for
a start. Then we could have used ETX to mark the end of the
body, and not ., which can legitimately appear in a
text message. But I wasn’t, so they weren’t and we couldn’t. Oh
well.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers