View source for Talk:Path (computing)

{{WikiProject banner shell|class=C|
1=
{{WikiProject Computing|importance=Mid}}
{{WikiProject Software|importance=High}}
}}
{{FOLDOC}}

== 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
<small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User: JanC | JanC ]] ([[User talk: JanC |talk]] • [[Special:Contributions/ JanC |contribs]])  11:59, 8 May 2005 (UTC) </span></small><!-- Template:Unsigned -->


This isn't true on Vista, and I would imagine not on Windows 7, either.  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/24.211.30.90|24.211.30.90]] ([[User talk:24.211.30.90|talk]]) 23:22, 7 January 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

:Ok, great detective work. But why are we starting the section [[Path (computing)#MS-DOS/Microsoft Windows style|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.
:--[[User:Qwerty0|Qwerty0]] ([[User talk: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.  [[User:Shamino|Shamino]] ([[User talk: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 [[Environment_variable|env]] (Unix). --[[User:Harvestman|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. [[User:Dustin gayler|Dustin]] 17:56, 5 January 2007 (UTC)

== Japan and Korea ==

Why do Japanese and Korean versions of Windows use different directory separators? --[[User:Abdull|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...? --[[User:Abdull|Abdull]] 16:42, 15 April 2007 (UTC)
: I just added some clarification. Check and edit it please.—[[User:Gyopi|Gyopi]] 04:30, 28 August 2007 (UTC)

== Distinguishing between drive and directory in the classic Mac OS ==

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?  
[[User:Jgharston|Jgharston]] ([[User talk: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.
[[Special:Contributions/69.116.252.118|69.116.252.118]] ([[User talk: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. [[User:Shamino|Shamino]] ([[User talk: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 foot'''note''' to the table, or as a separate row all for itself.  
—DIV ([[Special:Contributions/1.129.105.93|1.129.105.93]] ([[User talk: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 ([[Special:Contributions/1.129.105.93|1.129.105.93]] ([[User talk:1.129.105.93|talk]]) 13:54, 11 July 2019 (UTC))
:macOS's core file access API, i.e. the Unix API, atop which all higher-level APIs are implemented, matches Unix, not surprisingly.
:Some layers used by applications, including the Finder, may treat {{mono|:}} as a path separator and {{mono|/}} as a file name character, for backwards compatibility with [[classic Mac OS]] users, by turning {{mono|:}} into {{mono|/}} and {{mono|/}} into {{mono|:}} before handing paths to the core file access API, and translate {{mono|:}} in file names provided by core directory enumeration APIs into {{mono|/}}.
:This is mentioned in a note below the table. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 23:43, 25 April 2025 (UTC)

== Filepath ==

The term "filepath" needs to redirect to this article.
[[User:Grozo|Grozo]] ([[User talk: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. [[User:Somerandomuser|Somerandomuser]] ([[User talk:Somerandomuser|talk]]) 21:55, 1 January 2021 (UTC)
::I don't think ''filepath'' a commonly used term. Is is just a path to a file? If so, then I'd call it file path, and it's not very interesting; just one of many types of paths. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 20:16, 13 April 2025 (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.

[[User:TamusJRoyce|TamusJRoyce]] ([[User talk:TamusJRoyce|talk]]) 04:30, 1 March 2019 (UTC)

:Do you have a source for this? I have never heard of this convention. [[User:Companioncube31|Companioncube31]] ([[User talk: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

[[User:Fasterthanlime|Fasterthanlime]] ([[User talk: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. [[User:Ybungalobill|bungalo]] ([[User talk:Ybungalobill|talk]]) 13:31, 18 May 2023 (UTC)

== Syntax inconsistency in the table ==

In the "Root directory" column of the [https://en.wikipedia.org/w/index.php?title=Path_(computing)&oldid=1055489455#Representations_of_paths_by_operating_system_and_shell Representations of paths by operating system and shell] table, the brackets are used inconsistently: <code>[drive_letter:]\</code> vs <code>[drive_letter]:\</code>.

We can't fix that until we agree '''what exactly the braces mean''':
# They can be used to denote that something is '''optional'''. Then, of course, <code>[drive_letter:]\</code> should be used. (Valid paths are <code>C:\</code> and <code>\</code> but not <code>:\</code>.)
# They can be used to denote '''placeholders''' (a.k.a. [[nonterminal symbol]]s; i.e. one should put <code>C</code> or <code>D</code> or whatever instead of literally typing <code>drive_letter</code>). Then  <code>[drive_letter]:\</code> should be used. (Because one must put <code>C</code> or <code>D</code> instead of <code>[drive_letter]</code> while <code>:</code> and <code>\</code> are to be put literally.)

Personally I suggest:
# Use braces to denote optional.
# 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 <code>drive letter</code> (maybe it should be <code>drive_letter</code>, or better <code>driveLetter</code>, or better <code>drive</code>, or better <code>D</code>). Especially not <code>drive, volume, device or assign name</code> (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: <blockquote>
<code><span style="color: silver;">[</span><span style="color: green;">''d''</span>''':'''<span style="color: silver;">]</span>'''\'''</code>

<sub>(Footnote: <span style="color: green;">''d''</span> means bla-bla-bla.)</sub>
</blockquote> or at least <blockquote>
<code><span style="color: silver;">[</span><span style="color: green;">''driveLetter''</span>''':'''<span style="color: silver;">]</span>'''\'''</code>

<sub>(Footnote: <span style="color: green;">''driveLetter''</span> means bla-bla-bla.)</sub>
</blockquote>
# 
[[User:Sasha1024|Sasha1024]] ([[User talk:Sasha1024|talk]]) 10:43, 27 January 2022 (UTC)

== Z/OS ==

The article misses information about Z/OS or other (non-unix) mainframe operating systems. --- [[Special:Contributions/188.23.233.187|188.23.233.187]] ([[User talk: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 {{section link|Hierarchical file system|IBM OS/360}}, or are you thinking about the [[Hierarchical File System (IBM MVS)]] and the [[zFS (z/OS file system)]]? [[User:Guy Harris|Guy Harris]] ([[User talk: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. [[User:Palpalpalpal|palpalpalpal]] ([[User talk:Palpalpalpal|talk]]) 13:13, 19 May 2023 (UTC)

:Never heard of ''pathname''. I don't think it's a thing. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 20:17, 13 April 2025 (UTC)
::It is a thing: [https://developer.mozilla.org/en-US/docs/Web/API/Location/pathname][https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/ffb795f3-027d-4a3c-997d-3085f2332f6f][https://docs.ruby-lang.org/en/master/Pathname.html]. ―<span style="font-family:Poppins, Helvetica, Sans-serif;">[[User:Panamitsu|Panamitsu]]</span> [[User_talk:Panamitsu|(talk)]] 22:14, 13 April 2025 (UTC)

== Case sensitivity ==

With all the detailed information about obscure systems and how they may represent things, I find it odd that there's not one mention of the fact that on some systems paths are case insensitive whereas on others they are case sensitive.  People need to know this basic fact. [[Special:Contributions/172.75.81.84|172.75.81.84]] ([[User talk:172.75.81.84|talk]]) 03:36, 28 July 2024 (UTC)