Fully resolving path names

Objective: retrieve and store an absolute (or fully-qualified) path name for a file or directory from a user specified string which could be given as absolute, relative to a MATLAB path, relative to the current working directory ('.' or '..'), or relative to a user's directory (~ or ~user).

Builtin functions like EXIST and WHICH do a great job of searching out files that are on the path, hidden in class folders, specified as relative to the current directory, ... but they do not robustly return the full path for generic files (i.e. non-MATLAB user files that may not be on the MATLAB path). WHICH has a somewhat nonsensible behavior of claiming a file that EXIST, DIR, and FOPEN can find does not exist.

The goal is to be able to robustly obtain the absolute path name for a file so that it can be found again even from a different working directory or with a different MATLAB path.

For now my solution is to confirm existence of the file (EXIST) then save both the specified filename and the current working directory. Assuming that the MATLAB path doesn't change, I can cd to the directory, execute FOPEN, and then cd back whenever I need to access the file. Neither clean nor efficient.

Ideally I would like a function absolutePath = resolvePath(filename) that uses the same search criteria as the builtin functions.

Thoughts?

Answer 1

[Ray]

Not a complete solution for all the smart places the builtin's look, but a useful snippet that should work for most user file and directory applications:

function fullpath = resolvePath(filename)
  file=java.io.File(filename);
  if file.isAbsolute()
      fullpath = filename;
  else
      fullpath = char(file.getCanonicalPath());
  end
  if file.exists()
      return
  else
      error('resolvePath:CannotResolve', 'Does not exist or failed to resolve absolute path for %s.', filename);
  end

[Alec Jacobson]

This doesn't seem to work correctly for paths starting with ../ on mac. It always thinks the current directory is ~/Documents

Answer 2

[Jan]

FEX: GetFullPath.

Answer 3

[Jurgen vL]

Using the python os submodule to get an absolute path:

string(py.os.path.realpath(py.os.path.expanduser(<PATH>)))

The above does not yet check if the absolute path exists. Requires python to be installed and discoverable by MATLAB.

[Alec Jacobson]

First call is slow (launching python?) but subsequent calls are fast and this works for paths starting with / , ~/ and ../

Answer 4

[Andrea Barletta]

I had a similar question and I realized it was easier than I thought. I am sharing my code, just in case (no Java or Python used). I should work on all versions >=R2017b.

function absPath = getAbsPath(obj)

getAbsFolderPath = @(y) string(unique(arrayfun(@(x) x.folder, dir(y), 'UniformOutput', false)));
getAbsFilePath = @(y) string(arrayfun(@(x) fullfile(x.folder, x.name), dir(y), 'UniformOutput', false));

if isfolder(obj)
    absPath = getAbsFolderPath(obj);
elseif isfile(obj)
    absPath = getAbsFilePath(obj);
else
    error('The specified object does not exist.');
end

[Walter Roberson]

Note: the folder property of dir() needs R2016b or later.

[Tom Hawkins]

If you want to get the absolute path of something you know is a folder,

getfield(dir(targetFolder), 'folder')

seems to be a one-line version, at least for paths on local drives on R2018b, Windows 10.

[Andrea Barletta]

Yes, that could indeed be used to replace this line:

getAbsFolderPath = @(y) string(unique(arrayfun(@(x) x.folder, dir(y), 'UniformOutput', false)));

However, the remaining part of the code needs to be there to address files other than folders, as per original request. Furthermore, dot notation is to be preferred to getfield according to the official documentation:

"As an alternative to getfield, use dot notation, value = S.field. Dot notation is typically more efficient."

[Walter Roberson]

it has only been a small number of releases that we have been able to use dot field indexing on the result of a function call.

[Andrea Barletta]

Unfortunately I am unable to test my function on any version older than R2018a, for which I can confirm it works. I have some (unconfirmed) confidence it also works in version R2017b as I wrote in my first post. It will certainly not work on previous versions as some dependencies would be missing (e.g. isfolder).

[Walter Roberson]

However, the remaining part of the code needs to be there to address files other than folders, as per original request. Furthermore, dot notation is to be preferred to getfield according to the official documentation:

Yes, dot notation is preferred. However, Tom Hawkin's version using getfield() can be implemented in a single call without making any assignments, and assignments used to be strictly necessary in order to use dot notation without using getfield() or subsref().

Starting in R2019b, you can use dot notation to index the result of a function call, such as

dir('.').folder

However, dir() of a folder returns entries for the folder and its parents and everything directly inside of the folder, so dir('.').folder would be certain to return an expansion into a minimum of two (identical) entries. If you were passing the result into something, you would probably get complaints about too many inputs. For example

>> length(dir('.').folder)
Error using length
Too many input arguments.

getfield(dir('.'), 'folder') would return only a single copy, but using dot notation as "preferred" would have to deal with the multiple copies, such as

struct('folder', unique({dir('.').folder})).folder

But more likely

First = @(varargin) varargin{1};
First(dir('.').folder)

Though of course you could also do

FirstFolder = @(dinfo) dinfo(1).folder;
FirstFolder(dir('.'))

Answer 5

[Walter Roberson]

Pull off the file-name part. cd() to what remains. pwd() to find out the directory name. cd() back.

[Ray]

Thanks for the input. Your suggestion does solve some of the issues. However, if the input string is relative to the current working directory, one of the MATLAB paths, or one of the other nooks and crannies that EXIST and other builtins check, your solution will fail because there is no where to CD.

[Kyle Kaja]

Once you have the file name part stripped off, here's a simple way to do the directory changes:

resolvedPath = cd(cd(dirPath));

This takes advantage of the fact that cd() returns the previous working directory, therefore avoiding the need to call pwd().

Answer 6

[Gavriel Aminov]

Please examine my File Exchange contribution: Convert local to remote (global) filename.