8000 mv: add progress bar by ctsk · Pull Request #4220 · uutils/coreutils · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

mv: add progress bar #4220

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

Merged
merged 5 commits into from
Dec 13, 2022
Merged

mv: add progress bar #4220

merged 5 commits into from
Dec 13, 2022

Conversation

ctsk
Copy link
Contributor
@ctsk ctsk commented Dec 7, 2022

Similarly to cp, adds -g and --progress flags to enable a progress bar via indicatif.

The logic is tricker than the progress bar logic in cp and modeled closely to the implementation in advcpmv. In particular, the progress bar does not calculate the total size of the files if the move is performed via a rename operation. To still show adequate feedback, we use two progress bars:

  1. Count-Progress-Bar
  • This progress bar indicates how many of the source arguments have been moved.
  • Only shows up if there's 2 or more source arguments
  1. Folder-Copy-Progress-Bar
  • This progress bar indicates how much of a folder has been moved.
  • Only shows up if the source is a folder and copy+remove is required. Doesn't show up for file copies, as there's no progress reporting for that.
Screenshots

Multiple a file and a folder are mv'd across filesystems:

Screenshot from 2022-12-07 14-47-03

Screenshot from 2022-12-07 14-47-07

Similarly to `cp`, adds `-g` and `--progress` flags to enable a progress
bar via indicatif.
Copy link
Member
@tertsdiepraam tertsdiepraam left a comment

Choose a reason for hiding this comment

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

Excellent! I really like this design. My only important suggestion is that we can simplify the logic around the MultiProgress, by always initializing one if the progress bar flag is passed. Then we can always just add to it instead of having to branch between a MultiProgress and a single ProgressBar.

It's a bit unfortunate that we have to take suspend into account for all the prints, but I don't have a solution for that :)

@github-actions
Copy link
github-actions bot commented Dec 7, 2022

GNU testsuite comparison:

Congrats! The gnu test tests/tail-2/inotify-dir-recreate is no longer failing!

@ctsk
Copy link
Contributor Author
ctsk commented Dec 8, 2022

Thank you for all the feedback!

Copy link
Member
@tertsdiepraam tertsdiepraam left a comment

Choose a reason for hiding this comment

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

Looks good! Thanks!

@tertsdiepraam tertsdiepraam merged commit 00bbe24 into uutils:main Dec 13, 2022
@tertsdiepraam
Copy link
Member

Oh I remembered something right after I merged. @ctsk, could you explain the behaviour also in https://uutils.github.io/user/extensions.html? The source for that is docs/src/extensions.md.

@ctsk
Copy link
Contributor Author
ctsk commented Dec 13, 2022

Oh I remembered something right after I merged. @ctsk, could you explain the behaviour also in https://uutils.github.io/user/extensions.html? The source for that is docs/src/extensions.md.

Opened a PR here: #4234

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.

2 participants
0