15.1.3 Unix and Mac OS Paths

► |  | The Racket Reference

1 | Language Model
2 | Notation for Documentation
3 | Syntactic Forms
4 | Datatypes
5 | Structures
6 | Classes and Objects
7 | Units
8 | Contracts
9 | Pattern Matching
10 | Control Flow
11 | Concurrency and Parallelism
12 | Macros
13 | Input and Output
14 | Reflection and Security
15 | Operating System
16 | Memory Management
17 | Unsafe Operations
18 | Running Racket
| Bibliography
| Index

► | 15 | Operating System

15.1 | Paths
15.2 | Filesystem
15.3 | Networking
15.4 | Processes
15.5 | Logging
15.6 | Time
15.7 | Environment Variables
15.8 | Environment and Runtime Information
15.9 | Command-Line Parsing
15.10 | Additional Operating System Functions

▼ | 15.1 | Paths

15.1.1 | Manipulating Paths
15.1.2 | More Path Utilities
15.1.3 | Unix and Mac OS Paths
15.1.4 | Windows Paths

► | 15.1.3 | Unix and Mac OS Paths

15.1.3.1 | Unix Path Representation

On this page:

15.1.3.1`` Unix Path Representation

top contents ← prev up next →

##### 15.1.3`` Unix and Mac OS Paths🔗ℹ

In a path on Unix and Mac OS, a / separates elements of the path, . as a path element always means the directory indicated by preceding path, and .. as a path element always means the parent of the directory indicated by the preceding path. A leading ~ in a path is not treated specially, but expand-user-path can be used to convert a leading ~ element to a user-specific directory. No other character or byte has a special meaning within a path. Multiple adjacent / are equivalent to a single / (i.e., they act as a single path separator).

A path root is always /. A path starting with / is an absolute, complete path, and a path starting with any other character is a relative path.

Any pathname that ends with a / syntactically refers to a directory, as does any path whose last element is . or ...

A Unix and Mac OS path is cleansed by replacing multiple adjacent /s with a single /.

For (bytes->path-element bstr), bstr must not contain any /, otherwise the exn:fail:contract exception is raised. The result of (path-element->bytes path) or (path-element->string path) is always the same as the result of (path->bytes path) and (path->string path). Since that is not the case for other platforms, however, path-element->bytes and path-element->string should be used when converting individual path elements.

On Mac OS, Finder aliases are zero-length files.

##### 15.1.3.1`` Unix Path Representation🔗ℹ

A path on Unix and Mac OS is natively a byte string. For presentation to users and for other string-based operations, a path is converted to/from a string using the current locale’s encoding with ? (encoding) or #\uFFFD (decoding) in place of errors. Beware that the encoding may not accommodate all possible paths as distinct strings.

top contents ← prev up next →