From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id dfde19fa for ; Sun, 8 Mar 2020 05:27:15 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D0E1E9D778; Sun, 8 Mar 2020 15:27:13 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 321279D698; Sun, 8 Mar 2020 15:26:43 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id ED0C19D698; Sun, 8 Mar 2020 15:26:39 +1000 (AEST) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by minnie.tuhs.org (Postfix) with ESMTP id 01C4B9D649 for ; Sun, 8 Mar 2020 15:26:38 +1000 (AEST) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 84FE527313; Sun, 8 Mar 2020 05:26:34 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 8B104263595; Sun, 8 Mar 2020 16:26:33 +1100 (AEDT) Date: Sun, 8 Mar 2020 16:26:33 +1100 From: Greg 'groggy' Lehey To: Warner Losh Message-ID: <20200308052632.GD20478@eureka.lemis.com> References: <20200305020517.GA13872@wopr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fXStkuK2IQBfcDe+" Content-Disposition: inline In-Reply-To: Organization: LEMIS, 29 Stones Road, Dereel, VIC, Australia Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.lemis.com/grog X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) Subject: Re: [TUHS] Command line options and complexity X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thursday, 5 March 2020 at 14:56:58 -0700, Warner Losh wrote: > On Thu, Mar 5, 2020 at 2:51 PM Dave Horsfall wrote: >> On Wed, 4 Mar 2020, Ken Thompson via TUHS wrote: >> >>> do i get a prize: >>> ls -tj >>> /bin/ls: illegal option -- j >>> usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...] >> >> Another candidate for option-cleansing... Interesting; I get different >> options with the Mac and FreeBSD: >> >> Mac: >> >> usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...] >> >> FreeBSD: >> >> usage: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,] [-D format] >> [file ...] >> >> So FreeBSD has added up "y,D:" (in getopt(3)-speak); my eyes are burning= =2E.. > > FreeBSD wouldn't need -, if there were a good filter to add , to large > numbers... Some of the proliferation of options has been due to a lack of > proper building-blocks.... I wasn't going to join this discussion, but as the perpetrator of all three of the options that Dave complains about, I think it's worth explaining the rationale. First: yes, filters are good. They make for an extraordinarily flexible system. And many options are just bloat. But on the other hand, let's follow on with your example and assume a clever filter, say commafy, which would insert commas as needed in its input: $ ls -l | commafy 5 You really need the 5 (column number), because you can't rely on all large numeric values to require commas. Consider: $ ls -l 939585975893478543543 -rw-r--r-- 2 grog home 1719298048 8 Mar 14:14 939585975893478543543 The alternative would be to have the column number explicitly stated in the filter, but that would make the filter more specific to ls. But do you really want to add that much input when typing interactively into a shell? How much easier it is just to write: $ ls -l, 939585975893478543543 -rw-r--r-- 2 grog home 1,719,298,048 8 Mar 14:14 939585975893478543543 And then there are things that a filter can't easily do, the rationales for -y and -D format. -y is really a workaround for a bug in the POSIX specification for ls(1). From https://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html: -t Sort with the primary key being time modified (most recently modified first) and the secondary key being filename in the collating sequence. It's not immediately obvious, but these two keys sort in the opposite order. The file name is sorted alphabetically, but the modification time is the other way round (*reverse* chronological). This problem bites you, for example, when you list files from two different cameras that can take more than one image with the same time stamp. FAT timestamps have a granularity of 1 second, so they all end up with exactly the same time stamp. =46rom a diary entry for 24 January 2009 (http://www.lemis.com/grog/diary-jan2009.php?subtitle=3D%E2%80%9CNot%20a%20= bug,%20a%20feature%E2%80%9D:%20episode%204714&article=3Dlsorder#lsorder): =3D=3D=3D grog@dereel (/dev/ttyp2) ~/Photos/20061223/orig 63 -> ls -lTrt -rwxrwxrwx 1 grog home 2478324 Dec 23 15:35:08 2006 DSCN1325.JPG -rwxr-xr-x 1 grog home 1628592 Dec 23 17:11:00 2006 img_5504.jpg -rwxr-xr-x 1 grog home 1621982 Dec 23 17:11:00 2006 img_5503.jpg -rwxrwxrwx 1 grog home 2583242 Dec 23 17:27:30 2006 DSCN1326.JPG -rwxrwxrwx 1 grog home 2476707 Dec 23 17:27:48 2006 DSCN1327.JPG The file names for images with different timestamps are sorted alphabetically. The file names for images with the same timestamps are sorted in reverse alphabetical order. What to do? Potentially you could write a filter here too, though it wouldn't be simple, because the timestamp representation depends on the age of the file. And you can't just fix the bug, because it has been elevated to a feature. So -y does the right thing. And that date. There are three relatively arbitrary formats, two of them depending on how long ago the timestamp was: -rw-r--r-- 2 grog home 1,719,298,048 8 Mar 14:14 939585975893478543543 -rw-r--r-- 1 grog home 0 24 Sep 2012 foo You can fix that (on FreeBSD and probably on macOS) with the equally unsupported -T flag ("full timestamp"): $ ls -lT 939585975893478543543 foo -rw-r--r-- 2 grog home 1719298048 8 Mar 14:14:58 2020 939585975893478= 543543 -rw-r--r-- 1 grog home 0 24 Sep 14:42:57 2012 foo Do we need another format? Maybe. Certainly it would help to have a different format if you want to pass the output to a filter that looks at the timestamp. What should it be? Your guess is as good as mine, but probably different. Obvious choices are raw time_t and YYYYMMDDhhmmss. So I introduced the -D option to allow the user to choose his own output format. Is this a good idea? I certainly had pangs of conscience every time, and a non-standard option runs the risk of being incompatible with other systems. For example, Linux uses -T to define the tab size (arguably a better choice for a filter) and -D to produce output for Emacs dired mode. In summary: there's a tradeoff between the elegance of filters and the effort that they require. Adding options has its disadvantages too. You need to remember them, and they can easily become incompatible. But these specific features make life considerably easier and add very little to the size of the executable. I'd be interested to hear of alternative solutions to the issues. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl5kgggACgkQIubykFB6QiOmzQCeNp3Gb5y8s19hYB5CzVSyksht mLcAoJ37Jc6ejbPtAtyaxWVYQiqEMmiP =6o0I -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+--