1. join_path
- Posted by mattlewis (admin) Feb 22, 2013
- 1301 views
I was using join_path in std/filesys.e, and found what I think is probably a bug. Basically, I did (on Windows, obviously):
-- expected foo = `C:\foo\bar\baz` -- actual foo = `\C:\foo\bar\baz` foo = join_path( { `C:\foo\bar`, "baz" } )
Is this a bug, or am I missing something about this function?
Matt
2. Re: join_path
- Posted by ghaberek (admin) Feb 22, 2013
- 1276 views
I was using join_path in std/filesys.e, and found what I think is probably a bug. Basically, I did (on Windows, obviously):
-- expected foo = `C:\foo\bar\baz` -- actual foo = `\C:\foo\bar\baz` foo = join_path( { `C:\foo\bar`, "baz" } )
Is this a bug, or am I missing something about this function?
The documentation says...
-- fname would be "\\usr\\home\\john\\hello.txt" on Windows
So it's operating as described (that is the output you received) but knowledge of Windows vs Unix path styles should be involved in the output, otherwise you're stuck doing this...
foo = "C:" & join_path( { `\foo\bar`, "baz" } ) -- foo = `C:\foo\bar\baz`
-Greg
3. Re: join_path
- Posted by gbonvehi Feb 23, 2013
- 1236 views
I was using join_path in std/filesys.e, and found what I think is probably a bug. Basically, I did (on Windows, obviously):
-- expected foo = `C:\foo\bar\baz` -- actual foo = `\C:\foo\bar\baz` foo = join_path( { `C:\foo\bar`, "baz" } )
Is this a bug, or am I missing something about this function?
Matt
As Greg quoted, it seems not to be a bug but the documented behavior. However, I wouldn't expect it to add the leading directory separator char as for example, if you're using relative paths, you wouldn't want it to be added.
Normally standard libraries concatenate the strings using the fsystem's directory separator char.
-- win foo = join_path( { `C:\foo\bar`, "baz" } ) -- foo = `C:\foo\bar\baz` foo = join_path( { `foo\bar`, "baz" } ) -- foo = `foo\bar\baz` -- *nix foo = join_path( { `/foo/bar`, "baz" } ) -- foo = `/foo/bar/baz` foo = join_path( { `foo/bar`, "baz" } ) -- foo = `foo/bar/baz`
4. Re: join_path
- Posted by mattlewis (admin) Feb 25, 2013
- 1170 views
As Greg quoted, it seems not to be a bug but the documented behavior. However, I wouldn't expect it to add the leading directory separator char as for example, if you're using relative paths, you wouldn't want it to be added.
I think it's a bit of a grey area. It seems that the function expects each subsequence to be a single element in a path, with no slashes. I was basically using this as a way to presumably join a couple of paths without wanting to duplicate slashes or bother checking for that myself.
Matt
5. Re: join_path
- Posted by gbonvehi Feb 25, 2013
- 1161 views
I think it's a bit of a grey area. It seems that the function expects each subsequence to be a single element in a path, with no slashes. I was basically using this as a way to presumably join a couple of paths without wanting to duplicate slashes or bother checking for that myself.
I understand, but I still think this would be a problem, consider the following example.
include std/io.e include std/filesys.e constant READDIR = "../somedir" integer fn sequence filename filename = "test" fn = open(join_path({READDIR, filename}), "w") -- This would result in /../somedir which won't be what you expected.
Edit:
Well, it's documented so it's kind of the expected behavior according to the docs so I won't discuss further.
I still think that it shouldn't add the leading separator as it invalidates all relative paths using this function and makes them absolute.
Edit2: Changing line 1987 in hg's version of filesys.e to
if match(":", elem) = 0 then -- Or, as we know that there cannot be more than a : and must be before any directory separator -- if i > 1 or match(":",elem) = 0 then
instead of
if elem[$] != ':' then
would solve the problem you're currently having as it only avoid appending the directory separator char if the sequence ends in : but not contains it.
Here is the corresponding test
test_equal("join_path #3", "C:\\Users\\john\\hello.txt", join_path({ "C:\\Users", "\\john\\", "hello.txt" }))
Edit 3..:
Here's a patch with the changes: http://openeuphoria.org/pastey/205.wc
It also includes a fix for "canonical_path() #12:" test that fails in 64-bit when running in 32-bit as there are two Program Files shortened (PROGRA~1 = Program Files, PROGRA~2 = Program Files (x86)) and the canonical_path points to the second one.
I pointed it to Common Files instead which we have the guarantee that there's only one at the time.