-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XSpec Ant target does not work with files or directories containing space #13
Comments
I presume we can’t just use ${xspec-files} as the value of |
That doesn't work. From my understanding ${...} expands properties, i.e. strings. |
Why don't we have the xspec-runner run on itself and load the xspec files dynamically using a collection? I've always found using the xslt task in ant is a bit awkward, and I usually use the java task to call saxon directly, then have my xslt driver files load what they need. |
Do you mean the XSLT 3 collection() function? |
@dmj Sorry this is so late! Yes, I normally use the collection() function and iterate through content in the XSLT itself. |
Easy to reproduce, so should be easy to fix, I hope. |
…emove one problem from the situation.
We (@HelenaSabel , @martindholmes , and I) found a partial fix for this — use a BLAH-separated, instead of space-separated, list of files, and then tokenize on BLAH. (Where in this case we chose U+241D as BLAH, but it does not really matter, any string that is guaranteed not to occur in a filepath will do.) BUT after having done this we just bumped into the problem further down the line, in the xspec build file itself. (MH to post details soon.) So we think we should pause this ticket and ask XSpec folks if there is a way to do this. (To run XSpec when there is a space in the path.) |
What we determined was that when we call the ant target xspec.xspec in the XSpec ant build file, whatever variety of escaped or unescaped path we present to it, the call fails. The calls are done by generating our own ant file with antcall elements like this, for example:
and the result is |
@martindholmes, @sydb, and @HelenaSabel think this is potentially a big time-sink, since we don't quite know where to look to solve the problem, and we have more important things to focus on right now, so we're going to defer this for the moment. |
The pathconvert task does not URI-encode the file names. One could argue that this is not a bug, but just a limitation of the Ant target that is acceptable.
The text was updated successfully, but these errors were encountered: