Re: [Nmh-workers] mhshow -file /tmp (!)

[Paul Fox]

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
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers
 > 


=----------------------
paul fox, address@hidden (arlington, ma)