Bug 70813

Summary:

ls(1) is not POSIX compliant: options -g, -n, and -o in particular

Product:

Base System

Reporter:

Paul P <pprocacci>

Component:

standards

Assignee:

John Baldwin <jhb>

Status:

Closed FIXED

Severity:

Affects Some People

CC:

minsoochoo0122, standards

Priority:

---

Keywords:

standards

Version:

5.2.1-RELEASE

Flags:

jhb: mfc-stable14-
jhb: mfc-stable13-

Hardware:

Any

OS:

Any

URL:

https://github.com/freebsd/freebsd-src/tree/main/bin/ls

See Also:

https://reviews.freebsd.org/D34747

Attachments:

Description	Flags
file.diff	none

Description Paul P 2004-08-22 06:20:21 UTC

The bin utility 'ls' does not conform to Posix standards.  Specially the options
 g, n and o.
 
SHORT DESCIPTIONS from Posix:
-g "The same as -l, except that the owner shall not be written."
-n "The same as -l, except that the owner's UID and GID numbers shall be written
, rather than the associated character strings."
-o "The same as -l, except that the group shall not be written."
 
Current Desciption from freebsd, man page:
man ls
 
Please note that, in the manpage for ls, the -n option is currect, however the l
s utility doesn't actually follow the rule.
 
Also currently, the -o options is used to show the file flags.  With my included
 patch, I changed it to '-O', but I'm sure you guys would want to keep some comp
atibility somewhere.  I just wasn't sure how you guys wanted to implement this,
so I arbitrarily picked an unused letter.

Fix: http://hostsentry.net/ls.diff

How-To-Repeat: ls -g
ls -n
ls -o

Comment 1 Tim Robbins freebsd_committer

2004-08-22 10:27:57 UTC

Please note that the -g, -n and -o options are XSI extensions, and that
FreeBSD generally favours traditional BSD behaviour over System V behaviour
where conflicts exist.


Tim

Comment 2 Eitan Adler freebsd_committer

2017-12-31 07:58:57 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped

Comment 3 Minsoo Choo 2022-04-02 11:32:07 UTC

https://reviews.freebsd.org/D34747 Phabricator link

Comment 4 Graham Perrin freebsd_committer

2022-10-17 12:36:49 UTC

Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>

Comment 5 commit-hook freebsd_committer

2023-07-18 17:04:11 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=3bfbb521fef5764ecabc2bf3fdc76f47258171f8

commit 3bfbb521fef5764ecabc2bf3fdc76f47258171f8
Author:     Minsoo Choo <minsoochoo0122@proton.me>
AuthorDate: 2023-07-18 16:49:59 +0000
Commit:     John Baldwin <jhb@FreeBSD.org>
CommitDate: 2023-07-18 17:03:09 +0000

    ls: Improve POSIX compatibility for -g and -n.

    - Change -g (ignored for BSD 4.3 compatibility since BSD 4.4)
      to use POSIX semantics of implying -l but omitting the owner's
      name.

    - Change -n to imply -l.

    The -o option remains unchanged (POSIX defines -o as a complement to
    -g that implies -l but omits group names whereas BSD defines -o to add
    file flags to -l).  This compromise is the same used by both NetBSD
    and OpenBSD.

    PR:             70813
    Reviewed by:    jhb, Pau Amma <pauamma@gundo.com>
    Co-authored-by: John Baldwin <jhb@FreeBSD.org>
    Differential Revision:  https://reviews.freebsd.org/D34747

 bin/ls/ls.1              | 11 +++--------
 bin/ls/ls.c              | 10 +++++++++-
 bin/ls/ls.h              |  1 +
 bin/ls/print.c           |  8 +++++---
 bin/ls/tests/ls_tests.sh | 19 ++++++++++---------
 5 files changed, 28 insertions(+), 21 deletions(-)

Comment 6 Graham Perrin 2023-09-24 06:04:01 UTC

^Triage: 

* assign to the resolving committer
* CC the former assignee
* summary, URL, status, keywords, flags.

Comment 7 John Baldwin freebsd_committer

2023-11-18 19:12:56 UTC

This was merged to main prior to stable/14 branching, so is already present in stable/14 (no need to merge there).  Given that it does change the behavior of existing flags to a commonly-used command (albeit only slightly), I don't think it's worth merging to older branches.