The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Command line options and complexity
@ 2020-03-03 18:15 Jon Steinhart
  2020-03-03 18:44 ` Adam Thornton
  2020-03-10 23:03 ` Dan Stromberg
  0 siblings, 2 replies; 68+ messages in thread
From: Jon Steinhart @ 2020-03-03 18:15 UTC (permalink / raw)
  To: tuhs

OK, this should be good for some conversation.  A friend sent me this
link today: http://danluu.com/cli-complexity/

^ permalink raw reply	[flat|nested] 68+ messages in thread
* Re: [TUHS] Command line options and complexity
@ 2020-03-04 14:06 Nelson H. F. Beebe
  2020-03-04 16:17 ` John P. Linderman
  0 siblings, 1 reply; 68+ messages in thread
From: Nelson H. F. Beebe @ 2020-03-04 14:06 UTC (permalink / raw)
  To: tuhs

Arnold Robbins writes:

>> There was no tac in V7 Unix. It was first posted to USENET, I don't
>> know by who, and picked up by Linux and *BSD.

That brought back memories, and to verify them, I checked the tac.c
source code in the latest GNU coreutils test release.  It says

/* Written by Jay Lepreau (lepreau@cs.utah.edu).
   GNU enhancements by David MacKenzie (djm@gnu.ai.mit.edu). */

So my memory was right that my old friend Jay was the author.  Sadly, 
we lost him in September 2008: see

	https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifestory&pid=117597321
	
Jay founded the influential Flux group in advanced networking research:

	http://www.flux.utah.edu/profile/lepreau

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 68+ messages in thread
* Re: [TUHS] Command line options and complexity
@ 2020-03-05  4:57 Doug McIlroy
  2020-03-05 22:17 ` Diomidis Spinellis
  0 siblings, 1 reply; 68+ messages in thread
From: Doug McIlroy @ 2020-03-05  4:57 UTC (permalink / raw)
  To: tuhs

> These go all the way back to v7 unix, where ls has an option to reverse
the sort order (which could have been done by passing the output to tac).

A cool idea, but tac was not in v7. And tail didn't get the -r
option until v8.

As for rev, I don't know why it was first written, but one
use was to examine suffixes--a kind of thing that several
word lovers in the Unix lab were prone to do.

Apropos of using rev to make rhyming dictionaries, Walker's
Rhyming Dictionary was published decades before Noah
Webster's dictionary appeared and stayed in print
for about 200 years. Notionally the relation between
webster and walker is
	rev <webster | sort | rev >walker

Doug

^ permalink raw reply	[flat|nested] 68+ messages in thread
* Re: [TUHS] Command line options and complexity
@ 2020-03-10 16:15 Doug McIlroy
  2020-03-10 17:38 ` Dan Cross
  0 siblings, 1 reply; 68+ messages in thread
From: Doug McIlroy @ 2020-03-10 16:15 UTC (permalink / raw)
  To: tuhs

> The idea of a simple rule is great, but the suggested rule fails on sort -u
> which afaik came after sort | uniq for performance reasons.

As the guilty party for most of sort's comparison options, I can
attest that efficiency was not an objective of -u. It was invented
precisely because uniq had proved useful, but not when one was
interested in uniqueness only of some key aspect of the data.

-u differs from uniq in that -u selects samples based on
equality of keys, not equality of lines. In the default
case of whole-line keys, sort -u of course does exactly
what sort|uniq does.

For many applications of -u with keys, the non-key fields
are not of interest. Then sed s/nonkeys//|sort|uniq may
suffice. But sed did not exist when -u was invented.
And not all sort key specs are easily imitated in sed.

Doug

^ permalink raw reply	[flat|nested] 68+ messages in thread
* Re: [TUHS] Command line options and complexity
@ 2020-03-10 18:42 Doug McIlroy
  2020-03-10 19:38 ` Dan Cross
  0 siblings, 1 reply; 68+ messages in thread
From: Doug McIlroy @ 2020-03-10 18:42 UTC (permalink / raw)
  To: tuhs

> This begs questions of stability

Astute question. I had that in my original draft, but eliminited
it for what I thought was clarity. Anyway, depending on implementation
of sort, you may need sort -s. Of course it doesn't matter which copy
among several equal lines uniq produces, nor does it matter in sort 
when there are no comparison options--they're all the same.

> I don't know enough about the
> internals of sed to know even what algorithm it uses 
> (... a disk-based merge sort?)

sed is not a sorting program--basically it copies input to     
output, making line-by-line editing changes. That's the       
way I meant to use it in sed s/nonkeys//|sort -keys|uniq.
(I have added options to sort, hopefully for clarity).
The argument to sed here means substitute the empty
string for the nonkey fields (specified by a regular expression).


If "sed" was a typo for "sort", all versions of sort that
I know of use an internal sorting algorithm for big chunks
of the file, then combines the chunks by merge. But internal
sorting varies all over the map--variations on quicksort,
radix sort, merge sort, ...

Doug

^ permalink raw reply	[flat|nested] 68+ messages in thread
* Re: [TUHS] Command line options and complexity
@ 2020-03-13 10:45 Dave Horsfall
  2020-03-14  4:35 ` Greg 'groggy' Lehey
  0 siblings, 1 reply; 68+ messages in thread
From: Dave Horsfall @ 2020-03-13 10:45 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Meant for the list (and don't get me started on Reply All)...

-- Dave

---------- Forwarded message ----------
Date: Fri, 13 Mar 2020 21:43:51 +1100 (EST)
From: Dave Horsfall <dave@horsfall.org>
To: Greg 'groggy' Lehey <grog@lemis.com>
Subject: Re: [TUHS] Command line options and complexity

On Fri, 13 Mar 2020, Greg 'groggy' Lehey wrote:

>> -h is a gnuism, isn't it?
> 
> It might have originated there, but then I would expect it to be spelt 
> '--produce-human-readable-output'.  I haven't been able to establish from the 
> FreeBSD sources or commit logs when it was introduced.  It would clearly have 
> been a reimplementation.

It's in "df" as well, praise Cthulu:

     aneurin# df -h
     Filesystem     Size    Used   Avail Capacity  Mounted on
     /dev/ad0s1a    496M    302M    154M    66%    /
     devfs          1.0K    1.0K      0B   100%    /dev
     tmpfs          1000    272K    999M     0%    /tmp
     /dev/ad0s1d    2.9G    1.4G    1.2G    54%    /usr
     /dev/ad0s1e    989M    581M    329M    64%    /var
     /dev/ad0s1f    3.9G    2.2G    1.4G    62%    /home
     /dev/ad0s1g    8.9G    8.0G    127M    98%    /usr/local
     fdescfs        1.0K    1.0K      0B   100%    /dev/fd
     procfs         4.0K    4.0K      0B   100%    /proc

(Memo to self: see where all the room has gone in /usr/local, as that's where I 
assigned the leftover space after the other partitions.)

No, I've never liked stuffing everything under the root file system as both the 
Mac and Penguin do; fill the root file system and you're hosed (and I also have 
an itch about /tmp being there as it's a world-writable directory).

>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html does
>> specify the -S switch.  That's POSIX, isn't it?
> 
> So it is!  This was the first option that I wanted to add, back when I still 
> had practice wheels.  I asked my mentor, and he said "not the Unix way", so I 
> let it be.  Then Wes Peters came up with the idea, and I thought he committed 
> it, but it seems that it ultimately came from Kostas Blekos in 2005, based on 
> the same feature on NetBSD and OpenBSD. I wonder when it made it to POSIX.

Years ago I wrote a simple script "lss" which did the sort after being
howled down on one of the FreeBSD lists; what a surprise to see "-S"...

Heck, back in my UNSW days I suggested extending stty() to cover non-TTY 
devices and got trashed by the AGSM/ElecEng mob; well well, look at ioctl() 
when it appeared.

-- Dave

^ permalink raw reply	[flat|nested] 68+ messages in thread

end of thread, other threads:[~2020-03-14 20:26 UTC | newest]

Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-03 18:15 [TUHS] Command line options and complexity 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
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

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