A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1340 ====================================================================== Reported By: shware_systems Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1340 Category: Base Definitions and Headers Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Mark Ziegast Organization: SHware Systems Dev. User Reference: Section: XBD 8.3 Page Number: 178 Line Number: 5854-7 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2020-05-04 16:28 UTC Last Modified: 2020-05-05 16:21 UTC ====================================================================== Summary: PATH specification has an ambiguity. ======================================================================
---------------------------------------------------------------------- (0004862) kre (reporter) - 2020-05-05 16:21 https://www.austingroupbugs.net/view.php?id=1340#c4862 ---------------------------------------------------------------------- Re https://www.austingroupbugs.net/view.php?id=1340#c4854 To take the first couple of issues in reverse order, as it makes more sense (to me) this way... It is redundant because all of the places in the standard that require a PATH search to be done already state that no PATH search is done if there is a slash in the string that would be the subject of the search. To me that has produced exactly the inverse to the correct response. If everything that uses PATH needs to specify that it is only used when there is no slash in the name, then lets simplify all of those, and codify the rules for PATH processing in a single place, so everyone gets a *known* consistent interpretation and we don't have people quibbling about why the wording for the use in context X is subtly different from the wording for contest Y, and deducing from that, that the behaviour is supposed to be different. And if we're certain that the identical wording is used in every case, then that's an even better reason for consolidating it and removing the duplication. Further, this is the safe way to make the change - if we have missed one of the uses (and so don't delete its redundant wording) then we're left with some redundant text, but that's generally harmless. On the other hand if we have missed a use which turns out not to specify that no path search is done when the pathname being sought contains a slash, and we delete the text in the definition of PATH which deals with that, then we've just caused the standard to be broken. Since the standard is very large, and I'm sure the word PATH appears in it very many times, I'd hate to guarantee (as in, my life depends upon it) that we know every place where a path search is specified, and if we are not 100% certain that we have found every single one, then neither can we be certain that every single one has the "no slash" qualification. And last, it means that someone who simply wants to know what this environment variable PATH is all about, and (reasonably) turns to XBD 8.3 to get the answer, will actually discover the whole picture, and not end up missing the crucial element that a search for a/b only looks for "a/b" and doesn't try PATH[1]/a/b PATH[2]/a/b (etc) (using invented notation for the ':' delimited sub-strings of PATH). Next: It is erroneous because the thing that is sought is a filename, not a pathname, and therefore by definition cannot contain a slash. This is part of the "poor wording" I remarked on in earlier notes. It isn't really as bad (and isn't actually incorrect) it is just hard to read correctly easily (and currently depends upon the reader correctly understanding the difference between pathname and filename). PATH What we do about it depends upon the resolution of the previous point. If we agree to consolidate the definition of how PATH works (all of it) in XBD 8.3, which is what I'd suggest should be done, then the thing that is sought is a pathname, not a filename (as they're defined in XBD 3.170 and 3.271), and the correct response to this problem is to fix that, and use "filename" only after we have excepted the case where there's a slash in the pathname - and I'd make the wording be clear about the change of terminology, and why something perhaps like: PATH This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file. The prefixes shall be separated by a <colon> (':'). If the pathname being sought contains no slash ('/') characters, and hence is a filename, the list of prefixes shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. When a non-zero-length prefix is applied to the filename, a <slash> shall be inserted between the prefix and the filename if the prefix did not end in <slash>. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent <colon> characters ("::"), as an initial <colon> preceding the rest of the list, or as a trailing <colon> following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH. If the pathname being sought contains a <slash>, and so is not a filename, the search through the path prefixes shall not be performed. and then continue as it is now, as amended by the feed for ... The statement "If the pathname begins with a <slash>, the specified path is resolved" is problematic because it only requires pathname resolution to be done for absolute pathnames, not relative ones. More poor wording, and I have no problem with fixing that. However, I don't think we should discard mention of what happens with a PATH search when the pathname being sought contains a '/' and rely upon the reader just understanding that since it says "filename" thatmust be true, while being left in the dark (until they find a use of PATH search) about what happens if there is a '/'. And then wonder why it is divided up that way, and if perhaps different applications of PATH searching might have different rules for what to do in that case. That is, I don't believe the proposed resolution in https://www.austingroupbugs.net/view.php?id=1340#c4855 is good enough. Issue History Date Modified Username Field Change ====================================================================== 2020-05-04 16:28 shware_systems New Issue 2020-05-04 16:28 shware_systems Name => Mark Ziegast 2020-05-04 16:28 shware_systems Organization => SHware Systems Dev. 2020-05-04 16:28 shware_systems Section => XBD 8.3 2020-05-04 16:28 shware_systems Page Number => 178 2020-05-04 16:28 shware_systems Line Number => 5854-7 2020-05-04 19:31 kre Note Added: 0004846 2020-05-04 19:33 kre Note Added: 0004847 2020-05-04 20:05 shware_systems Note Added: 0004848 2020-05-05 03:00 kre Note Added: 0004849 2020-05-05 03:16 shware_systems Note Added: 0004850 2020-05-05 04:39 kre Note Added: 0004851 2020-05-05 05:03 kre Note Edited: 0004851 2020-05-05 05:04 kre Note Edited: 0004851 2020-05-05 05:11 kre Note Edited: 0004851 2020-05-05 05:13 kre Note Edited: 0004851 2020-05-05 08:40 geoffclare Note Added: 0004854 2020-05-05 08:46 geoffclare Note Added: 0004855 2020-05-05 08:47 geoffclare Note Edited: 0004855 2020-05-05 16:19 shware_systems Note Added: 0004861 2020-05-05 16:21 kre Note Added: 0004862 ======================================================================
