unix-history-repo VS gnu-units

There is also https://github.com/dspinellis/unix-history-repo (Continuous Unix commit history from 1970 until today)

FWIW, ls in Research-V6 back in 1975 had 10 options. https://github.com/dspinellis/unix-history-repo/blob/Researc...

By BSD 3 in 1980 it had 11 options. https://github.com/dspinellis/unix-history-repo/blob/BSD-3-S...

The thing is, we can see even from the 1970s 'ls' how the Unix model doesn't meet the goal "to chain these simple programs together to create complex behaviors".

There is no option to escape or NUL terminate a filename, making it possible to construct a filename containing a newline which makes the output look like two file entries.

The option for that was added later.

There's also the issue that embedded terminal codes will be interpreted by the terminal.

This is what it looked like about 7-8 years earlier: https://github.com/dspinellis/unix-history-repo/blob/BSD-1/e...

RA92 (1989): 16 ms / 8.3 ms.

Note that the RL02 (and V7) and RA92 mentioned in the article are separated by about a decade.

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

The earliest version I could find [1] is already written in C.

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

Here's a 1997 citation for "top cpu processes." It's not as close to the original 1984 release as I would like, but it's better than Wikipedia. https://github.com/dspinellis/unix-history-repo/commit/aee34003d7964653c44c31f5bf6bcf136b32c4f3

> The “why” goes into the PR and more importantly, engineering documentation and inline comments

This just ensures that the “why” is lost when someone comes looking years later.

From experience, SCM metadata is far more durable than just about any other work product we produce. Five decades later and RCS commit info was still available for the Unix sources, and history could be reconstructed: https://github.com/dspinellis/unix-history-repo

I’ve used 35-year-old commit messages to help understand a long-standing issue, decades after all other related organization tooling and data had disappeared.

P.S. I remember I looked into early versions of C (they survived in Unix historic releases) and that, finally, revealed to me why C does something really stupid and conflates arrays and slices (pointers). Initially C had no arrays! Or, rather, what it called arrays were, actually, pointers. “Normal” arrays were added at some point, but because these weird slices/pointers were already there that caused endless confusion. It wasn't resolved before C became popular and after that it was too late. Go repeated that mistake with slices, of course.

you might want to try units(1).

https://www.gnu.org/software/units/units.html

the input language is less flexible than wolframalpha/google, but i quickly got used to it. it's nice to have something local and reliable. you can also define custom units.

i prefer using it in terse mode:

    $ units -t 0.03$/hr*1month

Yes, units must not be used for currencies, it relies on hardcoded conversion rates. The latest version uses prices from FloatRates (2020-11-15) for most currencies and services.packetizer.com/btc for bitcoin. So while units is very very good for units conversion, it's no good for currencies unless you don't need more than a crude rule of thumb.

Does the GNU projet makes it repositories available online ?

I'd like to have a look at the code but all I found is an outdated mirror : https://github.com/ryantenney/gnu-units