> ## Content Index
> Fetch the complete content index at: https://blogs.remobjects.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Working with Paths in Elements RTL
- URL: https://blogs.remobjects.com/2019/09/11/working-with-paths-in-elements-rtl/
- Published: 2019-09-11T15:12:43.000Z
- Updated: 2019-09-11T15:13:14.000Z
- Author: marc hoffman
- Tags: #Import 2026-08-17 20:17

[Elements RTL](https://www.elementscompiler.com/elements/rtl?ref=blogs.remobjects.com), 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.

```oxygene
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).