Re: [xslt] create Directory bug in libxslt for W32
- From: Andreas Beppler <beppler arano de>
- To: xslt gnome org
- Subject: Re: [xslt] create Directory bug in libxslt for W32
- Date: Fri, 11 Feb 2005 09:27:32 +0100
Hello,
just to go back to the original question of thomas for a short moment:
What can I do to get windows binaries of xsltproc without the bug? Is
any further information needed to correct the problem?
Thanks for any help, Andreas
Aleksey Gurtovoy writes:
Daniel Veillard writes:
> On Tue, Nov 30, 2004 at 03:10:38PM -0600, Aleksey Gurtovoy wrote:
> > Thomas Fischer writes:
> > > Hi folks,
> > > i found a bug in libxslt and Daniel Veillard told me, that's
> > > a win only bug and he can't help :o<
> > >
> > > The Bug occurs, when i try to create a directory via command
> > > line parameter --output (like "xsltproc -o does_not_exist/res >
> > > ...")
> > > or via <exslt:document href="does_not_exist/res"
> > >
> > > Anybody knows a workaround or patch for this problem?
> >
> > See the attachments for the latter (against the current CVS).
>
> I do not understand the first patch nor the associated
> side effects. On windows the file path separator is '\' why is this
> wrong and need to be removed.
I agree that the patch is a little controversial, but only due to the
fact
that 'xmlParserGetDirectory' is used to extract directory paths from
both
URI/URLs _and_ file system paths. For the former the running platform
is
irrelevant; for the latter it's not (obviously). I'm not that
familiar with
the libxslt/libxml2 codebase to be able to say in how many cases when > a
function is passed a 'filename' argument it actually _is_ a native
filesystem path (as opposite to a URL), but I assume that at least
some
of them are. Of course you're in much better position to answer this.
In any case, my take on the issue is that, ideally, all current calls
to 'xmlParserGetDirectory' should become calls to either
'xmlParserGetURIDirectory' or 'xmlParserGetFileDirectory' (both
currently
non-existent), the latter differing from the former in that it would
respect the running platform's conventions.
Does it make sense to you?
> Moving the stat() remapping to the place where it is used makes
> sense
> to me, so that one will be applied, thanks,
You're welcome!
--
Dipl.-Phys. Andreas Beppler
ARANO GmbH
Hauptstraße 10
D-35579 Wetzlar (Steindorf)
e-mail: beppler arano de
Telephone: +49 6441 210 21-15
Fax: +49 6441 210 21-25
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]