The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steve Nickolas <usotsuki@buric.co>
To: Greg 'groggy' Lehey <grog@lemis.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Command line options and complexity
Date: Wed, 11 Mar 2020 23:34:46 -0400 (EDT)	[thread overview]
Message-ID: <alpine.BSF.2.02.2003112321580.82036@frieza.hoshinet.org> (raw)
In-Reply-To: <20200312030917.GJ89512@eureka.lemis.com>

On Thu, 12 Mar 2020, Greg 'groggy' Lehey wrote:

> On Wednesday, 11 March 2020 at 20:53:12 -0400, Steve Nickolas wrote:
>> I went through all the switches defined by POSIX, and figured that
>> those 26 could be cut down.
>
> A brave man to defy POSIX!  I wasn't so brave, which is why we have
> the -y option.

xD

>> My concept reduced the number of switches from 26 to 9 (FLRadfiln).
>> Of course, the idea is to be more minimalist than POSIX, so some
>> people's opinions on what is or isn't necessary may differ from
>> mine.
>
> OK, let's compare notes:
>
>> I felt -A was a redundant "almost -a".
>
> Arguably -a could go too.  The distinction seems arbitrary.

Well, I think one or the other would be desirable.  I figured -a was the 
better to keep - since it shows all dotfiles where -A leaves off . and .. 
.

>> I felt -C and -x were redundant because a tool like column(1) could be
>> used to do the same job (even though column(1) isn't POSIX).
>
> Neither would this ls(1) be.

Of course. ;)

<snip>

> -S isn't POSIX.  And to implement it without an option would mean
> removing -h.

-h is a gnuism, isn't it?

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html does 
specify the -S switch.  That's POSIX, isn't it?

> As I mentioned earlier, -t can't be done by a filter without
> significantly modifying the timestamp output.  That was my rationale
> for the -D option, which allows sorting by an external filter.

Understandable.

Honestly if the date format weren't standardized as it were, I would've 
standardized on "yyyy-mm-dd,mm:ss" - which wouldn't need special 
processing in order to pump into sort(1).

>> I felt -c and -u were meaningless, but that's because of the filesystems I
>> usually work with that do not have functional equivalents.  -u for one is
>> completely useless on VFAT even though it has such timestamps!  YMMV.
>
> I think this says more about your file systems than about the options.
> I find both incredibly useful, and there's no easy way to get the
> information elsewhere.  stat(1) would be an option, but then that
> could replace ls(1) completely.

Perhaps true.

<snip>

> So, any others?
>
> -G: Colorized output.  I'd be *really* happy to get rid of this, but
>    it's not easy to instate with a filter, so I suppose there are
>    enough people who like it that it will have to stay.
>
> -P: Seems only to be there to cancel a -H or -L.
>
> -W: "Display whiteouts when scanning directories".  I don't even
>    understand what that is.

I was using the link I referenced as my "standard", which doesn't have any 
of those.

I can take or leave color ls.  I don't like the GNU defaults because dark 
blue is TOO dark on my default settings.  I think the flags are adequate 
to know what kind of file I'm dealing with.

> -f: We haven't really discussed this one.  If you want to remove -S,
>    -r and -t, then arguably -f should become the default and be
>    -removed.

I used to use "dir|sort" a lot on PC DOS before it got "dir /o" in 5.0.  I 
wouldn't have a problem with removing sort from ls altogether.

<snip>

> Of course, none of this will happen.  But it is interesting to think
> about it.  In particular, options like -g and -o, which are no longer
> modern.

