data-store VS unix-history-repo

info on XDG: [the XDG spec](https://standards.freedesktop.org/basedir-spec/basedir-spec-...)

tools that respect XDG, for fellow JS CLI developers:

- https://github.com/davidtheclark/cosmiconfig Find and load configuration from a package.json property, rc file, or CommonJS module. [Check `searchPaths` to implement XDG spec compliance.](https://github.com/davidtheclark/cosmiconfig/issues/152)

- Sindre's libraries use [`env-paths`](https://github.com/sindresorhus/env-paths#pathsconfig) to get paths compliant with this.

- https://github.com/sindresorhus/conf simple config storing (maybe try [conf-cli](https://github.com/natzcam/conf-cli) to manipulate if needed) the successor to [configstore](https://github.com/sindresorhus/conf#how-is-this-different-f...)

- https://github.com/jonschlinkert/data-store conf like datastore but in the shclinkerverse

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.