Mon 23 Jan 2017 05:11:14 PM UTC, comment #9:
FTR, Matlab r2017a prerelease on Win7 64 bit:
Is fullpath only supported on Linux?
I could try to install the prerelease on Linux as well and try there.
|
Mon 23 Jan 2017 04:28:32 PM UTC, comment #8:
This definitely illustrates why we only try to follow the documented behavior because Matlab changes fairly often (for a mature piece of software). I think Octave is good enough as is. Maybe if they re-define their behavior again in R2017 or R2018 we can follow it then.
|
Mon 23 Jan 2017 10:03:28 AM UTC, comment #7:
It seems Matlab ~2015 introduced a new fullpath which still has bugs. Eg
>>fullpath('C:\','\')
ans=C:\\
Surprisingly unprofessional.
|
Mon 23 Jan 2017 09:45:38 AM UTC, comment #6:
Ah ha:
>>version
ans=9.1.0.441655 (R2016b)
>>fullfile('/usr','..','bin')
and=\usr\..\bin
So it looks like they've fixed this 'bug', which is unfortunate.
|
Mon 23 Jan 2017 07:25:20 AM UTC, comment #5:
On Windows:
>> version
ans =
8.3.0.532 (R2014a)
>> fullfile('/usr/../bin/')
ans =
\bin\
>> fullfile('/usr','..','bin/')
ans =
\bin\
>> fullfile('/usr','..','bin')
ans =
\bin
>>
Paths don't have to really exist, this is just a strings manipulation.
|
Sun 22 Jan 2017 04:50:43 PM UTC, comment #4:
Another thing to check is whether Matlab is just collapsing ".." or if it is also resolving symbolic links. I.e., does it do the full job of canonicalize_file_name or just the relative path part.
Also, does it only collapse ".." when it is in the middle of a file name? What about at the end or beginning? And what does it do with things like "./foo" or "~/foo"?
As long as Octave concatenates the parts and returns a valid filename, then I don't really see a bug here.
|
Sun 22 Jan 2017 03:15:01 PM UTC, comment #3:
We treat inconsistency with documented Matlab behavior as a bug. Their documentation seems reasonably clear about what is supposed to happen, and that's why I need the results of
from a recent version of Matlab. This looks to be a Matlab bug, not an Octave one.
|
Sun 22 Jan 2017 12:42:39 PM UTC, comment #2:
Well, whether you treat this as a bug depends on whether you treat being inconsistent with Matlab bugs as a bug.
If not then feel free to close. Having '..' in the path doesn't seem to cause any problems anyway.
|
Sat 21 Jan 2017 10:50:46 PM UTC, comment #1:
fullfile() is used to create a valid path from multiple components, not for changing relative references to absolute ones. The use case, from the Octave documentation, is
If your interest is in removing relative references, try the canonicalize_file_name() function. On a Linux machine,
The documentation reference from The Mathworks is at http://www.mathworks.com/help/matlab/ref/fullfile.html. In particular, see the last sentence of the paragraph below.
This implies that Matlab is not even following its own documentation. Octave usually doesn't bother to follow undocumented behavior because it could change at any time.
It would be helpful, since you have access to Matlab, to try the following test:
What does that return?
|
Sat 21 Jan 2017 08:29:29 AM UTC, original submission:
Octave:
>> fullfile('/one/../two')
ans = /one/../two
Matlab:
>> fullfile('/one/../two')
ans = /two
Which seems to be the whole point of fullfile really.
|