-uso.

  reply	other threads:[~2020-03-12  3:35 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 18:15 Jon Steinhart
2020-03-03 18:44 ` Adam Thornton
2020-03-04  4:11   ` Tyler Adams
2020-03-04  6:03     ` Dave Horsfall
2020-03-04  6:48       ` arnold
2020-03-04 21:17         ` Dave Horsfall
2020-03-05  0:49         ` Lyndon Nerenberg
2020-03-05 20:54           ` Dave Horsfall
2020-03-05 22:01             ` William Cheswick
2020-03-04 21:50   ` Random832
2020-03-04 23:19     ` Steffen Nurpmeso
2020-03-05  6:12     ` Alan D. Salewski
2020-03-04 22:03   ` Random832
2020-03-04 23:25     ` Terry Jones
2020-03-10 23:03 ` Dan Stromberg
2020-03-11  3:18   ` Dave Horsfall
2020-03-11  4:02     ` Steve Nickolas
2020-03-11 22:56     ` Greg 'groggy' Lehey
2020-03-11 23:14       ` Dan Cross
2020-03-12  0:42         ` Greg 'groggy' Lehey
2020-03-12  0:53       ` Steve Nickolas
2020-03-12  3:09         ` Greg 'groggy' Lehey
2020-03-12  3:34           ` Steve Nickolas [this message]
2020-03-13  1:02             ` Greg 'groggy' Lehey
2020-03-12  5:38         ` Dave Horsfall
2020-03-12  6:48         ` Peter Jeremy
2020-03-12  7:37           ` Steve Nickolas
2020-03-12  7:42             ` Warner Losh
2020-03-12 23:57           ` Greg 'groggy' Lehey
2020-03-12  5:22       ` Dave Horsfall
2020-03-12  5:35         ` Steve Nickolas
2020-03-13  0:36         ` Greg 'groggy' Lehey
2020-03-13 11:26           ` Dave Horsfall
2020-03-14  2:13           ` Greg A. Woods
2020-03-14  4:31             ` Greg 'groggy' Lehey
2020-03-04 14:06 Nelson H. F. Beebe
2020-03-04 16:17 ` John P. Linderman
2020-03-04 17:25   ` Bakul Shah
2020-03-05  0:55   ` Rob Pike
2020-03-05  2:05   ` Kurt H Maier
2020-03-05  4:17     ` Ken Thompson via TUHS
2020-03-05 14:53       ` Dan Cross
2020-03-05 21:50       ` Dave Horsfall
2020-03-05 21:56         ` Warner Losh
2020-03-08  5:26           ` Greg 'groggy' Lehey
2020-03-08  5:32             ` Jon Steinhart
2020-03-08  9:30               ` Tyler Adams
     [not found]                 ` <CAC0cEp8eFRkkLTw88WVaKZoKy+qsrhuC8LkzmmsbqtdZgMf8eQ@mail.gmail.com>
     [not found]                   ` <CAEuQd1D7+dfap98AwPo2W41+06prrcVaAWk3Ve-ve0uQ0xBu3Q@mail.gmail.com>
2020-03-09 21:06                     ` John P. Linderman
2020-03-09 21:22                       ` Kurt H Maier
2020-03-11 17:41                         ` John P. Linderman
2020-03-11 21:29                           ` Warner Losh
2020-03-12  0:13                             ` John P. Linderman
2020-03-12  0:34                               ` Chet Ramey
2020-03-12 12:57                             ` John P. Linderman
2020-03-12 19:24                               ` Steffen Nurpmeso
2020-03-08  9:51             ` Michael Kjörling
2020-03-05  4:57 Doug McIlroy
2020-03-05 22:17 ` Diomidis Spinellis
2020-03-10 16:15 Doug McIlroy
2020-03-10 17:38 ` Dan Cross
2020-03-10 17:44   ` Bakul Shah
2020-03-10 18:09     ` Dan Cross
2020-03-10 18:42 Doug McIlroy
2020-03-10 19:38 ` Dan Cross
2020-03-13 10:45 Dave Horsfall
2020-03-14  4:35 ` Greg 'groggy' Lehey
2020-03-14 19:52   ` John P. Linderman
2020-03-14 20:25     ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.BSF.2.02.2003112321580.82036@frieza.hoshinet.org \
    --to=usotsuki@buric.co \
    --cc=grog@lemis.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).