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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021