[GTALUG] Live and die by the command line WAS Re: git questions

[Christopher Browne]

On 6 March 2015 at 14:00, Giles Orr <gilesorr at gmail.com> wrote:
> On 6 March 2015 at 13:24, Loui Chang <louipc.ist at gmail.com> wrote:
>> On Fri 06 Mar 2015 10:52 -0500, Giles Orr wrote:
>>> I live and die by the command line, and I'm fairly sure all of this
>>> can be achieved without installing extra tools ...
>> [SNIP]
>>
>> What do you use for mail on the command line?
>
> Ah, you're making a perfectly reasonable assumption that I can't live
> up to.  I don't browse the web from the CLI and I don't do mail from
> the CLI.  I'm trying to think of other exceptions - I'm sure there are
> one or two - but I guess those are the major ones.
>
> I used mutt for a year or so (a decade ago), but configuring it always
> required a huge amount of reading, editing text files, cursing, and
> rinse and repeat.  While vim is arguably the same, I found the rewards
> greater - so I continue to use vim but these days I use Gmail's web
> interface rather than mutt.

I used nmh <http://www.nongnu.org/nmh/> for a decently long time;
got tugged into Gmail's orbit, but I still have a fair bit of toolset for
working with MH, and found it usually a rewarding way of accessing
email.

Google recently added archiving of mail as part of their "Takeout"
service (which is a Big Deal to me; it means that I can consider it
My Data that I can take away whenever I want to do so), and I
downloaded my mail as a giant Mbox file for the first time
yesterday.  I'm going to want to split it into smaller pieces and
archive it, ideally in a fashion that integrates somewhat with my
legacy MH mail.  It's no good to have it as one gigantic piece.
I'm musing things to do with it.  Ideas include:
a) Split into a message per file, just as with MH, and run a
    big batch job each time that stows them in some stable
    fashion (e.g. - so that when I pull the same messages
    NEXT month, they don't just get duplicated)
b) Split into messages, and use a DBMS-based mail storage
    system.  Musing on <http://archiveopteryx.org/>

A desirable result is to have the resulting mail stored in a
fashion that lends itself to running "git commit" against the
email repository.  a) might lead to too many files, but seems
otherwise largely desirable.  b) mightn't be all that nice to
"git commit", but is interesting in its own ways.

I tried out uzbl for cli-controlled web browsing; I wound
up struggling against it way too much.

-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"