Path (computing)

History

Multics first introduced a hierarchical file system with directories (separated by "") in the mid-1960s.

Around 1970, Unix introduced the slash as its directory separator.

Originally, MS-DOS did not support directories. When adding the feature, using the Unix standard of a slash was not a good option since many existing commands used a slash as the switch prefix (i.e., ). In contrast, Unix uses the dash as the switch prefix. The backslash was ultimately chosen instead for its similarity to the slash and not conflicting with existing commands. This convention continued into Windows. However, some areas of Windows do accept or understand Unix-style slashes also, such as PowerShell.

Summary of systems

Pathing is more a feature of the file system; not the OS or the shell, but this table focuses on OS and shell :(

The following table describes the syntax of paths in notable operating systems:

In programming languages

Most programming languages use the path representation of the underlying system, but some may also be system-independent.

For instance, this C code is system-dependent and may fail on opposing systems:

uxFile = fopen("project/readme.txt", "r") // Fails on Windows
winFile = fopen("C:\\Program Files\\bin\\config.bat", "r") // Fails on Unix

• In Java, the File.separator field stores the system-dependent separator. Some functions preclude the need for the separator entirely. :import java.io.File; import java.nio.file.Path; import java.nio.file.Paths; // ... File file = new File("path" + File.separator + "file.txt"); Path path = Paths.get("path", "file.txt");
• In Python, the module offers system-independent path operations. :from pathlib import Path

with (Path("path") / "to" / "file.txt").open() as open_file: ...

In Unix

Most Unix-like systems use a similar syntax. POSIX allows treating a path beginning with two slashes in an implementation-defined manner, though in other cases systems must treat consecutive slashes as one.

Many applications on Unix-like systems (for example, scp, rcp, and rsync) use resource definitions such as , or URI schemes with the service name (here 'smb'), like .

In macOS

When macOS was being developed, it inherited some pathname choices from Classic Mac OS and the Unix-like NeXTSTEP. The classic Mac OS uses a while Unix and Unix-like systems use a as the path delimiter. As a solution, to preserve compatibility for software and familiarity for users, and to allow disk file systems to be used both by the classic Mac OS and macOS, some portions of macOS convert between colons and slashes in pathnames; for example, the HFS+ file system, from the classic Mac OS, converts colons in file names to slashes and, when reading a directory, converts slashes in filenames to colons, and the Carbon toolkit converts colons in pathnames to slashes and slashes in path names to colons, and converts them back when providing filenames and pathnames to the caller.

In DOS and Windows

DOS and Windows have no single root directory; a root exists for each storage drive, indicated with a drive letter or through UNC.

Directory and file name comparisons are case-insensitive: "test.TXT" would match "Test.txt".

Windows understands the following kinds of paths:

• Local paths, such as .
• Universal naming convention (UNC).
• DOS device paths, such as or . The first, skips path normalization. The second, uses the raw device namespace.

In the Windows API, file I/O functions automatically convert into (except when using the prefix). Unless the prefix is used, paths are limited to the length defined by MAX_PATH. This variable defaulted to 260 characters until Windows 10, when it could be expanded to 32,767.

PowerShell allows slash-interoperability for backwards-compatibility:

PS C:\>Get-Content -Path "C:/path/to/file.txt"

Here is some text within a file

Yen/won character error

Main article: Backslash#Confusion with ¥ and other characters

Japanese and Korean versions of Windows often displayed the '¥' character or the '₩' character instead of the directory separator. This is because while in ANSI codepages, the character at 0x5C was the backslash, and in Japanese and Korean codepages, 0x5C was the yen and won signs, respectively. Therefore, when the character for a backslash was used, other glyphs appeared.

Universal Naming Convention

UNC

The Microsoft Universal Naming Convention (UNC, uniform naming convention, or network path), is a syntax to describe the location of a network resource, such as a shared file, directory, or printer. A UNC path has the general form:

Some Windows interfaces allow or require UNC syntax for WebDAV share access, rather than a URL. The UNC syntax is extended with optional components to denote use of SSL and TCP/IP port number. Thus, the WebDAV URL of becomes .

When viewed remotely, the "SharedFolder" may have a name different from what a program on the server sees when opening "\SharedFolder". Instead, the SharedFolder name consists of an arbitrary name assigned during creation of the share.

Since UNCs start with two backslashes, and the backslash is also used for escape sequences and in regular expressions, cases of leaning toothpick syndrome may arise. An escaped string for a regular expression matching a UNC begins with 8 backslashes because the string and regular expression both require escaping. This can be simplified by using raw strings, such as in C#, in Python, or in Perl.

Notes

References

References

1. "File system formats available in Disk Utility on Mac".
2. Matt Wojciakowski. "Case Sensitivity".
3. Day, Brittany. "Understanding the Linux Filesystem Case Sensitivity Debate".
4. (1965). "A general-purpose file system for secondary storage".
5. (10 February 2014). "Why Windows Uses Backslashes and Everything else Uses Forward Slashes".
6. (24 June 2005). "Why is the DOS path character ""?".
7. (2018-04-09). "File System Basics".
8. "UNC Network Share Access (Windows)".
9. (August 1987). "RSX-11M-PLUS MCR Operations Manual, RSX-11M-PLUS Version 4.0". [[Digital Equipment Corporation]].
10. Herkert, Mark Klause Herman. (December 1985). "Defense Data Network/TOPS-20 Tutorial. An Interactive Computer Program.".
11. Rabe, Bernhard. (2011-06-06). "OpenVMS & DCL on Alpha & VAX".
12. (2025). "VSI OpenVMS User's Manual".
13. (1983). "ProDOS User's Manual". [[Apple Computer]].
14. (February 1986). "The AmigaDOS Manual". Bantam Computer Books.
15. (2015-11-03). "RISC OS PRMs: Volume 2: Chapter 44: Writing a filing system". 3QD Developments Ltd..
16. (May 1988). "Getting Started with Domain/OS". [[Apollo Computer]].
17. (September 1983). "CP/M Operating System Manual". [[Digital Research]].
18. "Introduction to the Shell". OpenAtom OpenHarmony.
19. "exec". OpenAtom OpenHarmony.
20. "Java Development Kit Version 17 API Specification".
21. "os.path — Common pathname manipulations".
22. "UNC Definition".
23. "POSIX pathname resolution specification".
24. "POSIX pathname definition".
25. Chan, Alex. (2021-12-01). "A tale of two path separators".
26. Sanches, Wilfredo. (2000). "The Challenges of Integrating the Unix and Mac OS Environments".
27. De George, Andy. (2022-12-14). "File path formats on Windows systems".
28. Ashcraft, Alvin. (2024-08-28). "Naming Files, Paths, and Namespaces".
29. Ashcraft, Alvin. (2024-07-16). "Maximum Path Length Limitation - Win32 apps".
30. Wheeler, Sean. "about_Path_Syntax - PowerShell".
31. "When is a backslash not a backslash?".
32. (13 October 2021). "DavGetHTTPFromUNCPath function".