~nabijaczleweli/voreutils

053cda8c055c0af30483b7e650ad45d4b649b1a7 — наб a month ago ddaf17c
TODO: re-visit the early utilities' pages
3 files changed, 11 insertions(+), 7 deletions(-)

M .builds/sid.yml
M README.md
M voreutils.sublime-project
M .builds/sid.yml => .builds/sid.yml +1 -1
@@ 34,7 34,7 @@ tasks:
      git commit -m "Manpage update by job $JOB_ID" || exit 0
      while true; do
        git push && break
        for _ in $(seq 0 10); do
        for _ in $(seq 10); do
          sleep 3
          git fetch
          git rebase

M README.md => README.md +9 -5
@@ 4,7 4,7 @@ Drop-in Policy-compatible coreutils replacement, at the very least.
This probably wants a better blurb.

GNU coreutils provide the following 105 binaries, according to `dpkg -L coreutils | grep bin/` on Buster (8.30-3):
  * ☑ /bin/cat – actually faster for raw catting to/from pipes, `splice(2)`s by default
  * ☑ /bin/cat – actually faster for raw catting to/from pipes and to/from files, `splice(2)`s and `copy_file_range(2)`s by default
  * ☑ /bin/chgrp
  * ☐ /bin/chmod
  * ☑ /bin/chown


@@ 95,11 95,11 @@ GNU coreutils provide the following 105 binaries, according to `dpkg -L coreutil
  * ☑ /usr/bin/tee – `--output-error` is [multiple levels of wrong](//bugs.debian.org/991887)
  * ☑ /usr/bin/test — see `[`
  * ☑ /usr/bin/timeout
  * ☑ /usr/bin/tr – implements -C as -c and `[=e=]` as `e`: this matches 4.4BSD and GNU tr, but is nevertheless a missing POSIX feature; could also stand to do buffering lower than fgetc/fputc, as ~~I imagine the overhead of calling those for each byte is noninsignificant~~ locked I/O 33MB/s, unlocked I/O 46.6, GNU tr 180-200
  * ☑ /usr/bin/tr – implements -C as -c and `[=e=]` as `e`: this matches 4.4BSD and GNU tr, but is nevertheless a missing POSIX feature; OTOH, POSIX tr appears to think it operates on characters, which is both very optimistic and explodes instantly, is a horrible and confused hold-over from XPG3, and doesn't match historical implementations; implements `[:class:]` properly, unlike GNU tr; could also stand to do buffering lower than fgetc/fputc, as ~~I imagine the overhead of calling those for each byte is noninsignificant~~ locked I/O 33MB/s, unlocked I/O 46.6, GNU tr 180-200; [coreutils: tr: confusing error message w.r.t. backwards c-c set points at nonconformant behaviour](//bugs.debian.org/1012312); [coreutils: tr: tr.1 (and tr --help) falsely claims -t is only valid when translating](//bugs.debian.org/1012447)
  * ☑ /usr/bin/truncate
  * ☑ /usr/bin/tsort – GNU tsort is [turbofucked](//bugs.debian.org/990854), and returns 1 for loops
  * ☑ /usr/bin/tty
  * ☑ /usr/bin/unexpand – flag handling is mildly (very?) different, and matches NetBSD; the tests are (should be) representative and all pass, but i've had [the worst time of my life](//twitter.com/nabijaczleweli/status/1403145708543295493) writing it, so it's entirely possible (if unlikely) it's not 100% bug-compatible
  * ☑ /usr/bin/unexpand – historically, i've had [the worst time of my life](//twitter.com/nabijaczleweli/status/1403145708543295493) writing it, due to [coreutils: unexpand: nonconformantly (to both POSIX and heirloom) replaces single spaces with tabs](//bugs.debian.org/1012545); it also processes bytes, not characters, for some reason; POSIX words tab folding muddily (but see interpretation) + it's unclear non-space/tab blanks are processed (we don't for compat + ease of impl): https://www.mail-archive.com/austin-group-l@opengroup.org/msg09780.html
  * ☐ /usr/bin/uniq
  * ☑ /usr/bin/unlink
  * ☐ /usr/bin/users


@@ 110,9 110,9 @@ GNU coreutils provide the following 105 binaries, according to `dpkg -L coreutil
  * ☑ /usr/sbin/chroot
  * ☑ /usr/bin/md5sum.textutils

TODO: re-visit the early utilities' pages
TODO: import descriptions of the one-line 1BSD-style imports

TODO: multicalls should default to something rather than abort when appropriate like netbsd id(1) maybe?
TODO: multicalls should default to something rather than abort when appropriate like netbsd id(1) maybe? This is already what we do with `cksum`.

TODO: should posix_fadvise(sequential) where appropriate maybe?



@@ 126,6 126,8 @@ TODO? does "UNIX Programmer's Manual" want to have some part/entirety `.Tn`ed

TODO: some sort of consistent uid/gid/pwent/grent caching?

TODO: probably want to generate each locale at most once

## Building
You'll need a non-ancient C[++] toolchain, a POSIX AWK, GNU make, and mandoc (linting and HTML manuals only, `MANDOC=true` to disable).



@@ 186,6 188,8 @@ wrap them in braces (`.el \{ [text] % eqn % [text] \}`).
## Tests
Need to be attached to a teletype. Use `script(1)`, for example, if the test environment doesn't allocate one by default.

Test data is compacted *per data directory* w/`find -exec b2sum {} + | sort | mawk '{h = substr($0, 1, 128); fn = substr($0, 1 + 128 + 2);  if(h == hash) {tgt = "." fname; split(fn, curs, "/"); if(curs[2] == fnames[2]) tgt = fnames[3];  print "ln -sf -- \"" tgt "\" \"" fn "\""} else {hash = h; fname = fn; split(fname, fnames, "/")}}' | sh`.

## Compatibility
Free UNIXes, hopefully.
Debian, OpenBSD, and FreeBSD are on CI, as normal, bare, and [fucked](//bugs.freebsd.org/bugzilla/show_bug.cgi?id=256486) baselines, respectively.

M voreutils.sublime-project => voreutils.sublime-project +1 -1
@@ 26,7 26,7 @@
		},
		{
			"follow_symlinks": true,
			"name": "Manpages",
			"name": "Manuals",
			"path": "man"
		},
		{