According to David Adams: > Congratulations on getting to the bottom of this; it solves a few mysterious > reports of difficulties with external parsing reported to the mailing list > in the last couple of years.
Yeah, that's what I figured. I'm not on the list anymore because of time constraints, but I remember a few of these reports coming up before, and expect there may be more. Now, those of you still on the list will know what the cause is, and how to respond. I haven't actually tested my patch I posted yesterday, but until I (or someone) does, and applies it to the code base, and a new release goes out, I expect the lack of a meaningful "Can't execute" message will continue to be a problem. I'm sorry I didn't look more carefully at the code when we switched from popen() to the pipe(), fork() and execv() we're using now. > Could I clarify one point with you? You wrote: > > > The problem was that the script began with "#!/usr/local/bin/perl", > > which worked fine on the older system, but not on the newer one. > > was this simply because the Perl binary was in a different location on your > newer system, or because there is a general problem on the newer system with > this method of specifying the executable to run the script (which would be > serious indeed!)? The former, not the latter. Handling of "#!(some path)" in executable scripts is built right into the kernel of Linux and most UNIX systems, and is unlikely to go away or break in any current system. The problem was entirely on our own systems. This was on the Manitoba Unix User Group's web server (http://www.muug.mb.ca/). On the old system, there was a symlink to /usr/bin/perl in /usr/local/bin, so the script worked with the original heading. On the newer system, we've done away with these extra symlinks, but I forgot to check and change the heading of the script. (We actually had several perl scripts that needed changing, but someone else was looking after all of those, and left just the htdig setup to me.) > I think the moral is that users must take great care in correctly > configuring their external parser(s), and must check that they work from the > command line. I couldn't agree more. Meaningful error messages can help a lot, but there's no substitute for great care and manual testing. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ ht://Dig general mailing list: <[EMAIL PROTECTED]> ht://Dig FAQ: http://htdig.sourceforge.net/FAQ.html List information (subscribe/unsubscribe, etc.) https://lists.sourceforge.net/lists/listinfo/htdig-general
