numfmt: drop the stale number_str that stops the build by metif12 · Pull Request #224 · vlang/coreutils

metif12 · 2026-10-05T06:59:11Z

src/numfmt/numfmt.v declared fn number_str(n f64) string twice, at line 99 and line 192, so v build.vsh died with:

builder error: redefinition of function `number_str`
src/numfmt/numfmt.v:99:1:  conflicting declaration: fn number_str(n f64) string
src/numfmt/numfmt.v:192:1: conflicting declaration: fn number_str(n f64) string

build.vsh uses execute_or_panic, so one unbuildable tool takes the whole job with it: the Windows job fails in "Build all" and never reaches "Run tests". Every other tool gets to print compiling ... first, which is why the log looks healthy right up until the panic.

#210 added the second definition without removing the one from #196. I kept #210's and deleted #196's, because they differ at exactly one value and GNU sides with #210. Both bodies render a number as plain decimal digits, and over 0, 0.5, 1000, 1024, 2000, 999999, 1000000, 2000000.6, 1048576, 1073741824, 1099511627776, 1e15, 1e16, 1e-5, 0.1 and 1/3 they give the same string. At 2^53 they part company:

9007199254740992    #196 gives 9007199254740992.0    GNU gives 9007199254740992

#196's guard is math.abs(n) < 9.007_199_254_740_992e15, strictly less, so the bound itself falls through to f64_to_str_l and keeps the fraction. numfmt --to=none 9007199254740992 answers 9007199254740992 on GNU 9.4.

Verified on 138ab11 with V 0.5.2 125353b, cache cleared and building from scratch:


before	`build.vsh` dies at `src/numfmt`, same message as the runner (which uses V 64c6ba5)
after	`Compiled: 67 tools`, exit 0

v test ./src/numfmt passes and v fmt -verify is clean.

Two things this does not do. It does not make CI green: the test suite on top of it is 9 failed / 34 passed / 8 skipped (cksum, head, mkdir, shuf, sleep, sort, sum, tac, wc), so "Run tests" will now execute and fail. And winos-test was already red before #210 — 13bb30a, 6bb7969 and 0279956 all fail too — so this is the current blocker, not the first one.

