If PR #103 is merged, trashy will no longer be compatible with the trash command from trash-cli. I personally support this change because of the shell completion/simplicity it will bring. But that begs the question, why even name the executable trash at that point? It annoyingly conflicts with trash-cli and does not match the name of the project. Why not rename the executable to trashy? 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 be trash or trashy? The man page itself is titled trashy(1) and even displays the help string as having an executable named trashy. But of course that is inaccurate; the executable is actually named trash. I ended up creating both trash.1 and trashy.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's trash command comes from. In order to support trashy, you have to write something like this:
trash_cmd = nil
if vim.fn.executable("trash-put") == 1 then
trash_cmd = { "trash-put" }
elseif vim.fn.executable("gio") == 1 then
trash_cmd = { "gio", "trash" }
elseif vim.fn.executable("trash") == 1 and string.find(vim.fn.system("trash --version"), "^trashy") then
trash_cmd = { "trash", "put" }
end
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.
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.