RE: [xml] A few Windows specific issues

Hi there.

    This one is the reapparition of the old "I used a windows
    filename and something broke"
    My suggestion is to get a Windows path converter to convert
    Windows filename to valid URI or URI-References and have it
    plugged in a couple of critical places in libxml to avoid
    such problem for good. "All" I need it that small piece
    of Windows filename parsing :-). Any volunteers ?

Okay, I have tested a bit. 

Both xmllint and xsltproc accept all combinations of native path
specifications and their mutations I could think of. All that without
any changes to the code. Here are few examples:

  C:\dir\file.xml          Absolute path.
  C:/dir/file.xml          Absolute path slashed.
  ..\dir\file.xml          Relative path.
  ../dir/file.xml          Relative path slashed.
  \\server\share\file.xml  UNC path.
  file:///C:/dir/file.xml  Sort of URI starting with three slashes.

Any combination of these can be passed to xmllint and xsltproc without
problems. You can even mix slashes with backslashes in most cases. If
these utilities don't support the native path specification format, what
does? The fact is, as Mark said, the MS C runtime accepts a slash and a
backslash as a valid path element delimiter. I think there is no bug to

Now let us observe what else came out. The following does not work from
the command line:


The third of the above does not work at all. The first two report an
error, but fire up the program registered to handle files of type XML,
which then finds the file. This means, assuming the 'file.xml' exists,
you see this:

  C:\> xmllint file://c|/dir/file.xml
  warning: failed to load external 
           entity "file://c|/dir/file.xml"

and while you read it, Internet Explorer pops up and loads the specified
XML file. Since xmlint does not use Win32 Shell API, it must be fopen().
Xmllint calls fopen(), and fopen() launches Internet Explorer on the
specified file, reporting an error back to xmllint.

One day, when I get kids, someone shall ask:
  "Igorson, what would you like to be when you grow up?"
And my offspring shall answer: 
  "Ehmm... I would like to work for a company which neither uses nor
supports Microsoft Windows in any way."

Okay, now. Daniel, Passing native paths on the command line works. This
means, you don't need those conversion functions anymore, or do you plan
to allow Win32 native path specifications in XML files?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]