www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - trash-d: Replacement for rm that uses the trash bin

reply rushsteve1 <rushsteve1 rushsteve1.us> writes:
https://github.com/rushsteve1/trash-d

A near drop-in replacement for `rm` that uses the Freedesktop 
trash bin. Started because an acquaintance `rm -rf`'d his music 
folder and I thought there had to be a better way.

It's pretty simple and only uses the D stdlib. Been working on it 
in my spare time for a bit over a week and I figure it's good 
enough to show people.

I started this project in Bash originally but switched to D since 
I thought it would be a good way to learn some more (also Bash is 
scary). Ended up being a great choice!

Pretty new to D so feedback welcome!
Aug 23
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote:
 https://github.com/rushsteve1/trash-d

 A near drop-in replacement for `rm` that uses the Freedesktop 
 trash bin. Started because an acquaintance `rm -rf`'d his music 
 folder and I thought there had to be a better way.
Looks like a nice little utility. Thanks for sharing! One thing I would have liked to see in the README, and had to go digging through the source code for, is a list of supported command-line options. You might consider copy+pasting the output of `trash --help` into the README, to give readers a quick overview of its capabilities.
Aug 23
parent rushsteve1 <rushsteve1 rushsteve1.us> writes:
On Tuesday, 24 August 2021 at 02:34:54 UTC, Paul Backus wrote:

 One thing I would have liked to see in the README, and had to 
 go digging through the source code for, is a list of supported 
 command-line options. You might consider copy+pasting the 
 output of `trash --help` into the README, to give readers a 
 quick overview of its capabilities.
Thanks for the suggestion, I've updated the README with the flags and a "usage" section. Doing that actually made me realize another issue with flag precedence, so thanks for helping me find that too :) While I was in there I found another couple bugs (never ends does it?) that I quickly fixed, so I'm going to tag a new release.
Aug 24
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 24, 2021 at 02:19:58AM +0000, rushsteve1 via Digitalmars-d-announce
wrote:
 https://github.com/rushsteve1/trash-d
 
 A near drop-in replacement for `rm` that uses the Freedesktop trash
 bin.  Started because an acquaintance `rm -rf`'d his music folder and
 I thought there had to be a better way.
Cool!
 It's pretty simple and only uses the D stdlib. Been working on it in
 my spare time for a bit over a week and I figure it's good enough to
 show people.
Very nice!
 I started this project in Bash originally but switched to D since I
 thought it would be a good way to learn some more (also Bash is
 scary). Ended up being a great choice!
Agreed, I wouldn't touch bash scripting with a 100-foot pole if I could help it. D is much better for this sort of thing. ;-)
 Pretty new to D so feedback welcome!
Welcome! T -- The early bird gets the worm. Moral: ewww...
Aug 24
prev sibling next sibling parent Brian <bcallah openbsd.org> writes:
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote:
 https://github.com/rushsteve1/trash-d

 A near drop-in replacement for `rm` that uses the Freedesktop 
 trash bin. Started because an acquaintance `rm -rf`'d his music 
 folder and I thought there had to be a better way.

 It's pretty simple and only uses the D stdlib. Been working on 
 it in my spare time for a bit over a week and I figure it's 
 good enough to show people.

 I started this project in Bash originally but switched to D 
 since I thought it would be a good way to learn some more (also 
 Bash is scary). Ended up being a great choice!

 Pretty new to D so feedback welcome!
Funny seeing you here!
Aug 24
prev sibling next sibling parent russhy <russhy gmail.com> writes:
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote:
 https://github.com/rushsteve1/trash-d

 A near drop-in replacement for `rm` that uses the Freedesktop 
 trash bin. Started because an acquaintance `rm -rf`'d his music 
 folder and I thought there had to be a better way.

 It's pretty simple and only uses the D stdlib. Been working on 
 it in my spare time for a bit over a week and I figure it's 
 good enough to show people.

 I started this project in Bash originally but switched to D 
 since I thought it would be a good way to learn some more (also 
 Bash is scary). Ended up being a great choice!

 Pretty new to D so feedback welcome!
Welcome!
Aug 24
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote:
 https://github.com/rushsteve1/trash-d

 A near drop-in replacement for `rm` that uses the Freedesktop 
 trash bin. Started because an acquaintance `rm -rf`'d his music 
 folder and I thought there had to be a better way.
Cool! How does it compare to the `trash` command from the `trash-cli` package?
Aug 24
parent reply rushsteve1 <rushsteve1 rushsteve1.us> writes:
Thank you all for the warm welcome!

---

On Wednesday, 25 August 2021 at 06:11:04 UTC, Vladimir Panteleev 
wrote:
 Cool! How does it compare to the `trash` command from the 
 `trash-cli` package?
To quote the `trash-cli` README
 Although the interface of trash-put seems to be compatible with 
 rm, it has different semantics which will cause you problems. 
 For example, while rm requires -R for deleting directories 
 trash-put does not.
`trash-d` tries to mimic `rm`'s semantics as much as possible. It also unifies all the different `trash-*` commands that `trash-cli` provides into a single one with flags. One of my goals with `trash-d` was to make a simpler and smaller alternative to `trash-cli`. The only advantage that `trash-cli` has that I know of (aside from maturity at this point) is that it handles `.Trash/` directories on separate drives/partitions while `trash-d` always moves to the one in the user's home. Both approaches are spec-compliant, so I opted for the simpler one.
Aug 25
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 25 August 2021 at 13:30:36 UTC, rushsteve1 wrote:
 `trash-d` tries to mimic `rm`'s semantics as much as possible. 
 It also unifies all the different `trash-*` commands that 
 `trash-cli` provides into a single one with flags. One of my 
 goals with `trash-d` was to make a simpler and smaller 
 alternative to `trash-cli`.
That makes sense, thanks!
 The only advantage that `trash-cli` has that I know of (aside 
 from maturity at this point) is that it handles `.Trash/` 
 directories on separate drives/partitions while `trash-d` 
 always moves to the one in the user's home. Both approaches are 
 spec-compliant, so I opted for the simpler one.
I suggest investigating that as a future improvement. Not only is moving files within the same volume much faster (potentially an O(1) operation as opposed to having to read then write every byte of data), but it can also result in space savings (in the case of filesystem snapshots).
Aug 25
parent rushsteve1 <rushsteve1 rushsteve1.us> writes:
On Wednesday, 25 August 2021 at 18:37:33 UTC, Vladimir Panteleev 
wrote:
 I suggest investigating that as a future improvement. Not only 
 is moving files within the same volume much faster (potentially 
 an O(1) operation as opposed to having to read then write every 
 byte of data), but it can also result in space savings (in the 
 case of filesystem snapshots).
You're entirely right. I made an initial pass at this a little while back, and decided (for the time being at least) that it would complicate `trash-d` quite a bit more than I wanted. But it's something on my radar, and could be a very good feature to add at some point. I've opened [a GitHub issue for discussing/tracking this](https://github.com/rushsteve1/trash-d/issues/2), since I figured the D forums weren't the right place for such a discussion.
Aug 25
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote:
 https://github.com/rushsteve1/trash-d
You marked all functions inline?
Aug 24
parent reply rushsteve1 <rushsteve1 rushsteve1.us> writes:
On Wednesday, 25 August 2021 at 06:23:37 UTC, Kagamin wrote:
 You marked all functions inline?
If I did then it wasn't on purpose, I was only trying to mark the handful of helper functions as inline. If you know a solution to this, that would be greatly appreciated!
Aug 25
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 25 August 2021 at 13:30:58 UTC, rushsteve1 wrote:
 On Wednesday, 25 August 2021 at 06:23:37 UTC, Kagamin wrote:
 You marked all functions inline?
If I did then it wasn't on purpose, I was only trying to mark the handful of helper functions as inline. If you know a solution to this, that would be greatly appreciated!
When you use an attribute with a colon after it, like you do on [line 232 of trash.d][1]: ```d pragma(inline): ``` Then it applies not just to the next declaration, but to *all* subsequent declarations in the same scope (which in this case is the entire rest of the module). (Source: first paragraph in the ["Attributes" section][2] of the spec.) To avoid this, just remove the colon. To be honest, you could probably remove `pragma(inline)` from the program altogether and not notice a difference. A program like this is almost certainly going to be bottlenecked on IO long before function-call overhead makes a noticeable difference to performance. [1]: https://github.com/rushsteve1/trash-d/blob/00485ca0486e2190fbdfc051fc272c52b8faf014/source/trash.d#L232 [2]: https://dlang.org/spec/attribute.html
Aug 25
parent rushsteve1 <rushsteve1 rushsteve1.us> writes:
On Wednesday, 25 August 2021 at 13:52:32 UTC, Paul Backus wrote:
 To be honest, you could probably remove `pragma(inline)` from 
 the program altogether and not notice a difference. A program 
 like this is almost certainly going to be bottlenecked on IO 
 long before function-call overhead makes a noticeable 
 difference to performance.
Thanks for the help, I did end up just removing the `pragma(inline)` attributes. You're right, they're a premature optimization that doesn't really add anything. Compiler might inline them anyway, it's smarter than me :)
Aug 25