From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 22 00:48:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD9016A4CE for ; Tue, 22 Jun 2004 00:48:54 +0000 (GMT) Received: from felix.gbch.net (gw.gbch.net [203.143.238.93]) by mx1.FreeBSD.org (Postfix) with SMTP id 0346E43D2D for ; Tue, 22 Jun 2004 00:48:52 +0000 (GMT) (envelope-from gjb@gbch.net) Received: (qmail 51082 invoked by uid 1001); 22 Jun 2004 10:48:50 +1000 Message-ID: Date: Tue, 22 Jun 2004 10:48:50 +1000 From: Greg Black To: freebsd-hackers@freebsd.org References: <20040621054406.GA927@VARK.homeunix.com> <200406210910.aa18808@salmon.maths.tcd.ie> <20040621091649.GA92422@iconoplex.co.uk> <20040621133003.GA96338@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O98KdSgI27dgYlM5" Content-Disposition: inline In-Reply-To: <20040621133003.GA96338@ussenterprise.ufp.org> User-Agent: Mutt/1.4.2.1i; gjb-muttsend.sh 1.5 2003-10-01 X-Uptime: 62 days X-Operating-System: FreeBSD 4.8-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Blog: http://www.gbch.net/gjb/blog/ X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-PGP-Key-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-Request-PGP: http://www.gbch.net/keys/4B04B7D6.asc Subject: Re: /bin/ls sorting bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 00:48:55 -0000 --O98KdSgI27dgYlM5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-06-21, Leo Bicknell wrote: > While I think the particular sort order (current behavior vrs non > nano patch vrs nano patch) is largely unimportant, I think consistency > is very important. It's quite common to do things like using diff > on the output of commands like ls (indeed, I think several of the > built in periodic scripts to this), and for that having a _reproduceable_ > order is important. The output of ls has never been good for reproduceable output for identical data. It frequently leads to gigantic "diffs" in periodic reports which makes them useless, as far as I can tell. Take the following case: $ mkdir foo $ touch foo/a [1] $ ls -l foo total 0 -rw-r--r-- 1 gjb gjb 0 Jun 22 10:25 a $ touch foo/b =20 [2] $ ls -l foo total 0 -rw-r--r-- 1 gjb gjb 0 Jun 22 10:25 a -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b $ sudo chown nobody foo/a [3] $ ls -l foo total 0 -rw-r--r-- 1 nobody gjb 0 Jun 22 10:25 a -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b If we diff the output of ls[1] and ls[2], we'll get a useful answer that shows us that "b" was added. But if we diff ls[2] and ls[3], it will appear as though every entry has changed, although only "b" has. When this happens in big directories, the consequences are astonishingly bad. What we need is a canonical output form for this kind of use that can be fed to a custom diff that can operate on individual fields. Oh, but wait, we can do it anyway using standard tools. Maybe somebody could fix the periodic scripts instead of continuing the ls bikeshed: [4] $ ls -l foo | tr -s ' ' total 0 -rw-r--r-- 1 gjb gjb 0 Jun 22 10:25 a -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b $ sudo chown nobody foo/a [5] $ ls -l foo | tr -s ' ' total 0 -rw-r--r-- 1 nobody gjb 0 Jun 22 10:25 a -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b The output of ls[4] is in our canonical format, i.e., with one space between fields; when diff'd against the output of ls[5], only the single changed file will show up. Great, this is useful output. Cheers, Greg --O98KdSgI27dgYlM5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) Comment: See http://www.gbch.net/keys.html for my public keys iD8DBQFA14HyXYO2+0sEt9YRAkimAJ9qDTmhrBhHsOrSIJ+8ADwHgUAyawCg1S/F r97jcxeoDrx3FZWXuxbA21s= =WrxQ -----END PGP SIGNATURE----- --O98KdSgI27dgYlM5--