-
Notifications
You must be signed in to change notification settings - Fork 9
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
enhancement: size of graveyard #11
Comments
Thanks and good idea. The one potential issue with the simplest approach to this [see below] is I think it might take longer to delete files, right? For example, right now we can get away with simply a Lines 284 to 286 in c0e3092
But if we want to add more info to the record, like size and filecounts: Lines 10 to 14 in c0e3092
I think it would take longer. Alternatively, maybe we could compute this on-the-fly? Like, if you do Could even use the same code that e.g., dua-cli does for some of this. |
I think the 2. solution you mentioned would be perfect. |
I wonder if it would be possible to simply pipe it to Then you could pass whatever arguments you would normally pass to |
Good idea. |
I'm looking at https://github.com/zhiburt/tabled/ for doing this. |
looks like an amazing library |
I also wonder if we could instead modify https://github.com/Byron/dua-cli to get some kind of interactive restoration... Seems like a fair amount of work though. |
I've just installed this great tool, seems amazing.
One thing that would make it even better would be I think to show disk usage by
graveyard
.Something like with
rip -i
, eg.rip -s
:graveyard: /tmp/graveyard-user/ 428 files in 3 directories: 131M file, 2K: /home/user/.viminfo dir, 2 files, 81K: /home/user/.w3m dir, 425 files, 130M: /home/user/.cache
or something.
Would be awesome.
The text was updated successfully, but these errors were encountered: