Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001261 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Omission 2019-06-14 21:43 2024-06-11 09:08
Reporter stephane View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Stephane Chazelas
Organization
User Reference
Section ls utility
Page Number 2923 (in 2018 edition)
Line Number 96911
Interp Status Approved
Final Accepted Text See Note: 0004492.
Summary 0001261: missing first line in ls example output
Description > An example of a small directory tree being fully listed with ls -laRF a
> in the POSIX locale:
>
> total 11
> drwxr-xr-x 3 fox prog 64 Jul 4 12:07 ./


Is missing the "a:" header.
Desired Action Change to:

> An example of a small directory tree being fully listed with ls -laRF a
> in the POSIX locale:
>
> a:
> total 11
> drwxr-xr-x 3 fox prog 64 Jul 4 12:07 ./
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0004425)
stephane (reporter)
2019-06-15 06:09

 2019-06-15 06:36:32 +0700, Robert Elz on the mailing list
https://www.mail-archive.com/austin-group-l%40opengroup.org/msg04133.html [^]
[...]
> | Is missing the "a:" header.
>
> Versions of ls I use don't include that header when there was
> just one (or no, but that is just implicitly specifying "." as
> the arg) arg given:
>
> jinx$ ls -laRF /tmp | sed 10q
> total 258
> drwxrwxrwt 14 root wheel 8448 Jun 15 06:19 ./
[...]

Thanks, I hadn't realised that. I can see ast-open's ls behaves
like NetBSD here, but all the other implementations I tried
(GNU, busybox, Solaris (/bin and /usr/xpg4/bin), FreeBSD,
OpenBSD) do add the "/tmp:" header here.

[...]
> What the text says is (lines 96861-3) is:
>
> If more than one directory, or a combination of non-directory files and
> directories are written, either as a result of specifying multiple operands,
> or the -R option, each list of files within a directory shall be preceded by:
>
> "\n%s:\n", <directory name>
>
> That isn't all that clear as to what it intended when one directory
> operand is given, together with -R (which then finds sub-directories),
> but the presence of that leading \n in the format suggests to me that
> this was not intended to occur as the first output line (also when multiple
> operands are listed, and all are directories, that \n does not appear
> in the first such header).
[...]

I have to admit that I had assumed it was a simple case of an
editorial mistake where somebody didn't copy paste the output of
ls properly, so I didn't even bother checking what the spec
said.

Now, that text is followed by:

} If this string is the first thing to be written, the first
} <newline> shall not be written. This output shall precede the
} number of units in the directory.

which addresses your concern about the leading newline.

But otherwise, you're right, it doesn't match existing practice

Three problems I can see:

- it's not so much whether more than one directory are "written"
  but whether more than one filename argument is passed to ls. I
  did actually report a bug against GNU ls decades ago
  (https://lists.gnu.org/archive/html/bug-fileutils/2001-04/msg00036.html) [^]
  where GNU ls behaved like POSIX requires which is not
  desirable. When you ask ls to list more than one thing, and it
  only lists one (because it can't list the other ones), you
  still want to know which one is listed.

- In the case of -R with one directory argument, implementations
  either always or never include the "dir:" for the first
  (requested) directory name. Doing it only if it ends up
  listing the content of at least one subdir would mean
  implementations would have to defer printing the directory
  content until it has identified one directory for which it can
  list the content.

- as you say, the spec currently says that NetBSD, ast-open are
  not compliant, but given the example (which may not be a typo
  after all) which matches the NetBSD behaviour, it may not have
  been intentional.

  Here, while I do find including the header every time makes
  for a more consistent looking output, it's a case where
  omitting it doesn't leave any ambiguity, so I would find it
  acceptable to allow it (and it's not as if the output of ls
  -lR was parsable or intended to be parsed so it doesn't matter
  so much if it's not consistent from one system to the next
  (some FTP clients do try to parse it, but FTP is a thing of
  the past)

So I think the spec should say something along the lines of:

} If more than one <filename> argument is given or if the -R
} option is provided, every directory listing shall be preceded
} by:
}
} "\n%s:\n", <directory name>
}
} If this string is the first thing to be written, the first
} <newline> shall not be written. This output shall precede the
} number of units in the directory.
}
} Implementations may choose to omit that first line in the case
} where the -R option is provided and zero or one filename
} argument is provided.

and the example should look like:

} a:
} total 11
} drwxr-xr-x 3 fox prog 64 Jul 4 12:07 ./
} drwxrwxrwx 4 fox prog 3264 Jul 4 12:09 ../
} drwxr-xr-x 2 fox prog 48 Jul 4 12:07 b/
} -rwxr--r-- 1 fox prog 572 Jul 4 12:07 foo*
}
} a/b:
} total 4
} drwxr-xr-x 2 fox prog 48 Jul 4 12:07 ./
} drwxr-xr-x 3 fox prog 64 Jul 4 12:07 ../
} -rw-r--r-- 1 fox prog 700 Jul 4 12:07 bar
}
} where the "a:" line may be omitted by some implementations
(0004491)
joerg (reporter)
2019-07-25 16:09
edited on: 2019-07-25 16:09

 All older UNIX implementations behaved like the BSD ls.

Solaris did change that for a POSIX certification and since then always
prints the header in case -R was specified.
(0004492)
Don Cragun (manager)
2019-07-25 16:23

 Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
Existing practice on this issue varies.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the following changes:

Add after P2929, L96864:
    The above string may be omitted for the directory named by the operand
    if only one operand is present. It may also be omitted for dot ('.') if no
    operands are present.
Prior to P2930 line 96911, insert a line as part of the example output:
    a:
After P2930 line 96920, insert a line in normal font:
    where the "a:" line may be omitted by some implementations.
(0004601)
agadmin (administrator)
2019-10-07 15:16

 Interpretation proposed: 7 October 2019
(0004646)
agadmin (administrator)
2019-11-11 12:19

 Interpretation Approved: 11 Nov 2019

- Issue History
Date Modified Username Field Change
2019-06-14 21:43 stephane New Issue
2019-06-14 21:43 stephane Name => Stephane Chazelas
2019-06-14 21:43 stephane Section => ls utility
2019-06-14 21:43 stephane Page Number => 2923 (in 2018 edition)
2019-06-14 21:43 stephane Line Number => 96911
2019-06-15 06:09 stephane Note Added: 0004425
2019-07-25 16:09 joerg Note Added: 0004491
2019-07-25 16:09 joerg Note Edited: 0004491
2019-07-25 16:23 Don Cragun Note Added: 0004492
2019-07-25 16:24 Don Cragun Interp Status => ---
2019-07-25 16:24 Don Cragun Final Accepted Text => See Note: 0004492.
2019-07-25 16:24 Don Cragun Status New => Interpretation Required
2019-07-25 16:24 Don Cragun Resolution Open => Accepted As Marked
2019-07-25 16:25 Don Cragun Interp Status --- => Pending
2019-07-25 16:26 Don Cragun Tag Attached: tc3-2008
2019-10-07 15:16 agadmin Interp Status Pending => Proposed
2019-10-07 15:16 agadmin Note Added: 0004601
2019-11-11 12:19 agadmin Interp Status Proposed => Approved
2019-11-11 12:19 agadmin Note Added: 0004646
2019-12-05 11:09 geoffclare Status Interpretation Required => Applied
2024-06-11 09:08 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker