From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RDNS_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 13322 invoked from network); 12 Mar 2020 00:43:33 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from unknown (HELO minnie.tuhs.org) (45.79.103.53) by inbox.vuxu.org with ESMTP; 12 Mar 2020 00:43:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 604429BD0B; Thu, 12 Mar 2020 10:43:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5829A9BB47; Thu, 12 Mar 2020 10:43:03 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 341B19BB47; Thu, 12 Mar 2020 10:43:00 +1000 (AEST) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by minnie.tuhs.org (Postfix) with ESMTP id 21C4E9BB46 for ; Thu, 12 Mar 2020 10:42:59 +1000 (AEST) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 4A2E727313; Thu, 12 Mar 2020 00:42:58 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 8CD4C263595; Thu, 12 Mar 2020 11:42:57 +1100 (AEDT) Date: Thu, 12 Mar 2020 11:42:57 +1100 From: Greg 'groggy' Lehey To: Dan Cross Message-ID: <20200312004257.GH89512@eureka.lemis.com> References: <202003031815.023IFSlD493028@darkstar.fourwinds.com> <20200311225638.GG89512@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw" 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" --Zrag5V6pnZGjLKiw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 11 March 2020 at 19:14:32 -0400, Dan Cross wrote: > On Wed, Mar 11, 2020 at 6:57 PM Greg 'groggy' Lehey wrote: > >> On Wednesday, 11 March 2020 at 14:18:08 +1100, Dave Horsfall wrote: >>> >>> The "ls" command for example really needs an option-ectomy; I find that I >>> don't really care about the exact number of bytes there are in a file as >>> the nearest KiB or MiB (or even GiB) is usually good enough, so I'd be >>> happy if "-h" was the default with some way to turn it off (yes, I know >>> that it's occasionally useful to add them all up in a column, but that >>> won't tell you how many media blocks are required). >> >> A good example. But you're not removing options, you're just >> redefining them. In fact I find the -h option particularly emetic, so >> a better choice in removing options would be to remove -h and use a >> filter to mutilate the sizes: >> >> $ ls -l | humanize >> >> But that's a pain, isn't it? > > I don't know; that's subjective. It's certainly more work than -h. >> That's why there's a -h option for people who like it. > > That's incomplete, in that it implies that an option is the only way > to achieve the goal of reducing the perceived pain, but that's not > the case. (Note I'm not saying you intended that as an > interpretation, but it's a reasonable intuition for an intention.) What I meant (and this is certainly my interpretation) was that somebody added the -h option because of perceived pain with piping output through another program. I didn't intend to imply that it was the only alternative. > An interesting counterpoint to this argument is how columnized "ls" > is handled under Plan 9: there is no `-C` option to `ls` there; > instead, there's a general-purpose `mc` filter that figures out the > size of the window it's running in, reads its input, decides how > many columns the input will fit into, and emits it columnized. But > yes, it would be a pain to type `ls | mc` every time one wanted > columnized `ls` output, so this is wrapped up into a shell script > called `lc`. Note that this lets you do stuff like, `lc -l` and see > multi-column long listings if the window is wide enough. Yes, that sounds like an excellent method. > For the `humanize` thing, I don't see why one couldn't have an `lh` > command that generated "human-friendly long output from ls." And yes, I deliberately didn't mention this option, though it occurred to me. I have a couple of scripts like this, like: alias l="ls -lbL," >> Note that you can't do it the other way round: you can't get the >> exact size from -h output. > > That's true, but now the logic is specialized to ls, and not > applicable to anything else (e.g., du? df? wc, perhaps?). Similarly > with `-,`. It is not general purpose, which is unfortunate. Yes, this is an issue that I mentioned in an earlier message (I added a positional parameter to work around it). But this is in the nature of the output. mc doesn't have this issue. > Granted, combining these things would be a little challenging, but is it > likely that one would want `ls -l,h`? Optimize for the common case, > etc.... Heh. Never thought of that. But since -h (apparently) never produces output with 4 digits, the -, doesn't ever come into effect. I've just tried it on some big files, and the -, is effectively ignored. > And then there's the question why you don't like the standard > output. I don't like the standard output because things like this are hard to read: -rw-r--r-- 1 grog lemis 8234010624 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 13225168900 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 I find this easier to read: -rw-r--r-- 1 grog lemis 8,234,010,624 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 13,225,168,900 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 I can't speak for Dave, but this is also less painful: -rw-r--r-- 1 grog lemis 7.7G 22 Mar 2012 Casanova-TV-1-5 -rw-r--r-- 1 grog home 12G 31 Aug 2019 Movie:_Sahara_2005-2016-04-11-2028 The problem for me there is the difficulty comparing lengths, and the implicit inaccuracy. >> Because the number strings are too long and difficult to read, maybe? >> That's the rationale for the -, option. >> >>> Quickly now, without looking: which option shows unprintable >>> characters in a filename? Unless you use it regularly (in which >>> case you have real problems) you would have to look it up; I find >>> that "ls ... | od -bc" to be quicker, especially on filenames with >>> trailing blanks etc (which "-B" won't show). >> >> This is arguably a bug in the -B option. I certainly don't think the >> pipe notation is quicker. But it's nice to have both alternatives. > > By default, plan9 would quote filenames that had characters that > were special to the shell (there wasn't really the concept of > "non-printable characters in the Unix/TTY sense); this could be > disabled by specifying the `-Q` option. Hmm. In this particular case, so does Linux: === grog@bilbo (/dev/pts/11) ~ 2 -> touch "foo " === grog@bilbo (/dev/pts/11) ~ 4 -> l foo* -rw-r--r-- 1 grog grog 1499570 Jun 30 2012 foo -rw-r--r-- 1 grog grog 0 Mar 12 10:40 'foo ' I wonder if that's something we should emulate in FreeBSD. At the very least we should consider whether the lack of identification of trailing blanks is a bug in the FreeBSD implementation of -B. This option isn't in POSIX, and in Linux it means -B, --ignore-backups do not list implied entries ending with ~ So maybe it's a candidate for fixing. 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 --Zrag5V6pnZGjLKiw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl5phZEACgkQIubykFB6QiNjsACfaBRiLdTgkl6Kzfzafcck2npq G7AAniwa0+XXJw8whiiTYFBbR715tUNQ =hlCw -----END PGP SIGNATURE----- --Zrag5V6pnZGjLKiw--