-
Notifications
You must be signed in to change notification settings - Fork 13
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
Should executable be renamed to trashy? #104
Comments
This is probably a good idea. |
stelcodes
added a commit
to stelcodes/trashy
that referenced
this issue
Oct 23, 2023
Since trashy no longer supports `trash <PATH> ...` and has given up on being a drop-in trash-cli replacement, the executable name `trash` is only a hinderance to greater adoption because it conflicts with the trash-cli executable of the same name. Giving the executable a unique name allows both programs to be installed without issue and also allows programs that wish to shell out to external commands for trashing files to support trashy by simply checking if an executable named `trashy` is present. Before this change, these programs had to check the output of the user's `trash` command to determine if it was from trash-cli or trashy.
oberblastmeister
pushed a commit
that referenced
this issue
Oct 25, 2023
Since trashy no longer supports `trash <PATH> ...` and has given up on being a drop-in trash-cli replacement, the executable name `trash` is only a hinderance to greater adoption because it conflicts with the trash-cli executable of the same name. Giving the executable a unique name allows both programs to be installed without issue and also allows programs that wish to shell out to external commands for trashing files to support trashy by simply checking if an executable named `trashy` is present. Before this change, these programs had to check the output of the user's `trash` command to determine if it was from trash-cli or trashy.
i'm currently on windows. is this renamed on windows, too? i'm using winget bdw. yes, it is confusing. should be |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If PR #103 is merged, trashy will no longer be compatible with the
trash
command fromtrash-cli
. I personally support this change because of the shell completion/simplicity it will bring. But that begs the question, why even name the executabletrash
at that point? It annoyingly conflicts withtrash-cli
and does not match the name of the project. Why not rename the executable totrashy
? It really doesn't make sense for every reimplementation of the freedesktop trash spec to ship an executable with the exact same name.I recently submitted a PR to nixpkgs to generate and install man pages for
trashy
, and I ran across the problem of what to name the man page. Should it betrash
ortrashy
? The man page itself is titledtrashy(1)
and even displays the help string as having an executable namedtrashy
. But of course that is inaccurate; the executable is actually namedtrash
. I ended up creating bothtrash.1
andtrashy.1
man page files and installing both.Another issue that comes up is tooling that supports trashing files via shelling out to external commands. For example, in Neovim if you want to write a plugin that searches the user's
PATH
for a freedesktop trash utility, you have to be really careful about figuring out where the user'strash
command comes from. In order to support trashy, you have to write something like this:Seems like all this confusion could be avoided if the name of the executable is changed to
trashy
. It's unique and matches the name of the project. Perhaps both the PR #103 and this change could be combined into a single breaking change release to make it easier for users to adjust.The text was updated successfully, but these errors were encountered: