Talk:Path (computing)

Slashes

In the Windows APIs and the DOS APIs since v2.0 (DOS v1.x didn't have directories) both "/" and "\" are valid path separators.

The problem is that command.com & cmd.exe (and in general: most command lines) treat "/" as an option prefix (I think this had originally something to do with CP/M compatibility) and because of that you can't always use "/" as a path separator there (you can when putting quotes around the path).

http://blogs.msdn.com/oldnewthing/archive/2004/03/16/90448.aspx#91398

And some interesting posts from a discussion on the Python mailing list about this: http://mail.python.org/pipermail/python-list/2003-September/185204.html http://mail.python.org/pipermail/python-list/2003-September/185212.html http://mail.python.org/pipermail/python-list/2003-September/185217.html http://mail.python.org/pipermail/python-list/2003-September/185202.html — Preceding unsigned comment added by JanC (talk • contribs) 11:59, 8 May 2005 (UTC)

This isn't true on Vista, and I would imagine not on Windows 7, either. —Preceding unsigned comment added by 24.211.30.90 (talk) 23:22, 7 January 2010 (UTC)

Ok, great detective work. But why are we starting the section MS-DOS/Microsoft Windows style by talking about the exception instead of the rule? Why don't we start off mentioning the general rule that \ is used more often in Windows, and then mention the fun fact that you can often also use /? It'd also be great to switch the order in the table in this manner too.

--Qwerty0 (talk) 00:57, 3 October 2011 (UTC)

If I remember this correctly (it's been a while), the APIs in DOS (at least later releases) would recognize forward slashes as directory separators. It is the application code interprets the forward slash as an option-prefix, and all of the standard utilities bundled with DOS (and Windows and OS/2 for that matter) do just that. But there is nothing that prevents a developer from using a different character as an option-prefix (UNIX utilities ported to DOS typically retain the UNIX-style "-" option-prefix) allowing forward slashes to be treated as just another part of a path string, where DOS would treat them as directory separators. Shamino (talk) 20:07, 21 June 2018 (UTC)

Unix conventions

PATH is the name of a variable which $PATH refers to. So the text should be PATH and not $PATH. See env (Unix). --DLL 17:09, 24 March 2006 (UTC)

ARC paths

If someone could add some information on the ARC paths used in boot.ini on WinNT systems please do. Dustin 17:56, 5 January 2007 (UTC)

Japan and Korea

Why do Japanese and Korean versions of Windows use different directory separators? --Abdull 07:59, 11 April 2007 (UTC)

The backslash article says the usage of the yen and won character is due to different symbols in the Japanese and Korean versions of the ISO/IEC 646 character sets - so is it some kind of mojibake issue...? --Abdull 16:42, 15 April 2007 (UTC)

I just added some clarification. Check and edit it please.—Gyopi 04:30, 28 August 2007 (UTC)

MacOS

How does Mac OS distinuish between a drive and a directory? Is Letters:BankManager a file in the Letters directory, or a file in the root of the Letters drive? Jgharston (talk) 22:22, 14 August 2010 (UTC)

Before Mac OS X, I'm not positive, but I don't think paths were actually used to uniquely refer to files, so it might just be ambiguous. Classic Mac OS used "aliases" to refer to files, which was more like a direct reference based on a unique, automatically-assigned ID. Kind of like UNIX inodes. Note that this use of the word "alias" is slightly different from alias files that you can make in the Finder. As for OS X, there are UNIX paths under the hood, and drives have mount points like any other *nix. OS X has aliases too; various programs will use either aliases or paths or some weird combination to refer to files. (The preferred convention is for GUI apps to use aliases for open documents, but programs ported from other OSes might not fully respect this convention.) Any use of classic-style, colon-separated paths under OS X is for legacy reasons; it's mostly been phased out. 69.116.252.118 (talk) 16:43, 1 July 2012 (UTC)

it's the drive. Classic Mac OS had no environment variables so the relative path would be :Letters:BankManager (equiv. to ./Letters/BankManager) http://stackoverflow.com/questions/13298434/colon-appears-as-forward-slash-when-creating-file-name

In the Mac world, apps using Mac (that is, not UNIX) APIs are strongly encouraged to not store or use paths unless absolutely necessary. Most of the time, users select files using the GUI (file-open, file-save, drag/drop, etc.). The system presents the application with an object representing the file's location. The specific object presented has changed over the years, but it contains enough information to uniquely identify that file. It is this object that should be manipulated and stored persistently. The object contains a path string among other data, but that path is used as a last resort, for when the other information isn't usable. This allows the object to reference the correct file even if that file is moved or renamed. In early versions of MacOS, the object used two integers - a device ID and a file ID (equivalent to an inode number). In modern versions, it contains quite a lot of different representations in order to handle a wide variety of different kinds of file locations. I don't know of any other operating system that works this way. Shamino (talk) 19:58, 21 June 2018 (UTC)

Table

I have whacked "(including macOS)" into the table after "Unix-like OS", because I think otherwise it's pretty hard to see where macOS fits in. Without this it'd be tempting for readers to think they should refer to Classic Mac. Anyway, macOS should be explicitly present in the table, either as I have it, or as a footnote to the table, or as a separate row all for itself. —DIV (1.129.105.93 (talk) 13:50, 11 July 2019 (UTC))

This site http://www.westwind.com/reference/OS-X/paths.html indicates that macOS merits a row all for itself, because it doesn't quite match Unix. —DIV (1.129.105.93 (talk) 13:54, 11 July 2019 (UTC))

Filepath

The term "filepath" needs to redirect to this article. Grozo (talk) 21:33, 3 June 2018 (UTC)

I agree. It seems like Filepath already redirects to this article. I also think the term "filepath" should be included in the article. Somerandomuser (talk) 21:55, 1 January 2021 (UTC)

Filepath Misconceptions

The rest of the article should incorporate the fact that a path ending in a trailing slash (/ or \) does not represent a directory. But rather represents all the files within that directory. Since Windows 2000+ has some posix compliance (reference needed), it also follows this principle.

 c:\bobby\apples\.
 /bobby/apples/.

above are both obvious paths that are identifiable as directories.

 c:\bobby\apples
 /bobby/apples

above are files that may or may not resolve to paths.

 c:\bobby\apples\
 /bobby/apples/

above are much less documented. Even in posix environments. But they represent the files of the directory. Not the directory itself. Notice the below:

 dirname "/bobby/apples" -> /bobby
 dirname "/bobby/apples/" -> /bobby
 dirname "/bobby/apples/." -> /bobby/apples (bingo! That represents a path!)

dirname is a posix command which returns a directory from a given path. It does not resolve with a filesystem if paths pointing to files (including trailing slash only) as being directories. Note: In both file systems, directories are files with special attributes.

TamusJRoyce (talk) 04:30, 1 March 2019 (UTC)

Do you have a source for this? I have never heard of this convention. Companioncube31 (talk) 20:11, 5 March 2019 (UTC)

—

"dirname" doesn't "return a directory from a given path", it "strips last component from file name" (from its man page).

"dirname" is a path manipulation routine, it's not a filesystem operation. It has no knowledge of what's a directory and what's a file.

It goes together with the "basename" command to separate a path in "everything before it" and "the last component".

Note that it works fine on non-existent files:

 dirname "/i/made/this/up" -> "/i/made/this"
 basename "/i/made/this/up" -> "up"

"basename" isn't aware of the implementation details that are "." and "..".

For example, "/etc/hosts" is a file on my system, but:

 dirname "/etc/hosts/." -> /etc/hosts

The actual convention for writing directory paths seems to be to either write "/etc", or "/etc/".

Both are valid, and correct, and right, but the latter is not only more explicit to the reader, it also prevents treating it as a file. For example:

 cat "/etc/hosts" -> works
 cat "/etc/hosts/" -> fails, "not a directory"

Saying that "/etc/" represents "the files in the directory" is also wrong.

Commands that expect a directory work just fine with all three notations:

 ls "/etc" -> works
 ls "/etc/" -> works
 ls "/etc/." -> works

If you still need to convince yourself that all three notations are equivalent, run the following:

 stat "/etc" -> inode 281474976832834 on my system
 stat "/etc/" -> exactly the same
 stat "/etc/." -> also the same

Fasterthanlime (talk) 15:38, 11 October 2019 (UTC)

While I agree with most of your reasoning, there are some differences between "/etc" and "/etc/". If "/etc" is a symlink to a directory then "stat /etc" returns the information about the symlink, whereas "stat /etc/" returns the stat of the directory itself. If we look beyond standard POSIX commands, then some tools will also behave differently with and without a trailing slash. One that comes to mind is rsync, where "rsync src dest" would place "src/file" into "dest/src/file", whereas "rsync src/ dest" would palce "src/file" into "dest/file". I personally consider it more of a misfeature, but that's how it works. bungalo (talk) 13:31, 18 May 2023 (UTC)

Syntax inconsistency in the table

In the "Root directory" column of the Representations of paths by operating system and shell table, the brackets are used inconsistently: [drive_letter:]\ vs [drive_letter]:\.

We can't fix that until we agree what exactly the braces mean:

1. They can be used to denote that something is optional. Then, of course, [drive_letter:]\ should be used. (Valid paths are C:\ and \ but not :\.)
2. They can be used to denote placeholders (a.k.a. nonterminal symbols; i.e. one should put C or D or whatever instead of literally typing drive_letter). Then [drive_letter]:\ should be used. (Because one must put C or D instead of [drive_letter] while : and \ are to be put literally.)

Personally I suggest:

1. Use braces to denote optional.
2. Don't use braces to denote placeholders, use a different font for that (e.g. italic).

Currently there's a mess.

To make distinguishing of placeholders easier, I suggest:

• Make all placeholders visually atomic and (preferably) compact, e.g. not drive letter (maybe it should be drive_letter, or better driveLetter, or better drive, or better D). Especially not drive, volume, device or assign name (maybe camel case or split into separate entries).
• Explain meaning of every placeholder in the "Notes" section at the bottom of the table.

Additionally I suggest to use colors, e.g. black for actual characters, green for placeholders and gray for other stuff.

So I suggest it to be:

[d:]\

_{(Footnote: d means bla-bla-bla.)}

or at least

[driveLetter:]\

_{(Footnote: driveLetter means bla-bla-bla.)}

Sasha1024 (talk) 10:43, 27 January 2022 (UTC)

Z/OS

The article misses information about Z/OS or other (non-unix) mainframe operating systems. --- 188.23.233.187 (talk) 01:31, 24 April 2023 (UTC)

In the case of IBM's mainframe OSes, are you thinking about the OS/360 catalog, mentioned in Hierarchical file system § IBM OS/360, or are you thinking about the Hierarchical File System (IBM MVS) and the zFS (z/OS file system)? Guy Harris (talk) 01:54, 24 April 2023 (UTC)

“Path” vs “pathname”

Information about the distinction, if any, between the terms “path” and “pathname” would be welcome. palpalpalpal (talk) 13:13, 19 May 2023 (UTC)