boreutils

GNU coreutils, rewritten in pure wolf, one program at a time.

Each utility aims to be a drop-in replacement for the behaviour that users and scripts rely on. Where wolf allows it, each also aims to be faster than GNU. Speed is measured per utility and never promised. GNU's cat and wc are already fast, so beating them counts as a finding, not as a requirement.

Why

• A second large production wolf codebase, after lobo. The project is dozens of small, complete programs, each with one job. That makes it a good shape of wolf to learn from, whether you are a reader, a new contributor or a model.
• Pressure on the OS and IO surface. Coreutils need argv, exit codes, streaming byte IO on stdin, stdout and files, SIGPIPE, permissions, users and time. When a utility hits a gap in wolf, the gap is filed upstream with a witness.
• Verifier-backed data. GNU coreutils is the behavioural oracle. Every boreutils program is differential-tested against it.

The licence rule

boreutils is GPL-3.0-or-later (see LICENSE). The wolf Training Data Permission (see LICENSE-TRAINING-DATA) lets you train models on this repository's text and ship excerpts of it in datasets under CC BY 4.0.

GNU coreutils source is never read, copied or translated here. It is GPL-3.0 and owned by the FSF, so a translation of it would be a derivative that this project does not wholly own. Each utility is written from these sources only:

• the POSIX.1-2024 utility specification;
• GNU's documented behaviour: --help, the info manual's option descriptions, and black-box runs of the GNU binary;
• the permissively licensed implementations, as design references only: uutils/coreutils (MIT) and toybox (0BSD).

The header of each utility records which of these references were consulted.

Building it

The toolchain is pinned by digest and fetched, never built:

tools/fetch-toolchain     # wolf + lupin release archives, sha256-checked
tools/fetch-oracle        # GNU coreutils 9.11, sha256-checked, if needed
tools/build               # every utility into target/release/
tools/difftest            # the differential suite against the oracle
tools/texttest            # shuffle shape plants and bounded codec round-trips
tools/killtest --gnu DIR  # kill where it sends: a throwaway container a case
tools/killprobe --gnu K P # kill -l and -t of every number 0..140000 and a sample above, against GNU
tools/timeouttest --gnu DIR # timeout where it runs a command: a throwaway container a case
tools/idtest --gnu DIR    # the identity tools as root and as users: the same
tools/bench --scale 0.01  # hyperfine against GNU on generated inputs

GNU coreutils is the oracle and must be installed: natively on linux, brew install coreutils on macOS, where the harness uses the g-prefixed names. It must be the version gnu-oracle.toml names, and tools/difftest says so and stops when it is not — see The oracle of record below. Since kill (bu23) an installed coreutils is not enough on any host: no distribution's package holds coreutils' own kill (the one on your PATH is procps' or util-linux's, and the one your shell runs is its builtin), so tools/fetch-oracle builds the oracle with it and tools/difftest refuses any other kill.

Windows is out of scope: the oracle of record is a unix build of GNU coreutils, and CI runs on linux and macOS. (The reason used to be that the only byte-exact route to standard input and output was reopening /dev/stdin and /dev/stdout; since wolf 0.2.26 boreutils reads descriptor 0 and writes descriptor 1 directly, bu19.)

Standard output, and the exit convention

Every boreutils program writes through one shared buffered writer, and honours one convention, stated in full at the top of src/bore/bore.lu and measured black-box against GNU:

• A write that fails is status 1 and one diagnostic. `basename a/b

  &-isbasename: write error: Bad file descriptor`, exit 1, exactly as GNU's is.

• Writing nothing never fails. true >&- is 0 and false >&- is 1, because neither writes a byte; true --version >&- is 1.
• A broken pipe is not the program's business. yes | head -1 dies of SIGPIPE with status 141 and an empty stderr on both sides. wolf cannot observe or ignore SIGPIPE at all (wolf-lang#423), and for this shape the default disposition is the right answer, so nothing here works around it.

The reason is the host's. Since wolf 0.2.26 (os_error, os_error_text, bu19) the text after a failed write or read is the host's own strerror, as GNU's is: a full disk is write error: No space left on device on both sides, and every /dev/full case compares stderr. A program that reports after other fs calls keeps the host's number from the moment of the failure (bore.host_code), because the next successful call clears it. And standard output is descriptor 1 itself, so a socket is written like any other descriptor (until 0.2.26 linux refused the /dev/stdout reopen for a socket and output fell back to print_raw, which discards write errors, wolf-lang#408).

The oracle of record

gnu-oracle.toml names the GNU coreutils release boreutils is drop-in for. It is 9.11, and it is the pin that makes "drop-in" mean something: GNU releases differ from each other, ubuntu-latest ships 9.4 where Homebrew and Arch ship 9.11, and a differential suite whose verdict depends on which host ran it is a matrix rather than an oracle.

• tools/difftest asserts the version and returns no verdict against any other. BORE_ORACLE_ANY=1 runs anyway and says on every run that the result is information.
• tools/fetch-oracle installs the oracle by sha256 digest where the host does not already ship it, with the configure line the pin file names. CI does this and caches it.
• Where an older GNU still in the field behaves differently, the case names the range it describes with gnu_min / gnu_max, and CI's non-blocking field job runs the distro's own GNU so those ranges stay honest.

The pin is a version AND an environment (B73). Two builds of one coreutils release disagree about the obsolete +N operand form — Arch's tail +3 reads "from line 3" and Homebrew's reads +3 as a file name — because gnulib decides it from a value configure compiles in. A pin file cannot name a build nobody published, and it does not have to: $_POSIX2_VERSION overrides that value at run time, so [oracle.env] in gnu-oracle.toml pins it beside LC_ALL, and every build answers the same. [oracle.probe] then runs one command whose answer the build-time default decides — uniq +1 /dev/null — and tools/difftest refuses a verdict when the answer is not the one the pin file declares, exactly as it refuses one against the wrong version. On the field leg the probe is reported rather than enforced, which is how B73 was found in the first place.

What that does NOT close is the other half: divergences that are the two hosts' C LIBRARY rather than coreutils at all — seq -f %a, the strerror(ERANGE) wording, the width table — and a build identity would not have helped there either. Those stay recorded skips.

A death on the field leg is loud, a difference is not (B98). The leg used to carry continue-on-error on the whole job, which made it non-blocking about everything including its own death: it had been dying of signal 13 with a partial report and reporting success. The advisory now sits on the differential step alone, and tools/field-verdict decides what an exit code means — 0 quiet, 1 an advisory, a signal death or a harness refusal LOUD. tools/field-verdict-selftest gates that, planting a real SIGPIPE death of the harness on every CI run.

The oracle is a binary we run, never a source we read; building it derives no boreutils code from GPL source.

Status

Every shipped utility below is byte-for-byte identical to GNU coreutils 9.11 on its differential corpus, except where a case says otherwise and is skipped with its reason. The corpus holds 8,162 cases; kill has 365 more that SEND, each run in a container of its own (tests/kill/, tools/killtest: 365 passed, 0 failed on hasu at bu30, groups, kill 0 and kill -1 among them), timeout 163 more that run a command (tests/timeout/, tools/timeouttest: 150 passed, 0 failed on hasu at bu30, and 13 skipped there: twelve that need a core written as a file, which run on CI's ubuntu runner, and one of macOS's), and the six identity tools 1,126 more that run as root and as users or change an owner (tests/ids/, tools/idtest: 28 of them only on CI's macOS runner). The text-tool measurement in an unprivileged Ubuntu 24.04 container on hasu (linux x86-64, CPUs 0–5), at wolf 0.2.35 / lupin 0.1.56 with bundled std 2386522e, answers 8,005 passed, 0 failed, 157 skipped on both release and dev (before: 7,020 / 0 / 130). Six utilities add 1,012 cases: 985 pass and 27 explicitly name the two refused behaviours below. Random mktemp names are checked by fixed prefix, suffix, replaced X count, alphabet, object kind and private mode, never compared byte for byte. tty has standard-input pty cases, separate from standard-output ptys.

The newest tools are base64, base32, comm, join, tsort and shuf. Both codecs stream in bounded chunks, including malformed padding and decode groups split across reads. comm supports suppressed columns, custom delimiters, order diagnostics and totals; join supports selected fields, Cartesian groups, unpaired records, headers and automatic output fields. Comparisons are under LC_ALL=C. These two merge tools currently retain their records in memory. shuf checks compare sample count, membership and multiplicity independently on each side, including output files, never random order. It supports the full unsigned 64-bit input range. Head counts saturate at INT64_MAX (9,223,372,036,854,775,807), independently of the unsigned range endpoints. It refuses --random-source by name: GNU's general byte-draw rule has not been derived. tsort matches GNU's byte order on all 29,849 labelled DAGs of three through five nodes and 36,815 edge-order variants, and supports simple/disjoint cycles. Once all zero-indegree nodes have been emitted, a cyclic residual must have exactly one live incoming and one live outgoing edge per node; complex cyclic components and cycles with outgoing tails are refused by name. The measured GNU answers and those refusals are retained in notes/bu31/refusals.jsonl.

The pin alone preserved 6,668 / 0 / 120 on both tiers, as at 0.2.34 (bu29, notes/bu29-the-pin-0234.md). The container-suite figures above were re-measured on hasu; inouttest is 104 / 0 / 0 and roottest 178 / 0. timeout now disables its own core with os_core_off() before re-raising; the three core rows compare directly with GNU, with -s 33 still a named design difference. The edition before bu28 said 6,784 cases and 6,664 passed, 0 failed, 120 skipped at wolf 0.2.32, and tools/timeouttest 124 passed, 0 failed (bu27's figures are in notes/bu27-the-groups.md). The edition before bu27 said 6,645 cases and 6,383 passed, 0 failed, 262 skipped, and tools/killtest 338 passed, 0 failed (bu24's and bu26's figures are in notes/bu24-the-ids.md and notes/bu26-the-kill-cases.md). The edition before bu24 said 6,514 cases and 6,252 passed, 0 failed, 262 skipped, and tools/killtest 335 passed, 0 failed (bu23's figures are in notes/bu23-the-kill.md). The edition before bu23's kill said 5,646 cases and 5,527 passed, 0 failed, 119 skipped (bu22's figures and CI's are in notes/bu22-the-modes-and-links.md and its PR). The edition before bu22's chmod, touch, ln, mkdir -m and cp -p said: a run on kasumi (linux x86-64) at this pin answers 4,476 passed, 0 failed, 118 skipped of 4,594, the same list on the release and the dev tier, and CI's macOS leg skips the /dev/full and /proc cases besides, because macOS has neither, and the cases that print an owner's NAME, because a Mac's accounts are not in /etc/passwd: run 38124071375 answers 4,477 and 117 skipped on ubuntu and 4,337 and 257 skipped on macOS, none failed (bu21's figures are in notes/bu21-the-file-changers.md). (The previous edition of this sentence, before bu21's five utilities that change the file system, said 3,855 cases, 3,788 and 67 on kasumi, and 3,789 and 66 on ubuntu and 3,649 and 206 on macOS, run 38116093735; before bu20's long format and its three utilities, it said 3,077 cases, 3,017 and 60 on kasumi; before bu19, 3,048 cases, 2,986 and 62; before bu18's ls it said 2,674 cases, 2,642 and 32 on kasumi, and 2,618 and 56 on macOS, run 37060771131; before bu14's six utilities it said 2,114 cases, 2,094 and 20 on kasumi, and 2,077 and 37 on macOS, run 36044150121; before that it said 1,753 and 19 for the 1,772-case corpus, and "five more" on macOS; kasumi answered 1,752 and 20 at that commit, eac2a32, and macOS 37 at that lane's first green, run 36029854007.) The corpus and the run are stated separately on purpose: an earlier edition of this paragraph called the passing count the case count, which quietly subtracted the skips from the corpus instead of naming them.

Two wc cases are skipped and say why in the case file: two code points whose display width the two hosts' own wcwidth disagree about. (Two more, the ENOTDIR and ELOOP reasons, ran once wolf 0.2.26 put the host's error number beside the row, bu19.) Five more run only on a host with /dev/full, which is how a write error on a LIVE descriptor is reached at all, and so are skipped on macOS. Ten wc cases name the GNU version they describe with gnu_min — those are a record of the field, not of the oracle, which is 9.11 everywhere the gauntlet runs. The ninth was found by the field leg on the first run it ever made: with descriptor 1 closed, 9.11 stops at the first write that fails and 9.4 keeps walking, so wc FILE nope >&- names the missing file on 9.4 and not on 9.11. The tenth is bu19's: into /dev/full 9.11 names the reason and 9.4 says a bare write error. Sixteen more name 9.11 for the same reason, all bu14's: 9.4 has no %N$ in printf at all, takes an empty number without a word, and refuses an nproc --ignore past 2^64. Eight more are bu18's ls: 9.4 has no --sort=name, lists the --sort words in another order, and does not sort by --time=mtime alone.

The transform set adds eight more skips, all the same shape, and none of them a coreutils version difference. They are places where the two hosts' C LIBRARIES disagree at one coreutils release, or where GNU's long double gives an answer exact arithmetic does not: seq -f %a, seq 1 1 1e400, seq 1e30 … and two long-double stalls, nl -w 0's strerror(ERANGE) wording, and one BRE construct nl here does not implement. Each names both hosts' answers in its own skip line.

It used to be nine, and uniq +1 was the ninth. That one was a BUILD-TIME POSIX2 setting rather than a release, so Arch read +1 as "skip one character" and Homebrew as a file name; tail +3 was skipped for the same reason. Both are ordinary cases now, because the oracle pins the environment that decides it (B73, above). The text-tools milestone adds four skips of its own and no more: two fold -w values that are numbers OUT OF RANGE, where GNU appends the C library's strerror(ERANGE) and the two hosts word it differently — the same shape as nl -w 0 — and two tac -r expressions, \(…\) and \|, that are outside the regular-expression subset that utility states in its header.

The small-surface set adds twelve skips, and not one of them is a C library's. Each is a wolf 0.2.25 gap, filed with a witness and named in the case file: printenv's four bare listings (wolf lists the environment only sorted, wolf-lang#535), pwd -L beside a cp -a twin of the working directory (no file identity, wolf-lang#536), and tee's seven — five broken-pipe branches of -p and --output-error, and -i twice, all of which need a signal ignored (wolf-lang#423).

ls had thirty skips, every one wolf's, and wolf 0.2.27 answered twenty-eight of them (bu20). s218's fs_stat, fs_lstat, fs_read_link and fs_read_dir_entries give a file's whole record, a link's own identity and target, and the directory's own order, so the long format and what implies it, -s, -i, -u, -c, --time, -U, and every option that must tell a link from its target are ordinary cases now: the file holds 710, and kasumi answers 694 and 16 skips. Six of the sixteen are -f and -aU, where . and .. stand in the directory's own order and the listing call leaves them out (wolf-lang#692: right on btrfs, tmpfs and APFS, wrong on ext4); two are a terminal whose own width is not 80 (wolf-lang#643); one is -Z, a security context (no extended attribute, wolf-lang#685); four are options not written yet (--author, --block-size, --time-style=+FORMAT, -Q), each refused by name; and three are block devices this host does not have.

stat, readlink and env add twenty-one skips, and none is a C library's (bu20). stat's eight: -f twice (no file-system record, wolf-lang#686), - (no record of an open handle, #536), %o (no I/O block size, #684 — the default and terse formats run, with that one field masked on both sides), %C (#685), and three block devices this host lacks. readlink has none. env's thirteen: five listings that start from the inherited environment, which wolf lists only sorted (#535); an entry with an empty name, which os_exec refuses; a script found through an empty PATH component, which sees ./name where GNU's sees name (#689); and six options not written yet (-S, -v, the four signal options), refused by name.

kill adds one skip, a non-UTF-8 argument (#406) (bu27). Until bu27 it added 143 on linux: every case naming a signal the host has and wolf had no meaning for. Since wolf 0.2.31 (s241) a host signal is sent as -N, os_signal_last and os_signal_realtime say how the host numbers them and os_signal_text gives their words, so kill knows every signal the host numbers (linux's STKFLT, POLL, PWR and the real-time range by GNU's names, macOS's EMT, IO, INFO) and -t prints the third column. tools/killprobe holds -l and -t to GNU over 240,578 numbers on both hosts, in every CI run since bu28, with no row by design: since wolf 0.2.33 os_signal_text(0) gives signal 0's words (Unknown signal 0), so the 912 rows a tier that read as signal 0 (EXIT, 128, 256, …), and 84 cases' masks, are gone. The cases that SEND are not skipped: where this kill answers otherwise by design (a kill 0 from process group 1, which wolf never signals), tests/kill/cases.toml states both answers and both are asserted.

timeout adds seven skips, all on macOS, where GNU 9.11 warns setitimer: Invalid argument for a DURATION past its timer's range and this timeout says nothing (bu27). Since wolf 0.2.33 (bu28) it sends its group a fault or host signal (-s SEGV, -s RTMIN, -s 16) as GNU's does, ignoring it first, where it refused them (125); it dies of the signal its command died of, a fault's included, where it exited 139; and it says the monitored command dumped core. It never starts a command on a lane's host: tools/difftest runs only its cases that cannot (usage, invalid durations and signals, 126 and 127), and the rest run in tools/timeouttest.

The file changers add thirty-five skips, and every one is a thing wolf cannot do to a file or an option not written (bu21, bu22). Since wolf 0.2.28 (s230) a mode can be given at creation and changed, a link of either kind made, a time set and the umask read, and chmod, touch, ln, mkdir -m and cp -p are written on them (bu22). mkdir and rmdir have none. chmod has none on linux (on macOS, seven: GNU changes a link's own mode there and wolf has no call for it). touch's thirteen: eleven -d strings GNU's free-form grammar takes and this one does not read — relative items, month names, MM/DD/YYYY — each refused by name rather than guessed at, and touch - twice (times by handle, wolf-lang#714). ln's three: -b, --backup, -S, not written. rm's three: --no-preserve-root twice, refused on purpose, and --preserve-root=all, not written yet. mv's eight: --exchange (no rename that swaps, #706) and seven for -u, -b, -S and --debug, not written yet. cp's nineteen: -a, -d and --preserve=links, xattr, context, all (hard links among the sources are not tracked; no extended attribute, #685); -s and -l, not written; one fifo (#705); five for --sparse and --reflink with anything but auto (#703); and five options not written yet. The OWNER is the one thing cp -p cannot keep (#701): a copy whose owner or group came out other than its source's says so by name, status 1. Every refusal is BY NAME, status 1, and leaves nothing wrong behind. And rm -r / is refused as GNU refuses it, which is run, not read: tools/roottest hands / and its spellings to both tiers of rm in a throwaway container — no mount, no network, as a user and as root inside — beside GNU 9.11, thirty cases with mv's and cp's, a sentinel tree summed before and after (tests/root/cases.toml; CI's ubuntu leg).

"vs GNU" is wall-clock from tools/bench, GNU's time divided by ours, so above 1.00 is faster than GNU. It is a measurement on a stated host, never a promise, and the two hosts do not agree: GNU's yes is twice as fast on linux as it is on macOS, so the same boreutils binary wins on one and loses on the other. Both numbers are below; neither is "the" number.

Release tier, 5 runs, GNU coreutils 9.11. yes writes 1 GiB of y into head -c; the rest start up, write a few bytes and exit.

wc has a table of its own too. Release tier, GNU coreutils 9.11, 5 runs, 256 MiB of generated text under LC_ALL=C, nomad-1 at load 13.9 and kasumi idle.

wc is the first utility whose flags had to be benched separately, because each takes a different path, and the first whose locale had to be stated: the C loop reads a byte where the UTF-8 loop decodes a character, and under LC_ALL=C.UTF-8 the same four rows read 0.91x to 0.95x on nomad-1 and 0.71x on kasumi.

Where the work is a byte-at-a-time state machine that GNU cannot vectorize either — -w, and the default counts — wolf is ahead of C. Where GNU reaches for SIMD it wins by a lot: wc --debug -l reports using avx512 hardware support on kasumi, and no bulk byte scan is expressible in pure wolf today (wolf-lang#411, filed with every alternative measured). -c on a file operand is an fstat on both sides, so it measures start-up. Through a redirect GNU fstats and asks the offset, because wc -c owes size minus the current offset; before wolf 0.2.22 we could ask neither and read the whole input (34 ms on 256 MiB). Since bu15 we ask both, and the row is start-up too: 0.43 ms against 0.39 ms, hyperfine 50 runs, kasumi at load 5–7. The size is believed only when two positional reads confirm it, so a sysfs or /proc file, whose size lies, is read and counted as GNU counts it (trunk said 4096 and 0 for two of them, where GNU said 23 and 144).

Read the macOS column with its load. nomad-1 was at load 13.9 with other lanes on it, and contention flatters every ratio there, because GNU's vectorized line counter loses more to a busy machine than our scalar loop does: the same -l comparison read 0.55x at load 6.7. kasumi was idle.

Memory is flat in the size of the input: counting 256 MiB peaks at 5.7 MB of RSS on nomad-1 against GNU's 1.8 MB, and 4.3 MB on kasumi against 2.8 MB, and 16 MiB peaks at the same 5.7 MB. That costs one region per chunk, and about 5% of the time; without it the same count peaked at 271 MB, because the ambient region never frees what each read allocates (wolf-lang#416). -c never reads at all and peaks at 1.7 MB.

cat has a table of its own, because it is the first utility that moves bulk data and the two hosts disagree sharply about it. Release tier, GNU coreutils 9.11, 10 runs (50 for start-up), nomad-1 at load 7.4 and kasumi at load 5.9. The large file is 256 MiB of text; the short-line file is 16 MiB of nought-to-seven-letter lines.

So cat starts up level with GNU on both hosts and loses on bulk copying, by 1.6x on macOS and by 6x on linux. GNU moves the bytes without a round trip through user space where the host allows it, and wolf 0.2.25 exposed neither splice nor copy_file_range, so every byte was read into a list and written back out.

Since wolf 0.2.26 the host does the copy (bu19). cat's plain path is fs_copy_chunk to descriptor 1 (copy_file_range, sendfile, splice, then a loop), wc -l counts newlines with bytes_count, and head, tail, nl, uniq and cut find their lines with bytes_find/bytes_count. kasumi, release tier, GNU 9.11, the bench's full-size inputs, one hyperfine call per row with every build and GNU in it (10 runs; load 4 to 11, other lanes): 0.2.25 is trunk 50d8907, "before" the same tree at 0.2.26 with descriptors 0..2 adopted, "after" the adoption.

Every row and the rest are in notes/bu19-the-byte-surface.md. One row moved the wrong way and it is not the program's: cut on very short lines went from 373 to 546 ms when descriptor 1 stopped being reopened, with the same instructions; the system time is 1,537 brk calls where there were 10, glibc trimming and regrowing the heap as each chunk's region frees, and a malloc tunable makes both builds equal (wolf-lang#644). uniq moved 11% the other way for the same reason.

Memory is level, and flat in the size of the input either way: copying 256 MiB peaks at 2.4 MB of RSS on nomad-1 against GNU's 1.9 MB, and at 2.8 MB on kasumi against 2.3 MB; cat -n peaks at 3.9 MB against 2.2 MB, and at 3.7 MB against 2.7 MB. That costs one region block per chunk — without it the same copy peaked at 340 MB and cat -n at 1.1 GB, because the ambient region never frees what each read allocates.

head, tail and cut have a table of their own, because they are the first utilities where reading the whole file is a defect rather than a style choice. These numbers are linux only: wave 45 forbids builds on nomad-1, so macOS is CI's job and not a column here.

tail and head read from the end since wolf 0.2.22 (bu15, boreutils#19). Until then wolf had no seek, no tell and no positional read (wolf-lang#426), so tail -n 10 of a regular file read all of it and head -n -K held a window over everything. 0.2.22 has all three, and descriptor 0 answers them ([os.fs.std]), so a regular file — named, or standard input that is one — is read from where the answer starts, as GNU reads it. What each program does with each kind of input:

A file whose fstat size cannot be trusted is read forward like a pipe: a sysfs attribute reports 4096 bytes whatever it holds, and a /proc file reports 0, and GNU reads both. bore.verified_end believes a size only when the byte before it exists and nothing exists at it, which is two positional reads.

The head question, answered with a syscall count and not an adjective. head -n 1 and tail -n 10 of a 268,435,456-byte file, strace of the read-family calls on the file's descriptor:

(The head rows and the RSS column are bu03's, whose counts include the dynamic linker. The tail and wc rows are bu15's, strace -y on the input file's descriptor only: boreutils' extra calls are the two positional reads that verify the end before trusting it, and its tail -n 10 copies the last 941 bytes with one more read where GNU writes them from the block it already holds.)

Release tier, GNU coreutils 9.11, kasumi (linux x86-64, 16 cpus), 256 MiB of generated text (16 MiB of short lines where a row says so), hyperfine 20 runs, kasumi at load 5 to 9 with other lanes running (the load at each table's start and end is in bu15's notes). The "before" column is trunk 010f3144 built by wolf 0.2.20, the last release without the seek.

The sub-millisecond tail rows are hyperfine at 50 runs with -N (no shell), because the bench tool's tenth-of-a-millisecond rounding cannot tell 0.21 from 0.31; the rest are tools/bench at 20. tail -n 10 of a file is 366x faster than it was and 1.5x GNU's time, the remaining 0.1 ms being wolf's start-up, not the read: both sides now read about 8 KiB of a 256 MiB file.

The pipe rows did not move, and the A/B says so rather than the tables. Between the two tables the load moved, and so did GNU's own numbers (the -n +1 copy is 29.6 ms and 37.1 ms for the SAME GNU binary). Run back to back, three rounds of 10, the pin without the seek and bu15 read 102.6/104.1/102.2 ms against 102.4/104.0/101.8 ms for tail -n 10 through a pipe. head -n -1 through a pipe first read 8% SLOWER (299 ms against 327 ms): threading a mut sent: int parameter through the window loop to know where to leave the offset cost that, in a loop that never needs it. The window now places the offset once, from the reader's offset less what the window holds, and the A/B reads 303.4 ms against 303.3 ms.

cut is between 0.27x and 0.63x, and two measurements got it there. The first draft pushed every input byte through the shared ring, because the ring is the one buffer that can outlive a per-chunk region, and it read 0.06x; cutting each line out of the chunk it arrived in, and using the ring only for a line that straddles two chunks, is 7x faster. Then -f1 was still 0.09x because it walked every field of every line to the end: stopping at the last field any range names took it to 0.48x. Both are in the git history rather than only in this table.

Memory is flat in the size of the input for all three, at one region per chunk plus a window: 2.8 MB for head -n 1, 2.9 MB for tail -n 10 and 3.1 MB for cut -b1-10 on 256 MiB, against GNU's 2.3–2.5 MB (bu03's measurement). tail's window is the last K lines and head -n -K's is the same, so through a pipe a tail -n 100000 costs what those hundred thousand lines weigh and nothing more; on a regular file there is no window at all.

The transform set — tr, uniq, seq and nl — has a table of its own, and it is the first one taken on ONE host. Wave 45 forbids builds on nomad-1, this project's macOS box, so there is no macOS binary to measure; every number below is kasumi (linux x86-64, 16 cpus) at load 1.3, release tier, GNU coreutils 9.11, 5 runs, 256 MiB of generated text for the tr, uniq and nl rows and 16 MiB of very short lines where the row says so. seq reads nothing, so its rows are a million numbers each, 5 runs.

The predictions were written into the bench files before the first run, and two of the four were wrong in a way worth keeping.

tr -s a-z A-Z is not our win, it is GNU's cliff. Measured on the same file and the same host, 20 runs: GNU squeezes alone in 85 ms and translates alone in 95 ms, and does both in 1585 ms — eighteen times its own squeeze. boreutils does both in one pass over the byte, so it answers in 422 ms whether one is asked for or two, and the ratio is 3.7x with a standard deviation of 1.3 ms on our side. It is worth saying plainly: everywhere else in this table tr is behind, by 0.34x where the loop is a table lookup and a stored byte.

seq splits in two, and the split is the whole design. GNU has a hand-written decimal incrementer for a pure integer sequence, and it is fifteen times faster than anything this project can write today: 4.9 ms against 71 ms for a million integers. The moment the sequence is not a plain integer walk — a fractional increment, -w, a -f format — GNU falls back to a long double add and a printf per value, and exact decimal arithmetic beats that by 1.3x to 2.0x. So the exactness seq promises is not paid for in speed except on the one case GNU special-cases.

What the predictions got wrong. uniq was predicted at 0.4x to 0.6x and measured at 0.35x to 0.61x, which is a hit. The other three missed:

• tr was predicted at 0.6x to 0.9x for bulk work. Translation is worse than that (0.34x) and the translate-and-squeeze row is 3.72x, four times outside the band in the other direction.
• seq was predicted at 0.3x to 0.5x throughout. It is 0.07x on integers and 1.27x to 1.96x everywhere else: wrong in both directions, and the prediction missed that GNU has two paths.
• nl was predicted worst on short lines, because the per-line work is what it pays most for. It is the other way round: the short-line rows are the best ones. The per-BYTE copy, not the per-line work, is what costs — which is the same conclusion head, tail and cut reached, and their lane's measurement is why the numbers above are what they are.

uniq and nl were re-measured after taking the streaming lane's finding. Both first read a line by copying it out of the chunk it arrived in, and nl then built a str from those bytes on EVERY line just to compare it against \:. Cutting each line out where it lies — carrying a line into the boundary buffer only when it actually straddles one — and comparing the delimiter as bytes moved seven of the eight rows, one of them past GNU:

Neither utility uses the ring head, tail and cut share: what a line straddling a chunk needs here is one buffer that outlives the chunk, and that is a first-class region (let keep = region()) written through in keep { }, which is cheaper than a ring for a boundary that is crossed once per megabyte.

Memory is flat in the size of the INPUT and linear in the longest LINE. Peak RSS over 256 MiB, ours against GNU's: tr 6.9 MB against 2.2 MB, uniq 9.0 MB against 2.2 MB, nl 10.5 MB against 2.4 MB, and seq 3.3 MB for a three-million-number sequence against 2.3 MB. That costs one region per chunk read, and, in uniq and nl, a FIRST-CLASS region (let keep = region()) holding the one or two buffers that must outlive a chunk, written through in keep { } and overwritten in place rather than rebuilt. On a single 64 MiB line with no newline in it, where that bound is the line and not the chunk, uniq peaks at 527 MB against GNU's 70 MB and nl at 398 MB: the line is materialized six to eight times over on the way through, and GNU holds one copy.

The text-tools set — tac, paste, fold, expand and unexpand — finishes B3, and its table is the first in this repository where wolf is AHEAD of GNU on most rows. kasumi (linux x86-64, 16 cpus) at load 2–5, release tier, GNU coreutils 9.11, 5 runs, 256 MiB of generated text and 16 MiB of very short lines. Wave 45 forbids builds on nomad-1, so there is no macOS column.

The predictions were written into notes/bu07-the-pin-and-the-rest-of-b3.md and the bench files before anything was measured, and four of the five were wrong.

At wolf 0.2.25, unexpand lost about a third of its lead (wolf-lang#624, bu17). The program did not change, and its hot function's IR did not change either. The release tier's codegen partition moved flush_run into the same unit as the loop that calls it. That happened because unrelated functions grew. With the callee's body visible, clang compiles the loop into code that runs 14% more instructions and 63% more cycles. The measurement is kasumi, GNU 9.11, the bench's full-size inputs, and 0.2.23 and 0.2.25 in one hyperfine run:

At wolf 0.2.26 the loss is gone, and not because anything fixed it (bu19). In one hyperfine run at load ~4.5, boreutils trunk 50d8907 at 0.2.25 and the same tree at 0.2.26 run unexpand on ordinary lines in 2820 ms and 2929 ms against GNU's 6547 ms (2.24x), with identical user instructions (62.17 G) and a one of 689 instructions, 0.2.23's count rather than 0.2.25's 710: the partition no longer puts flush_run beside it. unexpand.lu did not change; the shared bore module did (bu18's ls). The fragility wolf-lang#624 names stands, and the issue carries the measurement.

tac is the one that loses, and the reason was tail's reason. GNU seeks to the end of a regular file and walks backwards through it; until wolf 0.2.22 there was no seek, no tell and no positional read (wolf-lang#426), so tac reads the whole input forward before it can answer anything. That is 0.18x, and through a pipe — where GNU cannot seek either — it is still 0.18x, because GNU buffers a pipe to $TMPDIR and reads it back with the same seek. 0.2.22 has the calls and tail and head use them (bu15); tac has not been rewritten onto them yet, and its numbers here are the forward reader's.

tac -r is the other side of the same coin. GNU's regular-expression path gives up the seek and runs re_search backwards over the buffer, and a small hand-written matcher beats it by 2.1x to 2.8x on the same input. So tac is 0.18x where GNU has a syscall we do not and 2.8x where neither of us does.

Where GNU decodes and we do not have to, we win by a lot. expand, unexpand and fold are 1.0x to 9.2x, and the largest ratios are on BINARY NOISE — 8.5x and 9.2x — because coreutils 9.x runs these utilities through a multibyte decoder even in the C locale, and invalid bytes are its slowest path. The smallest ratios are where the OUTPUT is large: expand on a tab-heavy input is 1.01x, because there both sides are writing, not deciding.

fold -s was predicted to be the worst row and is the best of its width (2.11x). The backwards scan for the last blank runs once per break over a piece that is at most -w bytes long; GNU pays more for the same decision.

Memory is flat in the input for four of the five. Peak RSS over 256 MiB, ours against GNU's: paste -s 3.4 MB against 1.7 MB, paste of two files 4.3 MB against 1.7 MB, fold 4.4 MB against 2.0 MB, expand 3.3 MB against 2.0 MB, unexpand -a 3.4 MB against 2.0 MB.

Getting there was a measurement, not a habit. All five first wrote their output through bore.put_byte, which is correct and cost 2.6 to 2.8 times the output in resident memory: the shared writer empties its buffer by allocating a fresh one, and every replacement is abandoned in an arena that frees nothing, so expand over 256 MiB peaked at 715 MB and paste of two such files at 1.35 GB. The three that read and write a chunk at a time now build each pass's output inside the per-chunk region and hand it to write_direct; tac and paste cannot do that and use bore.Sink, one buffer filled in place and written whole.

tac is the exception and always will be: it holds the whole input, so 256 MiB peaks at 515 MB, twice the input, against GNU's 1.8 MB. The factor of two is not the design, it is List having no capacity surface at 0.2.22 (wolf-std F-0011): a list built by pushing doubles, and each doubling abandons the previous buffer. Sizing it up front from fs_fstat does not help — filling it is itself a run of pushes — and that was measured rather than assumed.

A single line that is the whole input is the other bound: a 64 MiB line with no newline in it costs fold 322 MB and paste 131 MB, against GNU's 2.0 MB and 1.7 MB, for the same reason.

sort is B5, and the first utility here that may not hold its input: past a run budget (256 MiB by default, -S sets it) it sorts each run into a temporary file and merges the runs, at most 16 at a time. Every comparison is on bytes — GNU's behaviour under LC_ALL=C, which is the oracle's environment — and the sort is a merge sort of line indices, stable by construction; GNU's last-resort whole-line comparison makes that unobservable except under -s and -u, where input order decides on both sides. kasumi (linux x86-64, 16 cpus), release tier, GNU coreutils 9.11, 5 runs, generated text: 10 MB is tools/bench --scale 0.01, 100 MB is --scale 0.1, load 2–3, at the commit that carries this table's code.

The predictions were committed in notes/bu08-sort.md §3 and in the bench file before anything was timed, from the oracle's build rather than the algorithm: GNU sorts on eight threads here and compares with memcmp; this program sorts on one and compares in a loop. Four of eight bands were right.

Eight threads buy GNU less than two times. Its --parallel=1 row is 640 ms against 333 ms with eight, so the fair comparison — one thread each — is 0.42x, and the rest of the gap is memcmp against a bounds-checked byte loop. The keyed rows are the worst because GNU finds a key's bounds once per line and this program finds them per comparison. Our external merge is faster than our in-memory sort (1.37 s against 1.53 s for 100 MB): ten 10 MB runs sort in cache where one 100 MB index does not, which says where a faster in-memory sort would come from.

Memory, per input size (peak RSS, /usr/bin/time):

The external rows are flat in the input, which is the region per run doing its work, and they got there by measurement: the first draft read past the budget, and a list that crosses a power of two doubles, so 1 GB at the default budget peaked at 1,060 MB and at -S 10M grew to 61 MB. The external merge is seen, not asserted: under strace, 100 MB at -S 10M created 11 sortXXXXXX files and unlinked all 11 (GNU: 32 and 32), and -T naming a directory that does not exist makes both programs fail with cannot create temporary file in '…' — a differential case, which a sort that never spilled could not pass.

The small-surface set — tee, printf, printenv, pwd, sleep and nproc — is bu14's, and the wave asked for env beside them. env is not here, because its job is to run COMMAND in a modified environment and wolf 0.2.25 has no way to do that: no exec, no unset or clear, no child working directory, a spawned child's standard input wired to the null device, and a signal death that loses its number (wolf-lang#534, with the witness). Its print-only half would be printenv with a sorted listing, which is not the utility.

The six each have a header that says what they cannot do, and each such thing is a filed issue rather than a quiet difference:

• tee refuses -i by name (SIGINT cannot be ignored), and every broken-pipe branch of -p and --output-error dies of SIGPIPE where GNU carries on (wolf-lang#423). The non-pipe half of those modes — a full disk, a closed descriptor, a file that cannot be opened — is implemented and has cases, and the cases see the FILES it writes: tools/difftest gained a scratch directory per case for this, gated by two planted differences that must fail by name.
• printf has every conversion GNU 9.11 has, %N$ and * included, and its floating conversions are exact against the HOST's long double: x87 on linux x86-64 (printf %.20f 0.1 is 0.10000000000000000000), IEEE double on macOS (0.10000000000000000555), rounded and printed in big integers. Two random runs of 2,300 and 2,500 floating and integer conversions against GNU on kasumi found no difference.
• printenv prints a named variable exactly and the bare listing sorted (wolf-lang#535).
• pwd is physical by default as GNU's is; -L decides whether $PWD names the working directory from its type, size, time and listing, because there is no inode to compare (wolf-lang#536).
• sleep sleeps in whole milliseconds, rounding up.
• nproc counts what os_cpus counts, which agrees with GNU under an affinity mask and differs under a FRACTIONAL cgroup quota, where it rounds down and GNU up (wolf-lang#537; the whole nproc file under CPUQuota=150% is 55 passed and 23 failed, under 200% 78 of 78).

kasumi (linux x86-64, 16 cpus) at load 1.2–1.4, release tier built by wolf 0.2.20 with the host's clang 22.1.8, GNU coreutils 9.11-2, all taken between 16:20 and 16:30 EDT on 2026-10-02 — an hour before a system upgrade moved kasumi to clang 23.1.1 and GNU coreutils 9.12, so both sides of every row are on the same side of it. The start-up rows are hyperfine -N over 300 runs, so the ratio is real at a fraction of a millisecond; true (249 µs against 177 µs, 0.71x) is the floor every wolf binary here pays. The printf rows are 10,000 arguments built by the shell; tee is 256 MiB of text.

printf's floating rows cost a big-integer conversion each way, and were 0.03x before one change. The first measurement read 0.04x, 0.03x and 0.04x (218 ms, 227 ms and 220 ms): every argument was divided by a power of five bit by bit. Dividing by a one-limb divisor in one pass — every decimal with ten or fewer digits after its point — took them to 0.19x–0.27x, with both random runs re-taken on the faster binary and still clean. glibc converts in hardware and prints with its own exact printer; this program has no hardware float in the loop at all, which is why it can match two different long doubles.

tee to a file is AHEAD of GNU, and only there: GNU's copy into a file swung by ±29 ms across five runs where ours held ±4 ms. Peak RSS over 256 MiB is 2.9 MB against GNU's 2.2 MB, one region per 256 KiB chunk.

ls is faster than GNU at listing and slower at stat'ing, and the difference is one system call per name. kasumi (linux x86-64, load under 1), release tier, GNU 9.11, tools/bench --scale 10 --runs 20 ls twice (notes/bu18-ls.md): flat/ is 100,000 names, deep/ 316 directories of 316.

A plain listing stats nothing on either side, and here it sorts names fs_read_dir already sorted. -S and -t are one stat per name on both sides. -R is the gap: GNU knows a directory from the type the kernel returns with each name, and wolf's listing returns names only, so this program must ask of every entry whether it is a directory (wolf-lang#626). Peak RSS over the 100,000 names is 37 MB against GNU's 28 MB, and -R holds 2.8 MB against 2.2 MB: one region per directory, so a walk keeps only the directories it is inside (the first draft held every listing it had made, 70 MB).

The long format, and what else a record buys (bu20, wolf 0.2.27). kasumi, release tier, GNU 9.11, hyperfine -N, 15 runs, every side of a row in one call, at this branch's head 9633593 from a clean tree (~/lanes/bu20/bench.sh, log ~/lanes/bu20/ev/bench.log; the trees are tools/bench --scale 10's). The load was NOT quiet — 2.3 when the run began and 8 when it ended, other lanes building — so the σ of the later rows is wide and a difference under 10% is not a finding. "0.2.26" is trunk's ls before this lane.

Read the -l rows with their floor beside them. The floor of a long listing is one stat per name, and both sides are on it: strace -c counts 99,998 statx for GNU and 100,003 for this ls over the same 99,998 names. But GNU makes a SECOND call per name, 99,998 llistxattr, to decide the + it prints after a mode for an ACL (201,751 system calls in all, against 100,327 here). This ls cannot make that call (wolf-lang#685), so part of the 1.22x is work not done, not work done faster; where GNU has no second call (-s, -i, -F) this ls is 0.71x to 0.91x. -R went from 0.27x to level because a directory is known from the type the listing hands back, and a plain listing got faster because names fs_read_dir already sorted are no longer sorted again. -S and -t are slower than GNU and no faster than 0.2.26: they read the whole record where 0.2.26 asked for the size or the time alone, and in exchange sort a link by the link's own size and time, as GNU does. Peak RSS for -l of the 100,000 names is 174 MB against GNU's 29 MB: every list in a listing's region grows by doubling and nothing is given back until the listing ends, and no call can reserve a list's room (wolf-lang#416). A plain listing holds 33 MB (0.2.26: 37 MB; GNU: 28 MB).

The file changers (bu21, wolf 0.2.27). kasumi (btrfs), release tier, GNU 9.11, tools/bench with its new prepare step — every timed run starts from a tree put back by the host's own cp or rm — ten runs a side, at 546a656 (~/lanes/bu21/bench.sh, log ~/lanes/bu21/ev/bench.log). The load was between 5 and 9, other lanes building, so a difference under 10% is not a finding.

(The rm -r of flat/ row is the first of two later takes, 982 and 987 ms against 999 and 1,000 — ~/lanes/bu21/ev/bench-rm-again.log. In the run of record that one row read 2,029 ms against 958, with a σ of 128, while another lane's build took the load from 5 to 9; the three other takes of it, one from an earlier run at load 12, are all within 3% of GNU.)

Read each row with what both sides ask the kernel for. One 1 GiB file is the cost of asking, not of copying: on btrfs GNU's clone ioctl and fs_copy_chunk's copy_file_range both end in shared extents, a few tens of milliseconds for a gigabyte; on a file system that cannot share, both sides copy in the kernel and the row would be the disk's. rm -r is level with GNU though it names whole paths where GNU names entries relative to an open directory (wolf-lang#707): strace -c over 10,000 files in 100 directories counts 10,000 unlink and 101 rmdir here against GNU's 10,101 unlinkat, and 205 statx — one per directory and link, never one per file, because the listing says which entries are plain. cp -r is three quarters of GNU's speed, and most of the gap is the builtin's: per file GNU makes about seven system calls and this cp nineteen, eleven of them inside fs_copy_chunk — a duplicate of both handles for every call, and a second call with a confirming read to learn that a two-byte file has ended (wolf-lang#709). mkdir -p a thousand deep is 0.37x: one mkdir(2) per prefix means the kernel walks 1 + 2 + … + 1,000 components, where GNU changes directory as it goes; a path of ordinary depth is start-up on both sides.

Differences from GNU

Recorded, not matched: each is a place where boreutils answers otherwise than GNU coreutils 9.11 and was ruled to stay that way, with the evidence that measured it. Nothing here is refused, and no case hides it: the utility runs, and does the other thing. (A refusal by name is in each utility's row in the tables above.)

• A streaming filter appended onto its own input (boreutils#37, ruling #87). tail -c +1 f >> f, and nl, cut, tr, fold, expand and head -c the same way, read what they have just written: boreutils' write as they read, so each copies until the disk or a file-size limit stops it, at any size. GNU's stop after one pass on a file small enough to be read whole before the first write (a 9-byte file becomes 18 bytes, nl's 33), and on a larger one — 5,714 bytes and up in the probe — fill the disk as boreutils' do. The difference is that small file's single pass, a buffer's size rather than a rule: GNU has no input-is-output check for these utilities (cat has one, and boreutils' cat refuses as GNU's does, bu25), and none is added here. paste parts the other way at 5,714 bytes (GNU's fills, boreutils' stops after one pass); uniq, tac and cat -n answer alike. Evidence: bu25's probe notes/bu25/probes/p4.sh, each run in a 16 MiB tmpfs in a throwaway container, GNU's ev/probe-p4-gnu.log (sha256 f3a4f2aa…) and boreutils' ev/probe-p4-w1rel.log (2ec931a1…), copied into notes/bu28/ev/, and boreutils' answered again at wolf 0.2.33 (notes/bu28/ev/probe-p4-head-release.log).
• One signal, not two (bu28). GNU's timeout sends its command its own copy of a signal and then sends the group the command is in, so the command gets two; under load they now and then arrive apart, and a command that traps the signal runs its trap twice (measured: 2 of 360 runs on one cpu). This one sends a command still in its group (read from /proc/PID/stat on linux) the signal once, by the group send, and only a command that left the group, or one whose group cannot be read (macOS), its own copy too.
• timeout -s 33 (bu28). glibc keeps 32 and 33 for itself; GNU's timeout, sending either to the group it leads, dies of it. This one dies of 32 and lives through 33, on which its process holds a handler it never installed (SigCgt, measured): one tests/timeout/ row.

Drop-in readiness

Can a script call the boreutils program where it called GNU's? This table answers it per utility, from the evidence and from nothing else.

• GNU options are the entries GNU 9.11's own --help lists (a short and long spelling of one option are one entry), counted as covered when a passing differential case exercises the option and this program does not refuse it. An option that appears only in a case where GNU refuses it too — sort -ng — is not counted as covered.
• Cases are kasumi's, at this commit: passed / skipped, none failed. CI's macOS leg runs the same cases and skips the /dev/full ones as well, and the /proc and /sys ones (requires, bu15).
• vs GNU is the band of the rows in the tables above, kasumi only, GNU's time over ours. A start-up row is hyperfine -N over 300 runs.
• The verdict is mechanical. Drop-in when every option is covered and every skip is one of the two hosts' C libraries or devices disagreeing with each other. Drop-in for scripts that avoid X when an option is missing or refused, or a skip is this program's own. Not yet when the utility's central job does not hold. Slowness never lowers a verdict; it is the third column.

27 drop-in, 34 drop-in for scripts that avoid a named thing, none shipped not yet (bu28: kill's two named things became one, and timeout's four became three narrower ones; bu27: timeout arrived with named things, and kill's three became two narrower ones; bu24: the six identity tools arrived with a named thing each — accounts only in the two files, and logname on macOS; bu23: kill arrived with three named things, each a thing wolf cannot express yet; bu22: mkdir became drop-in, and chmod, touch and ln arrived with a named thing each; rmdir arrived drop-in at bu21 and mkdir, rm, mv and cp with a named thing each; readlink arrived drop-in at bu20; env, the one "not yet", shipped; wc became drop-in at bu19, when the host's reason arrived). cp's named things shrank at bu22: it copies a mode and both times now, and refuses only what it cannot keep, by name. The same evidence read across: no shipped utility fails a case, and every skip that is this program's own names its missing surface and evidence, with an upstream issue where one is already filed.

How much of GNU coreutils this is. GNU coreutils 9.11 documents 103 utilities (its info manual's invocation nodes, the four SHA-2 sums counted as one and [ as test; Arch's build installs 102 binaries and leaves out arch, chcon, runcon, hostname, kill and uptime; kill is built only when asked for, which the oracle of record now does). boreutils ships 61 of them, 59%. Effort is not what blocks many of the other 42: some need missing wolf surfaces. Existing issues carry witnesses; newly measured gaps below are listed for upstream. The OS surface lane's first cut, s199's wolf-lang#426 and #424 (seek, tell, the positional read, and the standard descriptors), shipped in 0.2.22, and tail, head and wc use it (bu15).

• #346 (closed, wolf 0.2.28, s230): a mode at creation (fs_open_perm, fs_create_dir_mode) and a change of one (fs_set_mode); chmod, mkdir -m, cp's new files and cp -p stand on them (bu22). install -m, mkfifo -m, mktemp can.
• #633, no user id and no access: rm's and mv's "write-protected" is the owner's write bit; id, whoami, test -w.
• #405 (closed, wolf 0.2.26): descriptors 0, 1 and 2 are read and written directly; every utility here does (bu19).
• #407 (closed, wolf 0.2.26): os_error/os_error_text give the host's reason; every utility here says it (bu19). The net and os families do not set it yet (wolf-lang#609).
• #411 (closed, wolf 0.2.26): bytes_count/bytes_find; wc -l, head, tail, nl, uniq and cut find lines with them (bu19). There is no backward scan, so tail's walk back from the end still compares a byte at a time.
• #416, a streaming read allocates and the ambient region never frees: worked around here with one region per chunk.
• #417 (closed for files, wolf 0.2.26): fs_copy_chunk; cat's plain path uses it (0.73x to 0.91x on linux, from 0.04x to 0.08x). Its read/write rung loses the bytes it read when the write fails (#642), which cat works out from the failure's shape.
• #643, no way to ask a terminal its size: ls -C on a terminal wider or narrower than 80; stty size, tput cols.
• #644, a region's exit frees to malloc: a streaming program's system time follows glibc's trim heuristics (cut on short lines moved +42% from an unrelated start-up change).
• #423 and #141 (closed, wolf 0.2.29, s232): every signal POSIX names has a meaning, a disposition can be read and set, and os_signal_send/os_signal_number reach any process and this host's numbering; kill stands on the last two (bu23). tee -p/-i here, nohup and env --ignore-signal can be written.
• #739, #740, #741, #762 (closed, wolf 0.2.31, s241, ruling #79): the group send, every process, host signals by -N, a signal's words, the caller's own group. kill's groups and -t's words, and timeout, stand on them (bu27). Of what bu27 met, wolf 0.2.33 (s246, wolf-lang#783, #784, #785, #787, ruling #88) answers four: one meaning ignored in the sending shape (os_signal_ignore_one), an end by a signal, a fault's included (os_exit_signal), a child's core (os_wait_poll_core) and signal 0's words; timeout and kill -t stand on them (bu28). Still not: process group 1 (ruling #86: kill 0 from it stays refused), hearing a send-only meaning or a host signal, and a process's own core limit or dumpability (timeout's own end dumps where GNU's never does).
• #424 (closed, wolf 0.2.22): fs_fstat, fs_seek, fs_tell and fs_read_at see descriptors 0, 1 and 2; wc -c and tail on a redirected regular file use them (bu15). cat's input-is-output refusal waits on #536 and on a handle's open flags: GNU refuses only when the output was opened for append or stands past the input (bu22, boreutils#28).
• #426 (wolf 0.2.22): seek, tell and the positional read exist; tail, head and wc use them (bu15). tac does not yet; dd skip=/seek= could; truncate and shred need a truncate call that does not exist.
• #534 (closed, wolf 0.2.27): os_exec and env_unset; env runs its command by them (bu20). nice, nohup, timeout, chroot and stdbuf each need one more call than an exec.
• #535, the environment listed only sorted: printenv and env.
• #536, file identity: by PATH it is fs_stat's device and inode since 0.2.27 (ls -i, ls -RL's loops, stat); from an open HANDLE there is still none, so cat f >> f is not refused and stat - cannot be written.
• #537, os_cpus rounds a fractional quota down: nproc.
• #538, wrapping[u64] prints signed and cannot be divided natively: worked around in src/bore/u64.lu.
• #625 and #626 (answered by wolf 0.2.27's s218): fs_stat, fs_lstat, fs_read_link, fs_read_dir_entries. ls -l and its family, stat and readlink are written on them (bu20), and ls -R went from 0.27x to level with GNU. realpath now uses the walk too (bu30); du, test -h and a find-shaped walk can be.
• #684, the record has no I/O block size: stat's %o and IO Block:.
• #685, no extended attribute: the + and . ls -l prints after a mode, ls -Z, stat %C; getfacl, cp -a's attributes beyond.
• #686, no file-system record: stat -f, df.
• #687, a name that is not UTF-8 is listable and nothing else: ls reports and skips it, and so do rm -r and cp -r (bu21) — its directory then stays, and the status is 1. As an OPERAND it never arrives: the runtime aborts on the argument (#406).
• #688 (closed, wolf 0.2.28): an 0o… or 0b… literal lowers on every tier; the modes here are still written in decimal.
• #689 and #682, os_exec runs ./name for an empty PATH component, and says nothing of why an exec failed: env.
• #692, the listing leaves out . and ..: ls -f and -aU cannot place them where ext4 has them.
• #698, #699 and #700 (closed, wolf 0.2.28, s230): fs_symlink, fs_link, fs_set_times; ln, touch, cp -p and cp's links stand on them (bu22). Setting times through a HANDLE is #714, which touch - waits on; a mv to another file system could now keep a mode and the times and does not yet.
• #701, no call changes an owner: chown, chgrp, cp -p's owner (refused by name), install -o.
• #702 (closed, wolf 0.2.28): fs_truncate sets a handle's length; truncate is written on it (bu30), with -o still blocked by #684.
• #703, a hole can be written and not found, and a clone cannot be asked for: cp --sparse and --reflink beyond auto.
• #704 (closed, wolf 0.2.28): os_umask sets the mask and answers the old one; reading it is setting it back (bore.current_umask), which chmod's symbolic modes, mkdir -p's parents and -m use.
• #705, device nodes still missing; fs_mkfifo arrived in 0.2.35 and mkfifo is written on it. mknod and a special file under cp -r.
• #706, a rename always replaces: mv -n is a look and then a rename; mv --exchange cannot be written.
• #707, no call is relative to an open directory: rm -r and cp -r walk by path, so a tree deeper than the host's path limit is out of reach, and a directory swapped for a link mid-walk is followed.
• #708, the prelude's min is refused by every compiler tier, and W0304 forbids declaring one: written out where it is needed.
• #709, fs_copy_chunk costs eleven system calls around the one that copies a small file: cp -r at 0.72x to 0.75x.

Newly measured surface gaps (bu30, notes/bu30/probes/surface.lu):

• Bare sync / sync -f need global sync(2) and per-filesystem syncfs(2). fs_sync(fd) and fs_sync_dir(path) flush only one object; both missing operations are refused by name, not approximated.

• uname needs raw sysname, nodename, release, version and machine fields. os_name() prints linux rather than Linux (or macos rather than Darwin), and os_arch() normalizes the machine word. There is no call for -n, -r or -v. No uname program is shipped.

• wolf-lang#684, a second consumer: truncate -o needs st_blksize, not allocated space (st_blocks, record word 8). Neither path nor handle's 20-word stat record has it, so -o is refused by name.

• Writable opens without create are absent from modes 0–5 and from fs_open_perm. truncate -c can recreate a name removed after its stat; sync cannot safely retry a read-denied, write-only operand. The latter is refused by name, not opened with append/create. In notes/bu30/probes/open-gap.lu, stat + unlink + mode 2 prints recreated=true; mode 5 is read-only, and mode 6 is invalid.

• Non-blocking writable opens are absent too. GNU refuses a FIFO without a reader immediately; mode 2 would block. truncate refuses an observed FIFO by name before opening it, but a concurrent replacement after stat remains a race until the surface exists. The bounded witnesses are notes/bu30/probes/review-oracle.py and the FIFO cases.

• unlink needs no further surface: the empty-directory witness gets the host refusal from fs_remove (Is a directory on Linux, Operation not permitted on macOS), and the entry remains. The utility also checks lstat; its final removal is still file-only.

• Following a hard-link source on macOS needs an atomic follow option for fs_link. The pinned call never follows a final symlink on any host; GNU's macOS link does. Source symlinks are refused by name on macOS, not linked to the wrong inode or reported as a fabricated ENOENT. The host-scoped witnesses are the two link cases and notes/bu30/ev/ci-macos-red.log (run 39987951234).