…output as bytes (#229) * numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81. * dircolors: implement it Outputs the commands to set LS_COLORS, matching GNU 9.4 on every case measured: the Bourne shell form by default and with -b, the C shell form with -c, an empty LS_COLORS when the terminal cannot show colours, and a missing database file. The default database is the one GNU compiles in, measured with TERM=xterm. Without a TERM, or with TERM=dumb, GNU outputs an empty LS_COLORS rather than the database. Two things worth recording. The -p form prints the database with a comment header rather than as LS_COLORS, and that is not matched here. And the database file parsing only handles EXT lines; the colour keywords that follow them are not read, so a database file that names no extensions leaves LS_COLORS empty, which is what GNU does with the same file.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81. * Add GitHub Action to auto-update README completed count

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81. * Add GitHub Action to auto-update README completed count * tr: implement it

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81. * dircolors: implement it Outputs the commands to set LS_COLORS, matching GNU 9.4 on every case measured: the Bourne shell form by default and with -b, the C shell form with -c, an empty LS_COLORS when the terminal cannot show colours, and a missing database file. The default database is the one GNU compiles in, measured with TERM=xterm. Without a TERM, or with TERM=dumb, GNU outputs an empty LS_COLORS rather than the database. Two things worth recording. The -p form prints the database with a comment header rather than as LS_COLORS, and that is not matched here. And the database file parsing only handles EXT lines; the colour keywords that follow them are not read, so a database file that names no extensions leaves LS_COLORS empty, which is what GNU does with the same file. * README: mark dircolors done dircolors was implemented in #235 but never marked. The count was 81 of 109; it is 82.

* numfmt: restore the number_str the build needs, and sort: capture -z output as bytes Two regressions on main, both found by running the suite. numfmt did not compile: number_str is called at numfmt.v:74 and :169 but not defined anywhere. The #224 merge removed the definition at :99, and the other copy that was in the file came from a branch that is not on main, so main was left with no definition at all. Restored the one with the GNU parity comment, which is the one that was there before. sort's -z test failed for a different reason than it looked. sort -z is correct: on b\0c\nd\0e\n it writes b\0c\nd\0e\n\0, nine bytes, matching GNU. The test read the output through os.execute, which hands the captured bytes over as a string, and the NUL bytes do not survive that: os.execute reported six bytes with the NULs gone. The test now captures to a file and reads it back with os.read_bytes, so the comparison is on the real bytes. Suite after: 41 passed, 3 failed, 8 skipped of 52. The three that fail all read standard input, which the Windows build of this V does not put in binary mode, and that is a change in the V compiler rather than in this repository. * README: mark csplit, join and od done, and correct the count csplit and join were merged as #221 and #222 but never marked, and od was merged as #228. The count was 76 of 109; it is 79. * shuf: mark the options that take an argument with an equals sign GNU writes --input-range=LO-HI, and the descriptions in #193 differ from that. The flag module puts a space between the option name and its argument description, so this gets --input-range =LO-HI rather than --input-range=LO-HI. The equals sign is the part that carries the meaning, and the space is a limitation of the flag module rather than something this repository can change. * cp, mv: add a -progress option Implements the feature request in #174. Both tools take a --progress option, off by default, which draws a bar on standard error while the bytes move. The bar is a fixed forty columns wide and shows a percentage, drawn with a carriage return so each update overwrites the last rather than scrolling. It is on standard error because that is where advcpmv draws, and because it keeps the tool's own standard output clean. The size of the source is stat'd before the first byte moves, which is what the bar needs in order to show a percentage and which is why -progress is slower than a plain copy. The bar itself lives in common/progress.v so both tools share it. Two things worth recording: - A long option with no short form is spelled with two dashes. \cp -progress\ leaves it as a free argument and the copy fails; \cp --progress\ works. - mv's directory move removes the source tree after copying, file by file, because rmdir only takes an empty directory. Suite: 43 passed, 3 failed, 8 skipped, of 54. The two new files are cp and mv. The three that fail all read standard input, which is the Windows binary mode problem in the V compiler, not in this repository. * split, tee: add the tests they were missing Both tools were implemented and marked done in the README but had no test files, so nothing was guarding them. split gets the three cut modes (-l, -b, -C), suffix length, numeric suffixes, a custom prefix, a missing file and the refusal to cut two ways at once. tee gets the copy to stdout and file, append versus truncate, an uncreatable file and several files at once. Two expectations were wrong rather than the tools: -b 3 over a\\nb\\nc\\n... cuts g\\nh and \\n, not \\ng\\n and \\n, and tee creates a missing name rather than failing, so the error case needs a name in a directory that does not exist. * pathchk: implement it Checks whether file names are valid or portable, matching GNU 9.4 on every case measured: a valid name, an empty name, -p rejecting a space, -P rejecting an empty name and a leading dash, a nonexistent name, and several names at once. Two differences remain and both are recorded rather than hidden. GNU prefixes its messages with its own argv[0], which is the full path when it is invoked by full path, so the text differs by a prefix only. And GNU takes NAME_MAX from the filesystem, which is 14 on the WSL filesystem this was measured on and 255 on most others; V exposes no pathconf, so the POSIX value is used and the difference is limited to filesystems with a smaller NAME_MAX. pathchk had no test file before this, so it is new. * README: mark pathchk done pathchk was implemented in #231 but never marked. The count was 79 of 109; it is 80. * tsort: implement it Topological sort of a partial ordering, matching GNU 9.4 on every case measured: a chain, a cycle, an odd number of tokens, empty input, a self loop, duplicate pairs, blank lines and a missing file. Two things worth recording. A self loop is not a cycle: GNU prints the node once and exits 0, so the edge is dropped rather than counted. And the ready queue is taken from the front rather than the back, because a stack reverses the independent chains relative to the order they were read in, which is the difference between matching GNU and not on blank-line input. The only residual difference in a differential run is the argv[0] prefix on the error messages, which is the same cosmetic difference as shuf and pathchk. * README: mark tsort done tsort was implemented in #233 but never marked. The count was 80 of 109; it is 81. * dircolors: implement it Outputs the commands to set LS_COLORS, matching GNU 9.4 on every case measured: the Bourne shell form by default and with -b, the C shell form with -c, an empty LS_COLORS when the terminal cannot show colours, and a missing database file. The default database is the one GNU compiles in, measured with TERM=xterm. Without a TERM, or with TERM=dumb, GNU outputs an empty LS_COLORS rather than the database. Two things worth recording. The -p form prints the database with a comment header rather than as LS_COLORS, and that is not matched here. And the database file parsing only handles EXT lines; the colour keywords that follow them are not read, so a database file that names no extensions leaves LS_COLORS empty, which is what GNU does with the same file. * README: mark dircolors done dircolors was implemented in #235 but never marked. The count was 81 of 109; it is 82. * date: implement it Prints the date and time, matching GNU 9.4 on the default form, +FORMAT, -u, -R and -I. Two things worth recording. +FORMAT is not a flag, so the flag parser does not claim it: it is read from the command line directly and the + is stripped. And V's Time carries no offset field, so the zone is the difference between the absolute epoch and the epoch the same wall clock would have in the local zone. Not implemented: -d with an arbitrary date string, -f for reading dates from a file, and the locale dependent %c, %x and %X forms. * realpath: new tool with -e, -m, -L, -P, -q, -s, -z, --relative-to, --relative-base * README: mark realpath done (82->83) * README: mark tee done (83->84) * date: implement it Prints the date and time, matching GNU 9.4 on the default form, +FORMAT, -u, -R and -I. Two things worth recording. +FORMAT is not a flag, so the flag parser does not claim it: it is read from the command line directly and the + is stripped. And V's Time carries no offset field, so the zone is the difference between the absolute epoch and the epoch the same wall clock would have in the local zone. Not implemented: -d with an arbitrary date string, -f for reading dates from a file, and the locale dependent %c, %x and %X forms. * realpath: new tool with -e, -m, -L, -P, -q, -s, -z, --relative-to, --relative-base * README: mark realpath done (82->83) * README: mark tee done (83->84) * realpath: run v fmt -w on realpath.v Fixes the indentation of a mis-indented block plus struct field alignment. No semantic change. * README: stop hand-editing the completed count This branch changed the count line from 82/109 to 84/109 by hand. That line is derived, not maintained: update-readme-count.yml computes it with count=$(grep -c '| &check; |' README.md) and rewrites it on every merge to main. So the edit here was redundant, and because it touched the one line the workflow rewrites, it re-conflicted this branch on every merge anywhere in the repo. That is the whole of the three rounds of "Conflict in README" on this PR. The table rows for date and realpath are already marked done on main, so the count was the only thing here that was out of step. Reverting README.md to main's copy leaves this PR touching the tool source only. The count follows from the rows once the tools merge.

numfmt: drop the stale number_str that stops the build

bb8ae27

This was referenced Oct 5, 2026

main does not build: src/numfmt defines number_str twice #223

Closed

tests: build expectations from the newline the tools actually write #225

Merged

JalonSolov merged commit 51fb58a into vlang:main Oct 5, 2026

This was referenced Oct 5, 2026

od: implement it, and unblock the -W build #228

Merged

tests: build the harness on os.exec so make test compiles on current V #218

Merged

numfmt: restore the number_str the build needs, and sort: capture -z output as bytes #229

Merged

Navigation Menu

Repository navigation

numfmt: drop the stale number_str that stops the build - #224

numfmt: drop the stale number_str that stops the build#224
JalonSolov merged 1 commit into
vlang:mainfrom
metif12:fix/numfmt-build

metif12 commented Oct 5, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

metif12 commented Oct 5, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants