Feature request: File actions
Closed this issue · 15 comments
For actions such as file deletion, you say that you one should use the clipboard. However, this does not work well when you SSH to a machine. While you state that the tool is intended to be used in a DE, it could be very useful in pure shell environment if you consider adding an alternative workflow. It was also mentioned on Hacker News that the deletion workflow is very common.
Maybe you should consider adding a tiny bit of complexity to allow more customizations. You already have system in place with the scripts directory. Maybe you should consider adding a bit of complexity; for example, the default keybindins might not suit all users. If you add some kind of configuration file for keybindings, one could map actions of keys such as "x" to a file deletion script, maybe it even asks for confirmation with readline or something. This still seems to be reasonably simple to me and is just a suggestion to add some flexibility.
Nothing is suits everyone, but nnn would seem to be reasonable alternative to mc/ranger/fzf if one could adapt it a bit more to specific needs. This is just a suggestion, but I mainly wanted to express that the clipboard workflow is not very useable in all scenarios such as when using SSH. Then one would need to use different tools.
There are reasons we don't support destructive/risky operations like deletion.
clipboard workflow is not very useable in all scenarios such as when using SSH
what's the alternative you propose? There is no clipboard over SSH without X forwarding. And piping to scripts is risky which is why nlay usage is kept at a minimum.
Also, the tagline says it all - The missing terminal file browser for _X_.
Maybe you should consider adding a bit of complexity
I think you are ignoring the complexity nnn already has. Anyway, please raise a PR and we can take a look.
Precisely because clipboard is not really an option for SSH, I proposed that a different approach would need to be taken to support actions such as delete.
I understand the rationale to be careful with desctructive/risky actions, which is why I mentioned that custom scripts would allow confirmations for such actions. However, I think you support rename with C-r, which I accidentally did do; I would consider this also as risky.
Since flat out adding deleting could be dangerous and more limited anyway, I tried to describe an approach which is very close to what you are doing anyway with your scripts directory. Maybe my describtion was too vage and not very good.
I did not say that nnn is not complex, I merely wanted to express that I think that adding certain things could be very beneficial for making nnn a much more effective tool.
I only created this issue as a feature request, not a pull request. If you do not like the idea at all, you can close this issue. I think the idea is good, because if you reread the discussions in Hacker News comparing nnn to mc and ncdu, I think a lot of people would really like nnn, because it seems quite light.
I also would not want to create a PR that might get rejected anyway if the idea is not well received. And I while I did like nnn quite a bit when testing and enough to write this request, I did not like it enough yet when using it with SSH, which is my main usage scenario, to replace mc/ncdu. If I delete files with the command line directly, it is easier to do with fzf for me right now, which can be integrated in many different custom workflows. I also find spawning a new shell a bit expensive just for deletion as opposed to using mc/ncdu for deletion.
Rename and delete are different. You do not lose data with rename.
I do not want to support delete within nnn and I haven't come around a way to do anything about the SSH scenario without using scripts which is insecure.
Closing the defect.
You don't lose the file contents from renaming, but you loose the filename, which is also information. It can be very long and if you do not know the previous name it is lost. If you have scripts with include/exclude patterns, it can get deleted. And renames can have other disastrous results. It is a modification, just like deletion.
Just to clarify, I did not specifically ask for "file deletion" and a solution just for SSH. I proposed that you could add a line to file to perform custom actions. For example:
tee ~/.config/nnn/keymap << EOF
C-x ~/bin/my_delete.sh
EOF
This could mean that by pressing C-x on a selection, the selection would be send to a script. And in this script, I could provide my own action, for example I could ask for a yes/no confirmation.
This solution is possible to use with SSH. And it is much easier to delete files with it, one could delete files just as in ncdu. And it should not be insecure. Since there is not default delete action in any way, nnn by default would not delete any files. But this solution requires an external configuration file, which you may not want. But I think the tradeoff may be worth it.
You can absolutely lose data with rename if you rename over an existing file.
Did you try this with nnn?
This could mean that by pressing C-x on a selection, the selection would be send to a script.
I am adding this to the ToDo list. When I requested you to add a PR that was because I am short on bandwidth myself.
I just tried the rename/overwrite thing, it's nice, nnn asks for confirmation. Anyway I still think that it is a bit inconsitent because I consider renaming "dangerous", but I am glad that renaming is possible.
I had another idea how one could add custom commmands: You now have a script directory for some parts that can be customized. You could use directories for keys and put scripts there. Then you would not need a config file. For example, you could do ln -s ~/bin/my_delete.sh scripts/ctrl/x. Then the file is linked to a script and the name defines the keybinding. You would not have to parse a config file.
The only problem would be how to handle default keybindings and if you want to allow users to rebind them. That is something you have to think about. When I read the documentation about the keys, I just thought that I might change or even remove some (like ctrl+r for rename ;-) ). But I do not offer a solution for this.
I also really like the tool as a way to change directories, it is faster than mc for this. If this tool makes its way into distros and can be installed via package managers, it might become quite popular. Ranger is also packaged now, but this tool seems to have a much different use case.
As I mentioned earlier, I would like to see PRs. I am short on bandwidth.
If this tool makes its way into distros and can be installed via package managers, it might become quite popular.
I believe you haven't even read the README. nnn is available in the repos of major distros already. And nnn is not ranger.
I missed adding some other aspects for supporting deletion inherently within nnn:
If there are thousands of files, the operation will block till completion. nnn doesn't use threads today. If we introduce threads, we will also need a way to visually update the progress to the users which will need changes to the gui.
@kevin-stuart I took some time to work out a solution and here's what we have: https://github.com/jarun/nnn#copy-file-paths-when-x-is-missing
This should be fine for all use cases where selected file names are required.
And the latest release adds vidir integration so you can batch copy, move, delete easily even when there's no X.
There might be one drawback to the current solution: If there is only a single file nnncp, this could cause problems with concurrent usage. For example, if you have two terminals open, use tmux, or if two users are using nnn. A solution could be to allow to supply an environment variable like you do for NNN_TMPFILE?
I would probably advise to use a default that maps the user as well, maybe the user's $XDG_CACHE_HOME? This would also be safer since only the user may be able to read this file (depending on the setup).
Either that or we can have a tmp file generated per session and remember it. I would prefer tmp in any case. $XDG_CACHE_HOME is not universal (my system doesn't have it by default) and I don't wanna litter $HOME.