Re: [9fans] upas : without acme : possible?

Re: [9fans] upas : without acme : possible?

[sl]

> is that "mail" you mention similar to "mailx" under unix-like systems?
> the problem is one of not wanting a captive user-interface to the
> mailing sub-system.

On Plan 9, 'mail' is a shell script that invokes either nedmail(1) or
marshal(1), depending on the flags it consumes.

The nedmail program is nearly identical, from a user interface
standpoint, to the mail command that shipped with the 8th edition of
Research UNIX.  It remains part of the same (though evolved) e-mail
processing system, upas.

Ned is a little different than mailx(1), but it's probably just about
what you're looking for.

Plan 9's mail system itself (upas) relies heavily upon upasfs(4),
filter(1), and simple rc scripts, which make even complex tasks
like custom spam filtering and automatic mailbox management
trivial.

sl

Re: [9fans] upas : without acme : possible?

[Mayuresh Kathe]

On 2018-11-30 09:02 AM, sl@9front.org wrote:
>> is that "mail" you mention similar to "mailx" under unix-like systems?
>> the problem is one of not wanting a captive user-interface to the
>> mailing sub-system.
>
> On Plan 9, 'mail' is a shell script that invokes either nedmail(1) or
> marshal(1), depending on the flags it consumes.
>
> The nedmail program is nearly identical, from a user interface
> standpoint, to the mail command that shipped with the 8th edition of
> Research UNIX.  It remains part of the same (though evolved) e-mail
> processing system, upas.
>
> Ned is a little different than mailx(1), but it's probably just about
> what you're looking for.
>
> Plan 9's mail system itself (upas) relies heavily upon upasfs(4),
> filter(1), and simple rc scripts, which make even complex tasks
> like custom spam filtering and automatic mailbox management
> trivial.

i was looking for a non-captive user-interface email client like "mh" by
rand corporation. i guess i'll either have to learn to use acme with
upas or write my own "mh" replacement for plan 9.

~mayuresh

[9fans] non-captive user-interfaces: some ramblings; Plan 9 possibilities

[Ethan Gardener]

On Fri, Nov 30, 2018, at 3:53 AM, Mayuresh Kathe wrote:
> non-captive user-interface

There's a term for what I've been looking for!  Lately I've been wanting to implement basically everything with non-captive interfaces.  I've been having trouble designing the programs because of my poor memory and other issues.

On the other hand, now I realise that a program I've heard of repeatedly over the last 20 years has the type of interface I'm looking for, I'm wondering why I didn't use it, if there's something wrong with the concept, something I felt but couldn't quantify.  I think maybe a general malaise when using the unix command line, probably initially due to trying to learn by reading init scripts of Red Hat 5.2; a source of brain damage almost on a par with BASIC!  Poor documentation in the 90s and tremendous option bloat obviously contributed to my malaise.  I did try hard at times.

I think netpbm was what finally put me off.  Inconsistent cryptic options, view-updating only by manual means, state-keeping also manual; I think those were the problems.  Ah, not netpbm; Plan 9's image tools are far more consistent, but the other two problems remain.  I guess both are worse in editing (text or images) than in mail.

I'm thinking of a two-pane view, one being a REPL of some sort, the other a display of what you're editing, obviously keeping state, and having an undo facility.  Obviously different display programs for text or images.  This could actually be scripted in Plan 9, especially in 9front where rio's text files are writable.  A minor catch is that you want the filters to operate on the displayed data rather than stdio.  This could be worked around by piping, or by a clever shell inserting redirects if none are specified.  (A wrapper around rc could do it.)  The display programs could (probably should) handle the case of `prog <dispfile >dispfile`.  Now I'm wondering if, when editing text, all output on stdout should go into the displayed text.  I guess that's reasonable, there is always undo, but I'm running out of functioning brain cells, lol.

[9fans] MH port

[Lyndon Nerenberg]

Mayuresh Kathe writes:

> i was looking for a non-captive user-interface email client like "mh" by
> rand corporation. i guess i'll either have to learn to use acme with
> upas or write my own "mh" replacement for plan 9.

A year-or-so ago I started working on my own version of MH, forked
from a then current nmh.  One of the goals for the version I'm doing
is to have a native (as much as is possible) Plan9 build; one that
gets along with upasfs and the plumber as much as possible.

So far most of the work has been cleaning up the code base. E.g.
ripping out all the GNU auto* build nonsense, and getting the code
to compile cleanly in a pure ANSI C environment.

Once that's finished it should be relatively straight forward to
add basic APE build support.  This is a couple of months out yet,
based on my current rate of progress :-(

--lyndon

Re: [9fans] MH port

[Lyndon Nerenberg]

Mayuresh Kathe writes:

> just so that i know, are you targeting plan9 users for your version
> of 'mh'? if yes, will they be interested in migrating away from the
> way they are working currently, i.e. with acme and upas?

Yes, and no.

Yes, in that I intend this MH to fully integrate with the Plan9
environment (upas, plumber, factotum) when run there.  That will
come with time.  The first step is to get the existing code building
and running, with a very basic inc(1) interface that pulls from the
user's inbox (just like with UNIX).

No, in that there will never be a "one true MUA" any more than there
is *any* "one true X" for any value of X.  On Plan9[1] I am constantly
moving back and forth between nedmail, acme Mail, and a basket
full of my own programs, depending on the task at hand.  The upas
filesystem interface makes the latter a breeze to implement.

MH is just another nugget in that basket of tools.

--lyndon

[1] Not just Plan9.  On UNIX systems I can't keep count of the number
of MUAs, MSAs, and the like I use, and almost always in parallel.  Again,
which tool I use is dictated by what I'm trying to accomplish at the
moment.

Re: [9fans] upas : without acme : possible?

[sl]

I ended up writing a ned-alike that is just a shell script:

http://plan9.stanleylieber.com/rc/mother

This is what I actually use.

sl

Re: [9fans] upas : without acme : possible?

[Mayuresh Kathe]

On 2018-11-30 10:10 AM, sl@9front.org wrote:
> It's not clear why you think the interface provided by upasfs(4) is
> captive, or why you insist acme needs to be involved at all. I'm
> writing this message with nedmail/marshal, connected to Plan 9 in a
> plain SSH terminal session -> OpenBSD -> drawterm -G. No GUI or
> terminal frills or frippery is involved.

wow, i'll definitely check out nedmail/marshal.
btw, i don't think the interface provided by upasfs might be captive,
it's the mail/mailx interface which is so damn painful (from a usage
philosophy perspective).

