A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1746 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1746 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: fuser Page Number: 2817 Line Number: 92698 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2023-06-13 15:58 UTC Last Modified: 2023-06-15 09:35 UTC ====================================================================== Summary: fuser output format clarification ======================================================================
---------------------------------------------------------------------- (0006332) geoffclare (manager) - 2023-06-15 09:35 https://austingroupbugs.net/view.php?id=1746#c6332 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1746#c6330 > Why the change from %d to %1d ? The default for %d is %1d according to XBD 5. Read the description of the d conversion more carefully, particularly the last sentence. The diff, stty, and ulimit pages already use %1d for the same reason I'm proposing to use it here. > You also omitted the "for each process using that file" from the final sentence. Oops, thanks for spotting that. I removed it because it's in the wrong place, but must have got distracted while I was working out how/where to reintroduce it. The rest of your comment results from this text being out of place. With -u the output looks similar to this on the four implementations I tested:<pre> /: 1805cr(root) 1806cr(root) 1807cr(root)</pre>and that is what I was trying to make the proposed new STDERR text match. Note that the paragraph being changed is not stand-alone; it follows a bullet list which describes each component written to standard error, so it just needs to make the ordering between what's written to standard output and what's written to standard error clear. Re https://austingroupbugs.net/view.php?id=1746#c6331 > Also, there doesn't really need to be a space before the first pid True, but all the implementations I tested have one or more blanks there and I'm sure the original intention was to describe the existing practice. > "The pathname of each named file" - but there's no clue given as to what that really means, is it intended to run XSH/realpath on each file name given? Of the four implementations I tested, GNU coreutils uses realpath() but the others just write the argument as-is. > It is also not clear what (for the -c option) > The file is treated as a mount point > actually means. Currently I think the standard requires an error if the specified file is not a mount point (via the default CONSEQUENCES OF ERRORS requirements). However, only two of the four implementations I tested do that. So I think we should say the behaviour is unspecified if it's not a mount point. > How is anything supposed to distinguish diagnostic messages that may be written to stderr, from the actual output that also goes there? The format of diagnostic messages is unspecified, so they are always expected to be interpreted by a human, not a "thing". Distinguishing them doesn't seem hard for a human:<pre>$ fuser foo . bar foo: fuser: No such file or directory .: 15164c 2545c bar: fuser: No such file or directory $ fuser foo . bar > /dev/null foo: fuser: No such file or directory .: cc bar: fuser: No such file or directory</pre> Issue History Date Modified Username Field Change ====================================================================== 2023-06-13 15:58 geoffclare New Issue 2023-06-13 15:58 geoffclare Name => Geoff Clare 2023-06-13 15:58 geoffclare Organization => The Open Group 2023-06-13 15:58 geoffclare Section => fuser 2023-06-13 15:58 geoffclare Page Number => 2817 2023-06-13 15:58 geoffclare Line Number => 92698 2023-06-13 15:58 geoffclare Interp Status => --- 2023-06-13 20:20 kre Note Added: 0006330 2023-06-13 20:44 kre Note Added: 0006331 2023-06-15 09:35 geoffclare Note Added: 0006332 ======================================================================
