Talk:Path (computing)

message: 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)
thread_title:  Unix conventions 

message: 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)
thread_title:  ARC paths 

message: Why do Japanese and Korean versions of Windows use different directory separators? --Abdull 07:59, 11 April 2007 (UTC)
replies: text: 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)

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

message: 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)
replies: text: 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)
thread_title:  MacOS 

message: 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)
thread_title: Table

message: The term "filepath" needs to redirect to this article.
Grozo (talk) 21:33, 3 June 2018 (UTC)
replies: text: 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)
thread_title:  Filepath 

message: 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)
replies: text: Do you have a source for this? I have never heard of this convention. Companioncube31 (talk) 20:11, 5 March 2019 (UTC)

text: 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)
thread_title:  Filepath Misconceptions 

message: 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:
# 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 :\.)
# 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:
# 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 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)
thread_title:  Syntax inconsistency in the table 

message: 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)
replies: text: In the case of IBM's mainframe OSes, are you thinking about the OS/360 catalog, mentioned in , 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)
thread_title:  Z/OS 

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