~mayuresh

Re: [9fans] upas : without acme : possible?

[sl]

It's not clear why you think the interface provided by upasfs(4) is captive, or why you insist acme needs to be involved at all. I'm writing this message with nedmail/marshal, connected to Plan 9 in a plain SSH terminal session -> OpenBSD -> drawterm -G. No GUI or terminal frills or frippery is involved.

sl

Re: [9fans] upas : without acme : possible?

[Steve Simon]

you can send mail with the mail command, just like traditional mailers.

reading mail: i use the same tool but envoked from faces(1) - right click on the face of the person who sent the mail to read the message.

people tend to be very impressed with faces to this day. great interface.

-Steve


> On 29 Nov 2018, at 3:58 pm, Kurt H Maier <khm@sciops.net> wrote:
> 
>> On Thu, Nov 29, 2018 at 08:27:09PM +0530, Mayuresh Kathe wrote:
>> 
>> is that "mail" you mention similar to "mailx" under unix-like systems?
>> the problem is one of not wanting a captive user-interface to the 
>> mailing sub-system.
>> 
> 
> You're looking for nedmail(1), I think.  Hopefully sl will chime in;
> he's got a pile of scripts revolving around this idea.
> 
> khm

Re: [9fans] upas : without acme : possible?

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 283 bytes --]

Re: [9fans] upas : without acme : possible?

[Kurt H Maier]

On Thu, Nov 29, 2018 at 08:27:09PM +0530, Mayuresh Kathe wrote:
>
> is that "mail" you mention similar to "mailx" under unix-like systems?
> the problem is one of not wanting a captive user-interface to the
> mailing sub-system.
>

You're looking for nedmail(1), I think.  Hopefully sl will chime in;
he's got a pile of scripts revolving around this idea.

khm

Re: [9fans] upas : without acme : possible?

[Mayuresh Kathe]

On 2018-11-29 08:04 PM, Dan Cross wrote:
> On Thu, Nov 29, 2018 at 8:45 AM Mayuresh Kathe <mayuresh@kathe.in>
> wrote:
>
>> hello,
>>
>> is it possible to use "upas" without relying on acme?
>> it might be uncomfortable (relatively speaking), but is it possible?
>
> Yes. This is quite reasonable. To a first order approximation, `upas`
> is a mail transfer agent, for moving mail around across a network (or
> just into a mailbox on a local system) while Acme provides a mail
> client (a "mail user agent") based on a filesystem.
>
> There used to be, and probably still is, another mail client just
> called 'mail' that could be used to read and send mail, but that is
> also independent of upas.

is that "mail" you mention similar to "mailx" under unix-like systems?
the problem is one of not wanting a captive user-interface to the
mailing sub-system.

i really hate moving out of the text console and away from the
command-line.

yes, i really don't mind having multiple consoles around instead of the
unixy way of switching terminals using ctrl+fn keys.

thanks,

~mayuresh

Re: [9fans] upas : without acme : possible?

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Thu, Nov 29, 2018 at 8:45 AM Mayuresh Kathe <mayuresh@kathe.in> wrote:

> hello,
>
> is it possible to use "upas" without relying on acme?
> it might be uncomfortable (relatively speaking), but is it possible?
>

Yes. This is quite reasonable. To a first order approximation, `upas` is a
mail transfer agent, for moving mail around across a network (or just into
a mailbox on a local system) while Acme provides a mail client (a "mail
user agent") based on a filesystem.

There used to be, and probably still is, another mail client just called
'mail' that could be used to read and send mail, but that is also
independent of upas.

Hope that helps.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1060 bytes --]

Re: [9fans] upas : without acme : possible?

[Alexander Sychev]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Hi,

Sure, no problem. Upas exports a filesystem, you can read it :-)
Although I use plan9port version of upas with acme and my client 'amail',
sometimes I use 9p to read, for example, a raw message body to send it to
spam analitics.
But reading messages is uncomfortable, it is true.

On Thu, Nov 29, 2018 at 4:47 PM Mayuresh Kathe <mayuresh@kathe.in> wrote:

> hello,
>
> is it possible to use "upas" without relying on acme?
> it might be uncomfortable (relatively speaking), but is it possible?
>
> ~mayuresh
>
>
>

--
Best regards,
  Alexander

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

[9fans] upas : without acme : possible?

[Mayuresh Kathe]

hello,

is it possible to use "upas" without relying on acme?
it might be uncomfortable (relatively speaking), but is it possible?

~mayuresh