Open rieje opened 1 year ago
You're right. The trash-restore interface should be revisited.
Would it also be possible to allow trash-restore
to accept the original paths of trashed files to instantly restore those, a bit like the trash-put
command for files in a given directory? I imagine this would allow trash-cli
to be used as a drop-in replacement for things like gio trash
which already have that facility in place.
Couldn't agree more.
# root @ ubuntu in / [19:57:37]
$ touch /test.trash
# root @ ubuntu in / [19:57:40]
$ trash-put /test.trash
# root @ ubuntu in / [19:57:46]
$ trash-restore
No files trashed from current dir ('/')
# root @ ubuntu in / [19:57:52]
trash-cli version: 0.23.11.10
I think users should be able to trash-restore from anywhere. One often wants to restore a file, only to need to go to the filesystem/directory containing the file in order to restore it.
Since trash-list shows all files anyway, it is also intuitive that user can restore them from anywhere.
P.S. Unrelated question, but I was wondering about the top-level /.Trash mentioned in the read-me. How does it work--is it a global trash location that trash-cli uses automatically if detected or are users expected to use
--trash-dir=
for this directory (otherwise it wouldn't do anything, i.e. use a .Trash at the root of each filesystem like normal)? And what happens when you're deleting from other filesystems--are the files moved to this top-level trash? Maybe a little more clarification is appropriate in the README on how it works and the usecase it's intended for.