Hi Christian,
Sorry in my example I should've used a relative path because that's what I'm processing most of the time and I use it to resolve to an absolute path. However I'm working with file sets for which the directory at that time may not yet exist.
Hmm it's in the spec. Didn't know about that.
Coming from Java I would say that this is not what I expect. A java.io.File object may represent both a file or a dir and when getting its absolute path it doesn't attach a slash. File:resolve-path mixes up file existence with path handling.
Guess, I will keep the 'fix' in a wrapper function then. Personally I don't see the rationale for this in the spec.
--Marc
On Tue, Oct 28, 2014 at 3:03 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
this behavior is compliant with the current spec [1]: The file:resolve-path function is non-deterministic, because its result is dependent on both the existence of the targeted file and the current working directory. If you want to address non-existing directories, you will indeed have to add the directory separator.
By looking at your example…
file:resolve-path('F:/tmp') => F:\tmp\
…I was wondering why you use file:resolve-path at all, and why you don't simply take your original path string for further operations?
Best, Christian
[1] http://expath.org/spec/file#fn.resolve-path
On Tue, Oct 28, 2014 at 10:31 AM, Marc van Grootel marc.van.grootel@gmail.com wrote:
Hi,
For a while I wasn't aware, then I noticed it and then I got annoyed by it. It's not a big issue but it does require extra code to work around this, in my opinion, annoying behaviour.
When using file:resolve-path it depends if the file exists or not. The output is different.
Say I have an existing directory F:\tmp then
file:resolve-path('F:/tmp') => F:\tmp\
However, when I have a path that points to a non-existing directory (or file, we cannot know!)
file:resolve-path('F:/tmp/not-exists') => F:/tmp/not-exists
Notice the absence of a slash. I guess the assumption that is made is that in the future this will refer to a file and not a directory.
The same behaviour occurs with file:path-to-uri(), and file:base-dir() also returns a path with a trailing slash.
I think that this is annoying, or let's say at least, inconsistent behaviour and had me add code that defensively strips of trailing slash. I cannot rely on file:resolve-path results because if a directory doesn't exist it has no slash at the end, and if it does it has and sometimes I don't want to check for existence at that point. When combining paths I tend to use string-join($parts,'/') and having slash at the end of URL's and filesystem paths doesn't feel right so I always strip them off.
Hope I didn't sound too grumpy ;-) Opinions? Guess, changing it would trip up a lot of existing path handling code.
--Marc