The following issue has been SUBMITTED. ====================================================================== http://austingroupbugs.net/view.php?id=1073 ====================================================================== Reported By: EdSchouten Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 1073 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Ed Schouten Organization: The FreeBSD Project User Reference: Section: dirname utility and dirname() function Page Number: - Line Number: - Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2016-08-29 20:17 UTC Last Modified: 2016-08-29 20:17 UTC ====================================================================== Summary: dirname utility: algorithm for computing pathname string is stricter than the corresponding dirname() function Description: The dirname() function is described in a pretty relaxed way:
"The dirname() function shall take a pointer to a character string that contains a pathname, and return a pointer to a string that is a pathname of the parent directory of that file. Trailing '/' characters in the path are not counted as part of the path." In FreeBSD HEAD, we're making use of this fact by implementing this function as follows: https://svnweb.freebsd.org/base/head/lib/libc/gen/dirname.c?view=markup A simple linear scan through the input string, copying all but the last pathname component over to the output. Pathname components consisting of a single dot are omitted, so that the output corresponds to the shortest sequence leading up to the path. As far as I know, this implementation complies to the spec. Now the interesting part. It looks like the description of the dirname utility has a definition that's a lot stricter than that of dirname(). It explicitly describes all of the steps that need to be performed to get the output string. This means that there are some inconsistencies between the potential output of the utility and the function: - Input: //a//b// - Output utility: //a - Output function: //a or /a - Input: //.//b// - Output utility: //. - Output function: //., /., // or / In other words, the dirname utility cannot be implemented on top of the dirname() function, which does seem to be done pretty often. My question is, is this really what's intended? Desired Action: The description of the dirname utility could be simplified a lot to just say: "The output generated by this utility is identical to that of the dirname() function." Done. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-08-29 20:17 EdSchouten New Issue 2016-08-29 20:17 EdSchouten Status New => Under Review 2016-08-29 20:17 EdSchouten Assigned To => ajosey 2016-08-29 20:17 EdSchouten Name => Ed Schouten 2016-08-29 20:17 EdSchouten Organization => The FreeBSD Project 2016-08-29 20:17 EdSchouten Section => dirname utility and dirname() function 2016-08-29 20:17 EdSchouten Page Number => - 2016-08-29 20:17 EdSchouten Line Number => - ======================================================================