Repository navigation
cp, mv: add a -progress option - #230
Merged
Merged
Conversation
…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 vlang#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.
GNU writes --input-range=LO-HI, and the descriptions in vlang#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.
Implements the feature request in vlang#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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the
-progressoption for both tools, off by default.The bar is forty columns wide and shows a percentage, drawn on standard error with
a carriage return so each update overwrites the last rather than scrolling. It is
on stderr because that is where advcpmv draws, and because it keeps the tool's own
stdout clean.
The size of the source is stat'd before the first byte moves. That is what the bar
needs in order to show a percentage, and it is why
--progressis slower than aplain copy. The bar itself lives in
common/progress.vso both tools share it.Two things I hit that are worth knowing:
cp -progressleaves it as a free argument and the copy fails;
cp --progressworks.mv's directory move removes the source tree after copying, file by file,because
rmdironly takes an empty directory.cpandmvhad no test files before this, so both are new. Suite: 43 passed,3 failed, 8 skipped, of 54. The three that fail all read standard input, which is
the Windows binary mode problem in the V compiler rather than in this repository.