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.
next prev parent 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).