Elements RTL, our (optional) cross-platform abstraction library, provides a rich API for working with filenames and and paths.

For one, it replicates the System.IO.Path class from .NET, which provides many APIs for parsing and manipulating paths, and it also has a Url class that has can be used for file-based URLs and offers many options to working with the path portion of an URL. On Cocoa, this class also seamlessly casts to NSURL, which many of the system APIs use for file access — which is very helpful.

But more conveniently, Elements RTL introduces a whole bunch of methods on the String type itself that can be used to work with strings that contain file names and file paths. For example, simply calling MyString.PathExtension will give back you the file extension, if any (including the "." — consistently on all platforms).

Many of these String APIs come in three flavor, a regular one and one with Windows or Unix in the name respectively.

With Elements RTL being targeted for multi-platform use, the default versions of all string APIs will work correctly with paths on the current platform — that means on Unix-based systems they will use forward slashes, while in Windows they will use backslash, and so forth.

When writing regular code that deals with files on the local system, you will usually want to use these versions of the APIs, and you can be assured they will "just work", regardless on what system your code runs on, Windows, Mac, Linux or elsewhere:

  • LastPathComponent
  • LastPathComponentWithoutExtension
  • PathWithoutExtension
  • PathExtension
  • ParentDirectory
  • AppendPath
  • IsAbsolutePath
  • ToPathRelativeToFolder
  • ToPathWithLocalFolderPrefixIfRelative

Most of these methods or properties rely on what the proper directory separator for the platform is, and will do the right thing.

Now, sometimes you have the opposite scenario: you have paths that match a particular platform, and you need to work with them regardless of what platform your code is running on. For example, you might be reading a file format that contains Windows-style paths (such as Elements' own .elements and .sln project files). Or maybe you connect to a remote server via SSH from Windows, and need to deal with Unix-style paths as they are valid on the remote.

var lPath := SSH.GetRootPath
var lSubFolder := lPath.AppendUnixPath("sub", "folder");
SSH.cd(lSubFolder);

That's where the path APIs with Windows and Unix in the name come in. These will assume the path they are called on conforms to the specified platform, regardless of what platform the code is running on.

  • LastUnixPathComponent
  • LastWindowsPathComponent
  • LastUnixPathComponentWithoutExtension
  • LastWindowsPathComponentWithoutExtension
  • AppendUnixPath
  • AppendWindowsPath
  • IsAbsoluteUnixPath
  • IsAbsoluteWindowsPath

Finally, there's APIs to convert paths from one style to the other. Of course, whether and how that makes sense depends a lot on the context, but it actually more common that one would think.

Convert a local path format to a well-known format (if necessary):

  • ToWindowsPath
  • ToUnixPath

Convert from a well-known format to the local format (if necessary).

  • ToPlatformPathFromWindowsPath
  • ToPlatformPathFromUnixPath

And finally, convert from on well-known path format to the other:

  • ToUnixPathFromWindowsPath
  • ToWindowsPathFromUnixPath

Of course any of the first four of these methods might be a no-op on a given platform. (for example, ToPlatformPathFromUnixPath has nothing to do on Unix, nor does ToUnixPath). But using them consistently ensures that code will port cleanly to Windows (or vice versa).