xsltproc from libxstl-1.1.15-1

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

xsltproc from libxstl-1.1.15-1

Thomas Berger-2
-----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/