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.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RDNS_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 Received: (qmail 2757 invoked from network); 11 Mar 2020 23:15:38 -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; 11 Mar 2020 23:15:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6F3069BB7F; Thu, 12 Mar 2020 09:15:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2865D9BB47; Thu, 12 Mar 2020 09:15:15 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="UAu8uHqA"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9BB189BB47; Thu, 12 Mar 2020 09:15:12 +1000 (AEST) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by minnie.tuhs.org (Postfix) with ESMTPS id 395E79BB46 for ; Thu, 12 Mar 2020 09:15:09 +1000 (AEST) Received: by mail-qk1-f174.google.com with SMTP id m2so3888790qka.7 for ; Wed, 11 Mar 2020 16:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hwynDFNVDZfXHqGFtIXvuIqiuhjr51v81eYLi//AO1I=; b=UAu8uHqAqyiheX8A9yDeL8kHfqAGZFgjBdHh+xZZs/9mTqp4V+fu4t8Pv4MWLvhISo GvNn8OHHuLvx8eyU5sP1o9EuQ8fFeEZrHpZ02hfNGe7szDb5ZhrWcr3WGQTWBoEJEtjf svDAkR8f2jfzDC8YaQxSX2vDwruw8QGvy8IkMmHiEyazFDVHL0wi6veCKP08qLheGwne v0hp6sCCUwJJ47G+E9+3A0f2Hk8+029bGB4umcee96ERmWwI472fXbkgM5FQJVMm7ZC3 cHEigHzo+rcCQwHauxlBgsJEYXl0wqUFNdYpclx6jq2/xXmeWb42lh5z5gasZMkMuqKt E3Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hwynDFNVDZfXHqGFtIXvuIqiuhjr51v81eYLi//AO1I=; b=DDkkR4iI68Uce3pw7oyCmV8NAUvvyLPtZ6CNPa1usQFh/cQMlVlGruIvS8+RsnksQT 1uFtU1qtxu0J4SmM9kEh+h0GGHq7jUXgdYiEvIsgIhKNDiERkRRXoem2NavOXU5f0lBY P7qSaXICTLPglV5Pk81VNvv9kcKOx/lhl3JOZ4pgXSj5h/EXc4vpTAsTzpmzEE0FG0zf brODzSgrgm5q2AYXjohcfm27m9uTmRK9qj0G7HM2RobNCKw/S1VdLQiVTfgcKsgm3ezm Y0WB6S0Q4JJIm/lYqmmk3rBscJ7TewjTEIEpOS48pQ3o/c9hEo2wC508eenIs1qw51k3 Q3Ng== X-Gm-Message-State: ANhLgQ0KDtoDcf32dE8FrDJIKxGA9XMwXxahKBQZNPQx4FBS58QamOqB dHZU+lVcPNsgqofAMADwLuws9u6g/FP2AugWPEs= X-Google-Smtp-Source: ADFU+vuAT4VPeZTqCSs928AHD+LlO2M39qTmO9H9K0Ai6m6jTTa7wtg5rpf5IyJ75fB36ZiSEYn6UI/L0e1V4/G5Op4= X-Received: by 2002:a37:6244:: with SMTP id w65mr1662214qkb.350.1583968508317; Wed, 11 Mar 2020 16:15:08 -0700 (PDT) MIME-Version: 1.0 References: <202003031815.023IFSlD493028@darkstar.fourwinds.com> <20200311225638.GG89512@eureka.lemis.com> In-Reply-To: <20200311225638.GG89512@eureka.lemis.com> From: Dan Cross Date: Wed, 11 Mar 2020 19:14:32 -0400 Message-ID: To: "Greg 'groggy' Lehey" Content-Type: multipart/alternative; boundary="000000000000461cb005a09c6840" 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" --000000000000461cb005a09c6840 Content-Type: text/plain; charset="UTF-8" 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. > 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.) 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. I got so used to this from plan9 that I keep an approximation in $HOME/bin/lc: `exec ls -ACF "$@"`. For the `humanize` thing, I don't see why one couldn't have an `lh` command that generated "human-friendly long output from ls." > 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. 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.... And then there's the question why you don't like the standard output. > 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. - Dan C. --000000000000461cb005a09c6840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 11, 2020 at 6:57 PM Greg '= ;groggy' Lehey <grog@lemis.com= > 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 f= ile 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.=C2=A0 But you're not removing options, you're just<= br> redefining them.=C2=A0 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:

=C2=A0 $ ls -l | humanize

But that's a pain, isn't it?

I don&= #39;t know; that's subjective.
=C2=A0
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 re= ducing the perceived pain, but that's not the case. (Note I'm not s= aying you intended that as an interpretation, but it's a reasonable int= uition for an intention.)

An interesting counterpo= int 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-p= urpose `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 t= ime one wanted columnized `ls` output, so this is wrapped up into a shell s= cript called `lc`. Note that this lets you do stuff like, `lc -l` and see m= ulti-column long listings if the window is wide enough.

I got so used to this from plan9 that I keep an approximation in $HOM= E/bin/lc: `exec ls -ACF "$@"`.

For the `= humanize` thing, I don't see why one couldn't have an `lh` command = that generated "human-friendly long output from ls."
= =C2=A0
Note that you= can't do it the other way round:
you can't get the exact size from -h output.

<= /div>
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.

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...= .

And then there's the question why you don't like the standard outpu= t.
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?=C2=A0 Unless you use it regularly (in which<= br> > case you have real problems) you would have to look it up; I find
> that "ls ... | od -bc" to be quicker, especially on filename= s with
> trailing blanks etc (which "-B" won't show).

This is arguably a bug in the -B option.=C2=A0 I certainly don't think = the
pipe notation is quicker.=C2=A0 But it's nice to have both alternatives= .

By default, plan9 would quote filenames t= hat 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.

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--000000000000461cb005a09c6840--