Re: [Nmh-workers] A non-complaint

[David Levine]

Ralph wrote:

> Ken's pointed out the <meta> wasn't in the original message;  were you
> seeing that in Chrome's view of the source?  It might add it based on
> the default it chose.

Something else added it along the way.  As Ken noted later,
it's not in the message in the raw mailing list archive.

> Ken said the HTML default was Windows-1252; it seems surprising
> Windows was ever a default.  I thought it was ISO-8859-1

Right, per RFC 2616 §3.4.1.

> up until HTML 5 which explicitly states it's UTF-8 along with a
> system for guessing based on the byte values.

RFC 5987?

> I've no Chrome to test with, but how about something like
> 
>     exec 42<%F && google-chrome /dev/fd/42

Oddly, that doesn't work (consistently):  the chrome window
remains blank.  If I copy to a plain file in /tmp, then
chrome renders the copy as expected:

    $ exec 42<3.1.html
    $ ls -lo /dev/fd/
    total 0
    lrwx------. 1 levine 64 Aug  7 08:36 0 -> /dev/pts/4
    lrwx------. 1 levine 64 Aug  7 08:36 1 -> /dev/pts/4
    lrwx------. 1 levine 64 Aug  7 08:36 2 -> /dev/pts/4
    lr-x------. 1 levine 64 Aug  7 08:36 3 -> /proc/4371/fd/
    lr-x------. 1 levine 64 Aug  7 08:36 42 -> /tmp/3.1.html
    $ google-chrome /dev/fd/42
    Created new window in existing browser session.  # blank
    $ file -L /dev/fd/42
    /dev/fd/42: HTML document, UTF-8 Unicode text, with very long lines
    $ cp /dev/fd/42 /tmp/42
    $ google-chrome /tmp/42
    Created new window in existing browser session.  # OK!

chrome normally follows symlinks, so I don't think that's the
culprit here.  Even stranger:  it will read the fd, following
the symlink, if there isn't a previously running chrome process.
If there is, it just shows "file:///dev/fd/42" in the location
bar and the blank page.

firefox reads the fd.  Though I tried (quickly) and it tripped
over a previously running process, even with -new-window,
-new-instance, and/or -private.  But, if used only for this
purpose, it would work.  In that case, it wouldn't be necessary
to hold on to the fd.

> It doesn't matter then if Chrome exits and %F is removed by nmh before
> the child Chrome reads the file since the open file description keeps
> the reference count bumped and the inode around.  The downside is it
> stays until child-chrome exits too.

Wouldn't it stay until the forked mhshow process exits?  In
any case, I don't see that as a problem.

David