From andyf@johnny.speednet.com.au  Wed Jul 23 08:41:40 2003
Return-Path: <andyf@johnny.speednet.com.au>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 98E9637B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 Jul 2003 08:41:40 -0700 (PDT)
Received: from johnny.speednet.com.au (johnny.speednet.com.au [203.57.65.6])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C753E43F3F
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 Jul 2003 08:41:39 -0700 (PDT)
	(envelope-from andyf@johnny.speednet.com.au)
Received: from johnny.speednet.com.au (localhost [127.0.0.1])
	by johnny.speednet.com.au (8.12.8p1/8.12.8) with ESMTP id h6NFfcZH051672
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 24 Jul 2003 01:41:38 +1000 (EST)
	(envelope-from andyf@johnny.speednet.com.au)
Received: (from root@localhost)
	by johnny.speednet.com.au (8.12.8p1/8.12.8/Submit) id h6NFfcai051671;
	Thu, 24 Jul 2003 01:41:38 +1000 (EST)
Message-Id: <200307231541.h6NFfcai051671@johnny.speednet.com.au>
Date: Thu, 24 Jul 2003 01:41:38 +1000 (EST)
From: andyf@speednet.com.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: find -ls wastes space
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         54784
>Category:       bin
>Synopsis:       find(1) -ls wastes space
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 23 08:50:11 PDT 2003
>Closed-Date:    Thu Jul 29 23:27:18 UTC 2010
>Last-Modified:  Thu Jul 29 23:27:18 UTC 2010
>Originator:     andyf@speednet.com.au
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
>Environment:
>Description:
	When using the -ls option of find(1) the username and groupname are
	formatted into a fixed length field of UT_NAMESIZE (MAXLOGNAME on
        -current). This patch does what top(1) does and scans for the long-
	est username, then formats the field to this dynamic value.

	The patches to operater.c fix compile warnings.
>How-To-Repeat:
	find . -ls
>Fix:

diff -u ./extern.h ./new/extern.h
--- ./extern.h	Sun May  6 19:53:22 2001
+++ ./new/extern.h	Thu Jul 24 00:58:54 2003
@@ -111,5 +111,5 @@
 exec_f	f_user;
 
 extern int ftsoptions, isdeprecated, isdepth, isoutput, issort, isxargs;
-extern int mindepth, maxdepth;
+extern int namelength, mindepth, maxdepth;
 extern int regexp_flags;
diff -u ./function.c ./new/function.c
--- ./function.c	Fri Nov 15 21:38:15 2002
+++ ./new/function.c	Thu Jul 24 00:02:45 2003
@@ -49,6 +49,7 @@
 #include <sys/wait.h>
 #include <sys/mount.h>
 #include <sys/timeb.h>
+#include <sys/types.h>
 
 #include <dirent.h>
 #include <err.h>
@@ -926,8 +927,17 @@
 	OPTION *option;
 	char ***argvp;
 {
+	struct passwd *pw;
+
 	ftsoptions &= ~FTS_NOSTAT;
 	isoutput = 1;
+
+	while ((pw = getpwent()) != NULL) {
+	    if (strlen(pw->pw_name) > namelength)
+		namelength = strlen(pw->pw_name);
+	}
+	if (namelength < 8)
+	    namelength = 8;
 
 	return palloc(option);
 }
diff -u ./ls.c ./new/ls.c
--- ./ls.c	Wed Mar 13 05:34:50 2002
+++ ./new/ls.c	Thu Jul 24 00:12:57 2003
@@ -52,6 +52,8 @@
 #include <unistd.h>
 #include <utmp.h>
 
+extern int namelength;
+
 /* Derived from the print routines in the ls(1) source code. */
 
 static void printlink __P((char *));
@@ -67,9 +69,9 @@
 
 	(void)printf("%6lu %4qd ", (u_long) sb->st_ino, sb->st_blocks);
 	(void)strmode(sb->st_mode, modep);
