Mail Archives: cygwin/2005/11/28/10:35:15
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gerrit, I'm using xsltproc from .bat-Files under cmd/command and so far had no problems with Backslashes for paths on the command line (at least when the last component is divided by a proper slash from the actual file name). >>> Using libxml 20622, libxslt 10115-CVS1027 and libexslt 812-CVS1027 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 <<< Thus (ini2bat.xsl contains <xsl:import href="lib/readconf.xsl"/> with >set -H2k=G:\hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xml yields: Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" warning: failed to load external entity "lib/readconf.xsl" compilation error: file G:\hans2k/util/confxml/ini2bat.xsl line 7 element import xsl:import : unable to load lib/readconf.xsl and with >set -H2k=G:/hans2k >xsltproc --load-trace --noout %-H2k%/util/confxml/ini2bat.xsl %-H2k%/config/empty.xml yields: Loaded URL="G:/hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G:///hans2k/util/confxml/lib/readconf.xsl" ID="(null)" ... The previous version worked o.k. (for me): >>> Using libxml 20620, libxslt 10114-CVS1011 and libexslt 812-CVS1011 xsltproc was compiled against libxml 20620, libxslt 10114 and libexslt 812 libxslt 10114 was compiled against libxml 20620 libexslt 812 was compiled against libxml 20620 <<< Loaded URL="G:\hans2k/util/confxml/ini2bat.xsl" ID="(null)" Loaded URL="G%3A%5Chans2k/util/confxml/lib/readconf.xsl" ID="(null)" ... At the moment I cannot see any possibilty to "slashify" my file paths prior to calling xsltproc. unfortunately I got lost studying the sources. In uri.c of libxml is no special path processing for CYGWIN, but there hasn't, since cygwin takes care of paths? My guess is, that test on "\" in IS_UNWISE cancels processing of those paths in several routines in uri.c thus it would be wise to (re?)introduce some CYGWIN-specific normalization in xmlCanonicPath in uri.c . However the comment "This really need to be cleaned up by someone with a Windows box" for the win32-specific normalization is not really encouraging... Do you have any ideas? simple testcase below: - ---------- foo.xsl -------------- <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:import href="bar.xsl"/> </xsl:stylesheet> - --------------------------------- - ---------- bar.xsl ----------------- <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> </xsl:stylesheet> - ------------------------------------ call as xsltproc --load-trace u:/bla/foo.xsl u:/bla/foo.xsl vs. xsltproc --load-trace u:\bla/foo.xsl u:/bla/foo.xsl Greetings Thomas Berger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDhjeGENVh3bB0lwMRAmvgAKCnhu9gGaw329cj+cC/3vyMDpdaOACff6oz G5WZgEcRuq8awMThZCxt8TE= =su83 -----END PGP SIGNATURE-----
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -