NetBSD Problem Report #58740

From www@netbsd.org  Fri Oct 11 11:01:58 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 868231A923B
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 11 Oct 2024 11:01:58 +0000 (UTC)
Message-Id: <20241011110157.3C5281A923D@mollari.NetBSD.org>
Date: Fri, 11 Oct 2024 11:01:57 +0000 (UTC)
From: tlaronde@kergis.com
Reply-To: tlaronde@kergis.com
To: gnats-bugs@NetBSD.org
Subject: ls: flag -O incorrectly described in MAN and buggy
X-Send-Pr-Version: www-1.0

>Number:         58740
>Category:       bin
>Synopsis:       ls: flag -O incorrectly described in MAN and buggy
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 11 11:05:01 +0000 2024
>Last-Modified:  Sun Oct 13 14:15:01 +0000 2024
>Originator:     LARONDE Thierry
>Release:        current
>Organization:
>Environment:
NetBSD cauchy.polynum.local 10.99.12 NetBSD 10.99.12 (CAUCHY) #2: Thu Sep 26 16:02:35 CEST 2024  tlaronde@cauchy.polynum.local:/data/m/netbsd-10.99/sys/arch/amd64/compile/CAUCHY amd64

>Description:
ls(1) has a non POSIX flag 'O' that is described as displaying only "leaf" files (files, not directory).

This is not what it does: it only suppresses the display of the newline, dir and trailing ':' when going recursive.

Furthermore---this was found by Valery Ushakov---the implementation is buggy:

$ mkdir -p 1/2/3/4
$ touch 1/2/200
$ find .
.
./1
./1/2
./1/2/3
./1/2/3/4
./1/2/200
$ ls -RPO
./1
./1/2 
./1/2/200./1/2/3
./1/2/3/4



>How-To-Repeat:
$ cd /libexec
$ ls -FO
blocklistd-helper* dhcpcd-hooks/      ld.elf_so-i386*
devpubd-hooks/     dhcpcd-run-hooks*  lfs_cleanerd*
devpubd-run-hooks* ld.elf_so*         resolvconf/
$ cd /tmp
$ mkdir -p 1/2/3/4
$ touch 1/2/200
$ ls -RPO
./1
./1/2 
./1/2/200./1/2/3
./1/2/3/4

>Fix:
Just suppress the option. What the MAN page described can be achieved using find(1).

>Audit-Trail:
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58740: ls: flag -O incorrectly described in MAN and buggy
Date: Fri, 11 Oct 2024 22:06:56 +0000 (UTC)

 On Fri, 11 Oct 2024, tlaronde@kergis.com wrote:

 > Furthermore---this was found by Valery Ushakov---the implementation is buggy:
 >
 > $ mkdir -p 1/2/3/4
 > $ touch 1/2/200
 > $ find .
 >

 This is just a formatting issue. When `-P' is used, ls(1) should take into
 account the full pathname length when printing in multiple columns--it doesn't.
 This displays correctly if you force single-column mode:

 ls -1OPR ~

 > ls(1) has a non POSIX flag 'O' that is described as displaying only "leaf" files (files, not directory).
 >
 > This is not what it does: it only suppresses the display of the newline, dir and trailing ':' when going recursive.
 >

 Also fixed, below, I think--please try.

 ```
 diff -urN ls.orig/ls.c ls/ls.c
 --- ls.orig/ls.c	2024-02-03 01:51:38.676768149 +0000
 +++ ls/ls.c	2024-10-11 21:55:06.727238968 +0000
 @@ -552,8 +552,15 @@
   				continue;
   			}
   		}
 -		if (cur->fts_namelen > maxlen)
 -			maxlen = cur->fts_namelen;
 +		if (cur->fts_info == FTS_D && f_leafonly)
 +			cur->fts_number = NO_PRINT;
 +
 +		unsigned int ftslen = f_fullpath ?
 +			/* path + name + '/' */
 +			cur->fts_pathlen + cur->fts_namelen + 1 :
 +			cur->fts_namelen;
 +		if (ftslen > maxlen)
 +			maxlen = ftslen;
   		if (needstats) {
   			sp = cur->fts_statp;
   			if (sp->st_blocks > maxblock)
 ```

 -RVP

From: tlaronde@kergis.com
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58740: ls: flag -O incorrectly described in MAN and buggy
Date: Sat, 12 Oct 2024 09:16:43 +0200

 On Fri, Oct 11, 2024 at 10:10:02PM +0000, RVP via gnats wrote:
 >[...]
 >  
 >  Also fixed, below, I think--please try.
 >  

 To fix it is evidently good, but the question, for me, was rather
 to answer first to:

 1) What was the initial purpose of the flag? 

 2) Is the function described in 1) necessary?

 If the feature can be obtained easily with a simple combination of
 other POSIX utilities, Ocam's razor should apply: don't add another
 option; there are, IMHO, already far too many in ls(1)---almost
 all the latin letters, lower and upper case!

 FWIW is worth, if the functionality is what is described in the man
 page:

 $ find . -type f | sed 's!^.*/\([^/]*\)$!\1!' 

 does the trick with the minimal cost of one supplementary exec (the
 one of sed(1)).
 -- 
         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                      http://www.kergis.com/
                     http://kertex.kergis.com/
 Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58740: ls: flag -O incorrectly described in MAN and buggy
Date: Sat, 12 Oct 2024 18:10:45 +0700

     Date:        Sat, 12 Oct 2024 07:20:02 +0000 (UTC)
     From:        "tlaronde@kergis.com via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20241012072002.6897E1A923E@mollari.NetBSD.org>


   |  $ find . -type f | sed 's!^.*/\([^/]*\)$!\1!' 
   |  
   |  does the trick with the minimal cost of one supplementary exec (the
   |  one of sed(1)).

 I don't know anything about the -O option, or why it is there,
 but that is not a replacement.   Do remember that all those many
 options you mentioned ls having can be combined with -O, duplicating
 all of that in some kind of script or function (probably using stat(1)
 sort(1), ... is probably possible, but not likely a productive use of
 anyone's time.)

 kre

From: tlaronde@kergis.com
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/58740: ls: flag -O incorrectly described in MAN and buggy
Date: Sun, 13 Oct 2024 16:10:22 +0200

 On Sat, Oct 12, 2024 at 11:15:02AM +0000, Robert Elz via gnats wrote:
 > The following reply was made to PR bin/58740; it has been noted by GNATS.
 > 
 > From: Robert Elz <kre@munnari.OZ.AU>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: bin/58740: ls: flag -O incorrectly described in MAN and buggy
 > Date: Sat, 12 Oct 2024 18:10:45 +0700
 > 
 >      Date:        Sat, 12 Oct 2024 07:20:02 +0000 (UTC)
 >      From:        "tlaronde@kergis.com via gnats" <gnats-admin@NetBSD.org>
 >      Message-ID:  <20241012072002.6897E1A923E@mollari.NetBSD.org>
 >  
 >   
 >    |  $ find . -type f | sed 's!^.*/\([^/]*\)$!\1!' 
 >    |  
 >    |  does the trick with the minimal cost of one supplementary exec (the
 >    |  one of sed(1)).
 >  
 >  I don't know anything about the -O option, or why it is there,
 >  but that is not a replacement.   Do remember that all those many
 >  options you mentioned ls having can be combined with -O, duplicating
 >  all of that in some kind of script or function (probably using stat(1)
 >  sort(1), ... is probably possible, but not likely a productive use of
 >  anyone's time.)
 >  

 OK, granted. But then:

 1) It doesn't do, at the present, what it is described to do;
 2) It doesn't work, at the present, with at least some other options.

 The conclusion is that at present nobody uses it since nobody can rely
 on it or someone would have already made a PR stating that it doesn't
 work---I stumbled upon it only by accident. 

 So it seems to me simpler to remove it before it spreads to avoid
 the burden to have to verify that it works with any combination of
 the zillion flags, since the '-P' is a valuable addition making it
 easy, with combination with '-p', to invoke ls(1) with whatever
 other options, and then filtering the result against the trailing
 '/'.

 -- 
         Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                      http://www.kergis.com/
                     http://kertex.kergis.com/
 Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Home	PR Database Search