-	(void)printf("%s %3u %-*s %-*s ", modep, sb->st_nlink, UT_NAMESIZE,
-	    user_from_uid(sb->st_uid, 0), UT_NAMESIZE,
-	    group_from_gid(sb->st_gid, 0));
+	(void)printf("%s %3u %-*s %-*s ", modep, sb->st_nlink,
+	    namelength, user_from_uid(sb->st_uid, 0),
+	    namelength, group_from_gid(sb->st_gid, 0));
 
 	if (S_ISCHR(sb->st_mode) || S_ISBLK(sb->st_mode))
 		(void)printf("%3d, %3d ", major(sb->st_rdev),
diff -u ./main.c ./new/main.c
--- ./main.c	Mon Feb 26 07:56:59 2001
+++ ./new/main.c	Thu Jul 24 00:10:57 2003
@@ -74,6 +74,7 @@
 int issort;         		/* do hierarchies in lexicographical order */
 int isxargs;			/* don't permit xargs delimiting chars */
 int mindepth = -1, maxdepth = -1; /* minimum and maximum depth */
+int namelength;			/* longest username */
 int regexp_flags = REG_BASIC;	/* use the "basic" regexp by default*/
 
 static void usage __P((void));
diff -u ./operator.c ./new/operator.c
--- ./operator.c	Sun May  6 19:53:22 2001
+++ ./new/operator.c	Mon Jul 21 22:19:03 2003
@@ -37,7 +37,9 @@
  */
 
 #ifndef lint
+#if 0
 static char sccsid[] = "@(#)operator.c	8.1 (Berkeley) 6/6/93";
+#endif
 #endif /* not lint */
 
 #include <sys/types.h>
@@ -173,7 +175,7 @@
 
 	tail = result = NULL;
 
-	while (next = yanknode(&plan)) {
+	while ((next = yanknode(&plan)) != NULL) {
 		/*
 		 * if we encounter a ( expression ) then look for nots in
 		 * the expr subplan.

>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@ringlet.net>
To: andyf@speednet.com.au
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/54784: find -ls wastes space
Date: Wed, 23 Jul 2003 19:06:35 +0300

 On Thu, Jul 24, 2003 at 01:41:38AM +1000, andyf@speednet.com.au wrote:
 > 
 > >Number:         54784
 > >Category:       bin
 > >Synopsis:       find -ls wastes space
 > >Arrival-Date:   Wed Jul 23 08:50:11 PDT 2003
 > >Originator:     andyf@speednet.com.au
 > >Release:        FreeBSD 4.8-RELEASE i386
 > >Description:
 > 	When using the -ls option of find(1) the username and groupname are
 > 	formatted into a fixed length field of UT_NAMESIZE (MAXLOGNAME on
 >         -current). This patch does what top(1) does and scans for the long-
 > 	est username, then formats the field to this dynamic value.
 
 Would this not break existing scripts, which rely on the current
 fixed formatting?
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 If you think this sentence is confusing, then change one pig.

From: Andy Farkas <andyf@speednet.com.au>
To: Peter Pentchev <roam@ringlet.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/54784: find -ls wastes space
Date: Thu, 24 Jul 2003 02:12:30 +1000 (EST)

 On Wed, 23 Jul 2003, Peter Pentchev wrote:
 
 > Would this not break existing scripts, which rely on the current
 > fixed formatting?
 
 You think? Most scripts would use spaces as a field seperator, so reducing
 the number of spaces shouldn't affect them.
 
 --
 
  :{ andyf@speednet.com.au
 
         Andy Farkas
     System Administrator
    Speednet Communications
  http://www.speednet.com.au/
 
 
 
 

From: Peter Pentchev <roam@ringlet.net>
To: Andy Farkas <andyf@speednet.com.au>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/54784: find -ls wastes space
Date: Wed, 23 Jul 2003 19:23:42 +0300

 On Thu, Jul 24, 2003 at 02:12:30AM +1000, Andy Farkas wrote:
 > On Wed, 23 Jul 2003, Peter Pentchev wrote:
 >=20
 > > Would this not break existing scripts, which rely on the current
 > > fixed formatting?
 >=20
 > You think? Most scripts would use spaces as a field seperator, so reducing
 > the number of spaces shouldn't affect them.
 
 In the past, people have objected strongly to changing the output of
 ps(1) for exactly this reason.  IMHO, there are several reasons not
 to rely on whitespace in parsing the output of ls(1) or find(1);
 for a trivial, though somewhat rare, example, consider whitespace in
 the localized representation of date and time.
 
 Other than that, there might be the human problem of comparing the
 output of 'find' run on different machines with different usernames, or
 even on the same machine, different directories owned by different
 users; the columns, and sometimes line continuations, would be all out
 of whack.
 
 G'luck,
 Peter
 
 --=20
 Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 I am not the subject of this sentence.

From: Andy Farkas <andyf@speednet.com.au>
To: Peter Pentchev <roam@ringlet.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/54784: find -ls wastes space
Date: Thu, 24 Jul 2003 02:34:01 +1000 (EST)

 On Wed, 23 Jul 2003, Peter Pentchev wrote:
 
 > In the past, people have objected strongly to changing the output of
 > ps(1) for exactly this reason.  IMHO, there are several reasons not
 > to rely on whitespace in parsing the output of ls(1) or find(1);
 > for a trivial, though somewhat rare, example, consider whitespace in
 > the localized representation of date and time.
 
 If there are objections, I'd like to hear the reasons. I think if you are
 relying on a fixed-width formatted string returned from a utility, then
 you are relying on the wrong thing.
 
 > Other than that, there might be the human problem of comparing the
 > output of 'find' run on different machines with different usernames,
 
 Different machines may have different values of UT_NAMESIZE. A human
 comapring two lists would be able to compensate.
 
 > or even on the same machine, different directories owned by different
 > users; the columns, and sometimes line continuations, would be all out
 > of whack.
 
 No. The computed value of namelength is same for all users on the same
 machine.
 
 --
 
  :{ andyf@speednet.com.au
 
         Andy Farkas
     System Administrator
    Speednet Communications
  http://www.speednet.com.au/
 
 
 
 

From: Peter Pentchev <roam@ringlet.net>
To: Andy Farkas <andyf@speednet.com.au>
Cc: bug-followup@freebsd.org
Subject: Re: bin/54784: find -ls wastes space
Date: Wed, 23 Jul 2003 20:13:47 +0300

 On Thu, Jul 24, 2003 at 03:07:05AM +1000, Andy Farkas wrote:
 [snip]
 > Also, 5.1-CURRENT is different like this:
 > 
 > -       (void)printf("%6lu %4qd ", (u_long) sb->st_ino, sb->st_blocks);
 > +       (void)printf("%6lu %4"PRId64" ", (u_long) sb->st_ino, sb->st_blocks);
 > 
 > What the fsck does "PRId64" mean!
 
 A newly-added POSIX standard specifier for a 64-bit decimal number,
 I believe - those can vary widely across systems, depending on
 the platform's 32- or 64-bitness, signedness, etc.
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 This sentence is false.

From: Gavin Atkinson <ga9@york.ac.uk>
To: bug-followup@FreeBSD.org, andyf@speednet.com.au
Cc:  
Subject: Re: bin/54784: find -ls wastes space
Date: Mon, 07 May 2007 14:47:33 +0100

 See PR bin/89762 for reasons as to why this may not be a good idea to
 implement (the code in top(1) that has been reused here has issues).
 
 Gavin
State-Changed-From-To: open->closed 
State-Changed-By: jilles 
State-Changed-When: Thu Jul 29 23:24:55 UTC 2010 
State-Changed-Why:  
I don't think there is a good way to fix this. 
Iterating over all users with getpwent() may be very slow or may not work 
at all in some environments. 
I don't see another way to find the column widths. Buffering all output 
would be rather annoying as well. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=54784 
>Unformatted:
