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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers