Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cp: add progress bar #3903

Merged
merged 4 commits into from
Nov 11, 2022
Merged

cp: add progress bar #3903

merged 4 commits into from
Nov 11, 2022

Conversation

tertsdiepraam
Copy link
Member

@tertsdiepraam tertsdiepraam commented Sep 5, 2022

Closes #1455

Based on the recent discord discussion around #1455, I figured I would give it a go to see what the feature would look like. This is mostly meant to spark some discussion about what this should look like and how it should behave.

Details of this implementation:

  • indicatif is used to draw the progress bar.
  • Before copying all the files, we have to recursively read all the files to get the total size (like du)
  • With very large directories, this means a bit of lag before we can actually show the bar. The entire application is also slowed down noticeably, though I haven't done any benchmarks.
  • I ignored the size of the directories themselves as it seems insignificant in most cases.
  • We update the progress bar with each copied file.
  • This behaviour might need to be tweaked when using cp with the symlink options as that wouldn't actually copy that many bytes.

If we actually want to land this, the progress bar (and accompanying performance hit) would of course need to be opt-in. I'm leaning towards adding both a compile-time feature gate and a run-time flag to enable this.

This is what it looks like:
image

@tertsdiepraam tertsdiepraam changed the title cp: add progress bar cp: add progress bar Sep 5, 2022
@sylvestre
Copy link
Contributor

it is magic how small it is :)

@tertsdiepraam
Copy link
Member Author

Indeed! indicatif is amazing :)

@sylvestre
Copy link
Contributor

what about adding an option --progress ?

@tertsdiepraam
Copy link
Member Author

Yeah that makes sense. I added -g/--progress. I'm not sure what the g stands for, but it's used in advcpmv, which seems to be the most notable "prior art" for this. xcp also has a progress bar, but only has a flag to disable the bar (--no-progress).

I think a compile-time flag might be unnecessary, because the bloat by indicatif seems to be fairly minimal (about 70Kib, which is 1.5% of cp), so it might not be necessary.

@tertsdiepraam tertsdiepraam force-pushed the cp-progress branch 2 times, most recently from 4ae15d0 to 2ccf3c8 Compare September 5, 2022 11:20
@sylvestre
Copy link
Contributor

Maybe we should have a page in which we list all the stuff that we added compared to GNU's?

for example, I think we have more hashing functions

@tertsdiepraam
Copy link
Member Author

I'll add something like that to the docs in this PR. I'll also add the bar to mv and then I'll mark it ready for review. In using it for testing, I already found myself agreeing with the issue author that this is very useful.

We can also bikeshed the layout and appearance of the bar itself. I think it makes sense to put cp: as a prefix like we do with warnings and errors so the user can see what command in a script is showing the bar. I think I'll also add the ETA.

@tertsdiepraam tertsdiepraam marked this pull request as ready for review September 5, 2022 23:56
@tertsdiepraam
Copy link
Member Author

I changed my mind about mv, because it just renames files, it's usually very fast anyway, so doesn't really need a progress bar.

With the documentation on the extensions over GNU, I think this is ready.

@@ -938,7 +952,22 @@ fn copy(sources: &[Source], target: &TargetSlice, options: &Options) -> CopyResu
let mut non_fatal_errors = false;
let mut seen_sources = HashSet::with_capacity(sources.len());
let mut symlinked_files = HashSet::new();
for source in sources {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs some rustfmt ;)

@sylvestre
Copy link
Contributor

sorry, I think I failed as fixing the conflicts :(

@sylvestre
Copy link
Contributor

small error:


error[B004]: found 2 duplicate entries for crate 'terminal_size'
    ┌─ /github/workspace/Cargo.lock:201:1
    │  
201 │ ╭ terminal_size 0.1.17 registry+https://github.com/rust-lang/crates.io-index
202 │ │ terminal_size 0.2.1 registry+https://github.com/rust-lang/crates.io-index
    │ ╰─────────────────────────────────────────────────────────────────────────^ lock entries

@tertsdiepraam
Copy link
Member Author

Welp, looks like it's blocked. So I think we'll have to make an exception in deny.

@github-actions
Copy link

GNU testsuite comparison:

Congrats! The gnu test tests/rm/rm2 is no longer failing!
GNU test failed: tests/misc/tee. tests/misc/tee is passing on 'main'. Maybe you have to rebase?

@@ -0,0 +1,31 @@
# Extensions over GNU
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love that file :)

@sylvestre
Copy link
Contributor

needs rebasing again, sorry :(

Once done, if the CI is green, please land it :)

Adds the `-g` and `--progress` flags to enable a progress bar via
indicatif.
docs: fix typos in extensions page
@github-actions
Copy link

GNU testsuite comparison:

GNU test failed: tests/misc/timeout. tests/misc/timeout is passing on 'main'. Maybe you have to rebase?

@sylvestre sylvestre merged commit 81a2abc into uutils:main Nov 11, 2022
@sylvestre
Copy link
Contributor

sorry it took that long :)

@doronbehar
Copy link

Would it be possible to add progress bar for mv as well 🙏?

@tertsdiepraam
Copy link
Member Author

@doronbehar I found that mv is generally quite fast because it essentially just renames the files instead of having to read them. If you have a test case where it's slow enough to need a progress bar I could take a look.

@sylvestre
Copy link
Contributor

Maybe mv can be slow when moving between disks. (ex sdd - > USB)

@doronbehar
Copy link

Maybe mv can be slow when moving between disks. (ex sdd - > USB)

That's exactly the use case I was thinking about.

@tertsdiepraam
Copy link
Member Author

That makes sense! I'll open a new issue for it.

@tertsdiepraam tertsdiepraam mentioned this pull request Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature requests: cp & mv progress bar
3 participants