ken wrote:
it's somewhat shocking how far the code gets when handed this invocation:
mhshow -file /tmp
short answer: way into the depths of show_content_aux(), where
it finally hits "internal error (3)". this leaves tempfiles unremoved,
and, in my case, the tty is no longer in fully-cooked mode, and needs
to be reset.
Hm. I get:
mhshow: error reading from /tmp: Is a directory
(content text/plain in message /tmp)
do i recall correctly that you're using a mac?
And everything seems ok. A quick system call trace reveals that the
error is coming back from read(). I suspect there are a lot of things
that are falling back to a "mangled" message being a single text/plain
part. Can you just open directory files without any special magic on
your system? It would be interesting to see the logic flow.
yes, open(2) on linux is perfectly happy opening a directory. but
that's not the problem. (your open() is succeeding too, right?)
i'd be curious to know which read() failed for you. the first read on
the opened directory is in read_more(), at m_getfld.c:443. strace
shows me that that read() is returning EISDIR, but that the fread()
returns 0. i have no clue why it might do that, but i also see that
there's no error checking on that fread(), so i guess that's not the
one that's failing for you.
paul
Personally, I'm a little reluctant to require that all -file arguments
are vanilla files; I could see where it being a named pipe, for example,
might be useful.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers