, [Fwd: xsltproc from libxstl-1.1.15-1]

, [Fwd: xsltproc from libxstl-1.1.15-1]

[Thomas Berger]

Woah Gerrit,
WDYDWMLF (what did you do with my line feeds)?

o.k. since the libxml maintainer choose to forward my struggles
to the list, here comes the readable form:

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


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

Re:

[Gerrit P. Haase]

Thomas Berger wrote:

> Woah Gerrit,
> WDYDWMLF (what did you do with my line feeds)?

Oops, it is my broken Delphi mailer, everytime it gets an email
in UTF-8 encoding it sends out in the same encoding, however it
doesn't do it right,  I have no idea how to teach this stupid
little software to always use the default charset or how to
convince it that a linebreak in UTF-8 is still al linebreak.

I'm sorry.


Gerrit
-- 
=^..^=

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