GNOME Bugzilla – Bug 331290
--path option doesn't work as expected
Last modified: 2006-02-20 10:36:32 UTC
I have to use the --path option in one of my projects. It works perfectly for xsltproc but not for xmllint. There it doesn't work as expected. To show you, which issues occur, you could checkout a copy of http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/ and run ./autogen.sh && configure && fakeroot make distcheck In the last step of make distcheck, the check-local target from the Makefile(.am) is called. This target runs: xmllint --noout --path ..:. <file>.xml inside the _build directory and fails for every file. A similar command for xsltproc works. To show the issue in a small example, I will add a small archive containg the same situation. test.xml _build _build/example.dtd Change to the _build directory. The expected result is, that [host:_build]$ xmllint --noout --path .:.. test.xml or at least [host:_build]$ xmllint --noout --path .:.. ../test.xml works. If you need more onfo, please let me know. Regards, Daniel
Created attachment 59412 [details] A sample test case. The archive contains a simple example to reproduce the issue.
The path option further shows the same bug as described in http://bugzilla.gnome.org/show_bug.cgi?id=331779.
You're suggesting to look in paths . and .. , while your resource is in _build No surprize it can't find it. If you actually give it the right path to look for it *does* find it, tested with the released last version : paphio:~/tmp/test -> cat test.xml <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "/usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd" [ <!ENTITY % _example SYSTEM "example.dtd"> %_example; ]> <article> <title>title</title> <sect1> <title>example</title> <para>test &example;</para> </sect1> </article> paphio:~/tmp/test -> ls -l _build total 4 -rw-r--r-- 1 veillard www 30 Feb 15 17:11 example.dtd paphio:~/tmp/test -> xmllint --noout --path ".:_build" test.xml paphio:~/tmp/test -> xmllint --noout --path ". _build" test.xml paphio:~/tmp/test -> the second run also prove comment #2 is bogus too. I don't see any bug there, all seems to work fine, and the code used by xmllint and xsltproc for this is exactly the same except for the the name of the function. I think I lost 30mn dealing with your two last bogus bugs, could you check a bit better before rushing onto bugzilla in the future ? thanks, Daniel
(In reply to comment #3) > You're suggesting to look in paths . and .. , while your resource is in _build > No surprize it can't find it. If you actually give it the right path to look > for it *does* find it, tested with the released last version : The target is run inside the _build directory. So --path ". .." contains exactly the right paths to look for resources. > paphio:~/tmp/test -> xmllint --noout --path ".:_build" test.xml That's wrong. You have to test inside _build and not in $(top_srcdir). Therefor I reopened the bug. > I think I lost 30mn dealing with your two last bogus bugs, could you check > a bit better before rushing onto bugzilla in the future ? no comment Still thanks.
Here the full output. dl@leidi:~/test/empty/test/_build$ xmllint --noout --path ".:.." --valid ../test.xml ../test.xml:6: I/O error : failed to load external entity "../example.dtd" %_example; ^ %_example; ^ dl@leidi:~/test/empty/test/_build$
After doing some more research it seems, it only throws these errors but still works: read(4, "<?xml version=\"1.0\"?>\n<!DOCTYPE "..., 16384) = 6202 read(4, "", 8192) = 0 _llseek(4, 0, [6202], SEEK_CUR) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 read(4, "<?xml version=\"1.0\"?>\n<!DOCTYPE "..., 4096) = 4096 read(4, "SIS//DTD XML Exchange Table Mode"..., 4096) = 2106 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7f94000, 4096) = 0 stat64("../example.dtd", 0xbfba67a0) = -1 ENOENT (No such file or directory) stat64("../example.dtd", 0xbfba66d4) = -1 ENOENT (No such file or directory) stat64("../example.dtd", 0xbfba66d4) = -1 ENOENT (No such file or directory) stat64("../example.dtd", 0xbfba66d4) = -1 ENOENT (No such file or directory) write(2, "../test.xml:6: ", 15) = 15 write(2, "I/O ", 4) = 4 write(2, "error : ", 8) = 8 write(2, "failed to load external entity \""..., 48) = 48 write(2, "\t%_example;\n", 12) = 12 write(2, "\t ^\n", 13) = 13 write(2, " %_example; \n", 13) = 13 write(2, " ^\n", 13) = 13 stat64("./example.dtd", {st_mode=S_IFREG|0644, st_size=30, ...}) = 0 stat64("./example.dtd", {st_mode=S_IFREG|0644, st_size=30, ...}) = 0 open("./example.dtd", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=30, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c2d000 read(4, "\n\t<!ENTITY example \"foobar\">\n\n", 131072) = 30 read(4, "", 131072) = 0 _llseek(4, 0, [30], SEEK_CUR) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 read(4, "\n\t<!ENTITY example \"foobar\">\n\n", 131072) = 30 read(4, "", 131072) = 0 close(4) = 0 munmap(0xb7c2d000, 131072) = 0 stat64("/usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd", {st_mode=S_IFREG|0644, st_size=5796, ...}) = 0 stat64("/usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd", {st_mode=S_IFREG|0644, st_size=5796, ...}) = 0 stat64("/usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd", {st_mode=S_IFREG|0644, st_size=5796, ...}) = 0 open("/usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd", O_RDONLY) = 4 It first throws the error and then uses ./example.dtd. Maybe this could be changed, so it only throws the error, if the entitiy really can't be found.
Haha ... You are using --valid ! This does change things quite a bit, in that case not being able to fetch an external entity becomes and error and is not a warning, xmllint and xsltproc (as XSLT loads external entities and does not validate) then will just emit a warning, and that warning is ignored in the case of -path is used . But with --valid, then the parser operates in validating more, it emits an error that is issued, this explain why I could not reproduce the problem. None of your initial reports indicated that, only #5 did ! I changed xmllint --path handling to not raise the error, but I don't think --path is a good idea in general it forces a non-conformant processing in the way URI references are generated, it's tool specific and not a good idea from an infrastructure point of view. paphio:~/tmp/test/_build -> ~/XML/xmllint --noout --path ".:.." --valid test.xml../test.xml:11: element title: validity error : No declaration for attribute foo of element title <title foo="bar">title</title> ^ paphio:~/tmp/test/_build -> with an extra attribute added to show that errors are still reported Daniel
Thanks. > None of your initial reports indicated that, only #5 did ! JFTR: My original report told everything. Also where to run xmllint, where to expect files, which options to use ... But I honestly did not run strace. > I changed xmllint --path handling to not raise the error, > but I don't think --path is a good idea in general it forces a non-conformant Maybe you could change he error to a warning, which is raised, if an external entity can only be fetched if the --path option is used. Sounds pretty naive, but IMO you understand, what I mean. I've prepared an update for the xmllint manpage. Have a look at the following attachement.
Created attachment 59720 [details] [review] Update to manpage The patch contains changes to the manpage fixing: - explanation for the --path option - markup (completed e.g. the usage of the <acronym> tag) - make it more more compatible with the man-page howto (section titles) It's xmllint-clean. One thing: The ENVIRONMENT section contains all environemt variables mentioned in the manpage. But two variables misses an explanation. Maybe you could add them.
> JFTR: My original report told everything. Also where to run xmllint, where to > expect files, which options to use ... But I honestly did not run strace. F... I really missed, that I used the --valid option. No idea why. Really, really sorry. I thought, that I provided all necessary infos.
Created attachment 59724 [details] [review] Patch for the xmllint manpage. IMHO a better path for the xmllint manpage.
Cool, thanks for the man page improvements ! Applied and commited. Changing the way the core parser reacts to missing entities can't really be done on a case by case basis, this is driven by the normative behaviour defined by the specification. That should not be changed, Daniel
FWIW, Daniel, you forgot to apply the changes to the .html file in cvs. Same applies to xsltproc manual changes.
Hum, there is no rule to build xmllint.html from xmllint.xml in Makefile.am, that's why ... Daniel