Hi, > Good point. I'm not too sure either; it depends what the current > needs are...
So my email above had this part to it, that made it through the list back to me. > Content-Type: message/external-body; access-type="url"; > url="dict://dict.org/d:yagni:foldoc" > > Content-Type: text/plain > Content-ID: <3814.150314751...@orac.inputplus.co.uk> But I couldn't get it to mhshow or mhstore even with my `nmh-access-url: curl -sSL' profile entry. strace showed curl(1) was fetching the content and storing it in its stdout, that was a temporary file set up by nmh beforehand. But nmh was just seeking to the start of it before unlinking; no read of the file occurred. This uncommited fixes it. This one case anyway. diff --git uip/mhparse.c uip/mhparse.c index 71405616..0fadf786 100644 --- uip/mhparse.c +++ uip/mhparse.c @@ -2897,7 +2897,7 @@ openURL (CT ct, char **file) fseeko(ce->ce_fp, 0, SEEK_SET); *file = ce->ce_file; - return fd; + return fileno(ce->ce_fp); } I did notice earlier that openURL() was different from most of the other calls of openExternal() in handling its `OK' return value; it returned fd instead of ce_fp's fileno(). Here fd is -1, but ce_fp is valid and returning its fileno instead gives the dictionary entry as part of the email. I don't know if this is the right fix. Frankly, after staring at functions that take a pointer to a struct with an FILE pointer and a filename, and also a couple of pointers to return a filename and a file descriptor, I'm unclear if the duplicates are meant to always be in sync, whether the file descriptor is always the of the FILE pointer if that's not NULL, or if sometimes the two filenames should differ... There's other messes I was already in the middle of trying to sort out, so I'm giving up on this one. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers