Subject: RE: [xsl] Windows Batchfile calling Saxon - Confusion of / and \|
From: "Kerry, Richard" <richard.kerry@xxxxxxxxxxx>
Date: Thu, 11 Oct 2007 16:25:10 +0100
> So the person > who brought up the issue could have just used forward slashes, > right? No. That would be me. And the reason I couldn't is pretty much as indicated in the later part of Andrew's posting (below). When I was generating full paths in my batch file I was generating them using '/' as Saxon was only happy with those (for multiple documents using document()). When I finished doing the initial 'experimental' phase of my task I needed to change the batch file so it no longer had the original full path hard-coded in it and could be run from anywhere. Then I found that Saxon wouldn't understand '.' as meaning the current directory. So I used Windows' 'cd' command to get the current directory and assigned the result to a variable (using 'set'), which I then passed into the stylesheet for this purpose. It was at this point that the problem arose. So, as Andrew indicates, this is a problem specifically with paths that are generated by Windows itself and have not been entered manually, and so there is no reasonable alternative that I can see to using the '=' option in 'set' that allows strings to be substituted. Helpfully, Richard. > -----Original Message----- > From: Houghton,Andrew [mailto:houghtoa@xxxxxxxx] > Sent: 11 October 2007 15:48 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: RE: [xsl] Windows Batchfile calling Saxon - > Confusion of / and \ > > > From: Paul Spencer [mailto:xml-dev-list@xxxxxxxxxxxxxx] > > Sent: 11 October, 2007 09:49 > > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > > Subject: RE: [xsl] Windows Batchfile calling Saxon - > > Confusion of / and \ > > > > Michael Kay wrote: > > > > > There are unfortunately many products that accept Windows > > filenames in > > > contexts where the standards mandate a URI. I have been resisting > > > doing this, because I think standards conformance should outweigh > > > minor convenience. However, I've been dithering a little on > > this one > > > recently, because once everyone breaks a standard in the > same way, > > > they establish a new de facto standard. > > > > Keep resisting Michael! One of the annoying things about XML > > Spy is that it creates filenames with backslashes where there > > should be a URI. Then, of course, it accepts them. So anyone > > who doesn't test with another processor is likely to release > > stuff that doesn't work. Some of us rely on tools that do it > > properly for our testing. > > The original problem that raised this issue has to do with how the > Windows command processor works, which prefers to generate file > names with backward slashes. As Michael indicated, the Windows > API that is used by every application will generally accept file > names with either forward or backward slashes. So the person > who brought up the issue could have just used forward slashes, > right? > > It's not that simple when you type commands into the Windows command > processor or create a batch command file and run it. Lets take a > simple example. Here is a Windows command that when run from the > command prompt will list the fully qualified names of all the files > in a directory: > > for %f in (C:/foo/*) do @echo %~ff > > Notice that the directory specification is given with forward > slashes, but if you put some file in the foo directory named > file1.txt and file2.txt, then you will get the following > output: > > C:\foo\file1.txt > C:\foo\file2.txt > > Windows did accept the original directory specification with > forward slashes, but because the file specification was manipulated > by the command processor it reverted back to backward slashes. This > might have been part of the reason why the person raised the issue, > by not being aware of what the Windows command processor was doing > and the construction rules for the HTTP file: scheme. > > As Michael previously indicated, if you try to open the file > C:\foo\bar.txt or C:/foo/bar.txt the correct thing will happen. In > addition, you can also send the Windows API the corresponding HTTP > file: scheme versions, file:///C:/foo/bar.txt or > file:///C:\foo\bar.txt. > > The Windows API is slightly schizophrenic, in that you can even > mix forward and backward slashes for the file specification. So > C:\foo/bar.txt or C:/foo\bar.txt will work, as well as, > file:///C:\foo/bar.txt or file:///C:/foo\bar.txt. > > RFC 1738, section 3.10 indicates that the file URI's path is > separated by forward slashes. So being a Windows user of Saxon, > I personally don't have any issues with Saxon strictly conforming > to the RFC. However, it should be possible to detect that Saxon > is running under Windows and relax the conformance to local OS > practice and user's expectations. > > If it is decided that Saxon should not change it behavior under > Windows, then there is a simple work around that I mentioned in > my prior post and perhaps the issue and work around could be > mentioned in the Saxon documentation for Windows users. > > > Andy.