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(_dot_)1503147515(_dot_)2(_at_)orac(_dot_)inputplus(_dot_)co(_dot_)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(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers