join: implement it by metif12 · Pull Request #222 · vlang/coreutils

metif12 · 2026-10-04T20:24:49Z

Adds src/join/join.v and a test suite.

The behaviour was read off GNU 9.4 rather than the manual, and the two places where the manual and the program disagree are the two that took the most measuring:

The default output shape is the join field followed by every field of each file except that file's join field, not the fields after it. Measured over two three-field files whose second field matches, join -j 2 writes 1 a x a z — the field in front of the join field is kept. A join field past the end of the line leaves the whole line, which is what makes -j 9 print both lines in full behind an empty key.
An -o list reshapes the unpaired lines too. join -v1 -o 1.2 on b 3 z 7 r writes 3, not the line as it stands.

-a and -v are read out of the argument list before the shared parser sees them, for two measured reasons: GNU honours every occurrence of either, while the parser keeps only the last value of a repeated option, and the parser matches a short option only when the argument is exactly that character, so the glued -a1 has to be split somewhere. That also gives -o1.2 for free. GNU 9.4 has no long form of either option, so none is claimed.

Verified with a 44-case differential harness against GNU 9.4 under WSL — output, exit code and stderr, all matching. v fmt -verify and v test ./src/join are clean, and the full suite goes from 24 to 25 passing with the same 18 pre-existing failures.

Not addressed: an operand of - reads CRLF rather than bytes, because the Windows build of the compiler does not put stdin in binary mode. That is a compiler fix rather than a join one, so this stays as it is and is not claimed as working.

csplit and join were merged as vlang#221 and vlang#222 but never marked, and od was merged as vlang#228. The count was 76 of 109; it is 79.

…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.

join: implement it

2a2d5af

JalonSolov merged commit 138ab11 into vlang:main Oct 4, 2026

Navigation Menu

Repository navigation

join: implement it - #222

join: implement it#222
JalonSolov merged 1 commit into
vlang:mainfrom
metif12:fix/join

metif12 commented Oct 4, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

metif12 commented Oct 4, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants