I sent it off list to Chet and Paul but it's too big for Warren's
reflector. I'll work with him to get it separately. If anyone else wants
it before, please let me know off list.
Clem
On Mon, Mar 16, 2020 at 10:37 AM Clem Cole <clemc(a)ccc.com> wrote:
> Here you go...
>
> Warren - Would please be able to add to the docs/paper directories...
> USENIX Summer 1985 June 11-14
>
Hi,
Would anyone know how the CSRG made available updates to the public
distribution of Net/2 before releasing 4.4 BSD Lite?
Net/2 was released on tape in July 1991 as represented in the TUHS
archive. The first mention I see of the sources appearing online is old
usenet posts announcing the bsd-sources mirror on uu.net starting in
January 1992.
However, the Net/2 derived versions of NetBSD (0.8-0.9) and FreeBSD
(1.0-1.1.5.1) imported userland tools revised after both dates in early
1993, when there are also mentions of using 4.4 code in the commit logs
(well before Lite 1 was released in March 1994).
At this point, I'm wondering if the latest code was issued on tape at the
time of a request for Net/2 sources and there were direct uploads from
the CSRG to any online mirrors before the USL lawsuit?
Thanks,
Dan Plassche
--
Dan Plassche
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(a)horsfall.org>
To: Greg 'groggy' Lehey <grog(a)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
> -,: Make the option standard: output numbers with commas every 3 digits
A terrible idea. Whatever ls outputs should be easy for other
programs to read, and few know how to read commafied numbers.
As others have mentioned, this is also a strong argument for
changing the output representation of dates.
I often do mailx -H | sort -t/ -k2nr to sort in reverse order of size--a
quick way to find the pay dirt when I want to shrink my mailbox.
This would never fly if the sizes had commas. (Well, I suppose I
could add sed s/,//g to the pipeline.)
Doug
Nothing I'm aware of. I didn't mind throwing "tac" over the wall, because
it was trivial, probably a couple hours work for me, under a minute for
Ken. But the rsort source is not at all trivial, and still of potential
value to AT&T.
The source managed to get out as part of the "Hancock" project. I found a
link in
https://www.wired.com/2007/10/att-invents-pro/
but the page is gone. It probably didn't help that Wired titled the article
*AT&T Invents Programming Language for Mass Surveillance*
That's horse-pucky, akin to "Pitchfork makers invent device for spearing
babies". I'm trying to track down a copy that was released publicly. I'm
not hopeful.
On Mon, Mar 9, 2020 at 11:28 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
> Woah, this sounds really useful, is there anything like it today?
>
> On Sun, Mar 8, 2020, 16:32 John P. Linderman <jpl.jpl(a)gmail.com> wrote:
>
>> In the "UNIX SYSTEM" issue of the BSTJ back in October of 1984, I
>> suggested that it might be better, both for functionality *and*
>> performance, to have a sort that only worked on records with a *single*
>> key to be sorted *lexicographically*, and put all the complexity of
>> dealing with native integers, dates, case-mapping, etc into a key-building
>> front end. I wrote such a sort built around a radix sort. The sort
>> itself sported very few options relating to record format (fixed-length,
>> newline terminated, and header-based, where an ascii header identified
>> record length, and, optionally, key position and key length), where to find
>> the key in fixed-length and newline terminated records, merge-only, check
>> sort order only, unique, strip off the sort key (to avoid the need for a
>> post-process in many cases). Key-building was usually near-trivial using
>> awk or perl or a few commands for tweaking native integer and floating
>> point values so they would sort lexicographically. The sort was stable and
>> blazingly fast. Some summer students once complained to me that I was
>> messing up a paper they were writing because my external sort was faster
>> than an internal qsort... the kind of complaint that warms one's heart. At
>> the back of my mind was a generic key-building library that would
>> accommodate (decimal) numbers of arbitrary length, with or without "E"
>> exponents, dates in various formats, string collation for Unicode, etc. It
>> remains at the back of my mind.
>>
>> On Sun, Mar 8, 2020 at 5:32 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
>>
>>> 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.
>>>
>>> Another idea on the same vein is that a flag should be added only when
>>> the job can be done inside the program and not with stdin/stdout (or no
>>> flag can be added if one can reproduce the same behavior using pipelines).
>>>
>>> So, you need sort -u because only within sort can you get the
>>> performance needed to get the job done.
>>>
>>> But you don't need -h in ls -lh. All the information to render a human
>>> readable number is present on stdout of ls -l. You could easily have a
>>> filter which renders numbers with options like adding commas, dots,
>>> scientific notation, precision, money, units, etc.
>>>
>>> Tyler
>>>
>>> On Sun, Mar 8, 2020, 07:33 Jon Steinhart <jon(a)fourwinds.com> wrote:
>>>
>>>> After following this discussion, I guess that I have a simplistic way to
>>>> determine whether something should be a dash option or a filter. In
>>>> general, I'd make a filter if whatever it was doing was applicable to
>>>> more than one command, a dash option otherwise.
>>>>
>>>> Jon
>>>>
>>>
On (post-)V10:
echo '.EQ
define f % $1 %
f("a,b")
.EN' | eqn
emits
.lf 1 -
.EQ
.ds 11 "\f2a,b\fP
.if 1m>\n(.v .ne 1m
.rn 11 10
\&\*(10
.EN
.lf 5
On a Linux system with GNU eqn (groff) version 1.22.3,
the output is rather more verbose (48 lines!), but
the troff result is just an a (rather than the proper
a,b) and eqn complains
eqn:<standard input>:3: newline before end of quoted text
I assume this Linux result is more or less what Doug
expects.
Norman Wilson
Toronto ON
(still heating my basement with a MicroVAX)
I was surprised that eqn parses the macro call below as having two
arguments, each with an unmatched ".
.EQ
define f % $1 %
f("a,b")
.EN
Ralph Corderoy found that the comma can be hidden by replacing it with
\N'44'. A somewhat cleaner way to hide it is
.EQ
define f % $1 %
define comma % , %
f(a comma b)
.EN
This works too.
.EQ
f(f(a comma b))
.EN
[Note for cognoscenti. Eqn's practice in expanding macro arguments clashes
with troff's. Eqn expands nested calls after substitution in the outer
macro definition; troff expands while collecting arguments of the outer
call. I've found no documentation of the eqn behavior.]
The classical man page for eqn asserts categorically, `Strings enclosed
in double quotes " " are passed through untouched.' Unfortunately the
version of Kernighan/Cherry User's Guide that describes macros with
arguments says little about how arguments are parsed except that they
are separated by commas--nothing about whether commas are hidden by
parentheses or quotes.
Certainly splitting at a comma in a quoted string violates the plain
meaning of the man-page assertion. If anyone has v10 (or perhaps something
else after v7) running, I'd be grateful to learn what classic eqn actually
did. I'm morally certain that if it did split and anyone had complained
to Brian, he would have fixed it.
These observations lead me to file a bug report.
Doug
> 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
> 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
