You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I could see adding a -progress option, or some such. So by default they worked like the coreutils versions, but would have the option of showing progress.
Of course, I don't know that they collect all the info required up front to actually display the progress properly... seem like that would slow things down a bit, at least in some cases.
The bar is forty columns wide with a percentage, drawn with a carriage return so
each update overwrites the last. 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 --progress is slower than a
plain copy. The bar lives in common/progress.v so both tools share it.
Two things worth knowing for anyone using it:
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.
cp and mv had no test files before this, so both are new.
Activity
medvednikov commentedon Oct 4, 2024
I agree
JalonSolov commentedon Oct 4, 2024
I could see adding a
-progressoption, or some such. So by default they worked like the coreutils versions, but would have the option of showing progress.Of course, I don't know that they collect all the info required up front to actually display the progress properly... seem like that would slow things down a bit, at least in some cases.
metif12 commentedon Oct 6, 2026
Implemented in #230.
Both tools take a
--progressoption, off by default, which draws a bar onstandard error while the bytes move:
The bar is forty columns wide with a percentage, drawn with a carriage return so
each update overwrites the last. 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 lives in
common/progress.vso both tools share it.Two things worth knowing for anyone using it:
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.cp, mv: add a -progress option (#230)
pathchk: implement it (#231)
README: mark pathchk done (#232)
tsort: implement it (#233)
README: mark tsort done (#234)
dircolors: implement it (#235)
Add GitHub Action to auto-update README completed count (#238)
tr: implement it (#239)
README: mark dircolors done (#236)
date + realpath: new tools (#237)