-----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/

Reply via email to