Apologies ahead of time for grammar and spelling, I am on a phone.
This is a really cool idea, although you would you be willing to implement it using a file which would cache the cut/copy operations until a paste is done?
As it stands, whether you copy or cut the underlying operation is a cp. This means no matter what you pay the price of creating a copy of each file. There are a couple of ramifications of this, that I can think of at least. One, surprising labeling of files - selinux labels are dependent on how files are created. As such a move does not create new labels, where a copy does. Depending on what the operation is, the user might want to retain or remove the existing label. As it stands, the user cannot do the former. It is also possible that a file cannot be copied/moved to the home directory but to the destination directory only. Two, loss of filesystem move advantage. When you move a file within the same filesystem all that happens is a new link is created in the directory and the old one is deleted. This means the data of the file goes no where. Generally the "copy then delete" method is used between file systems. By doing this manually you cause this process to happen all the time. Worse, it is possible the SRC, HOME, and DST are all different file system, so this would cause three different copies.
However, if you implement a file within the HOME/.xcv directory which contains the source and the method of transfer you can make the transfer a direct source to destination affair.
Overall, I really like this project - could have saved a lot of time with it. Good luck!
I'm glad you like it, in its infancy it's already saved me a good bit of time! Your concerns make sense and I do want to eventually reconsider the paste processing; for now, for me it's sufficient but please do submit a pull request.
Copy all files recursively:
xcv .
Cut all files recursively:
xcv -x .
List all files which will be pasted:
xcv -l
Paste all copied files elsewhere:
xcv -v /elsewhere
It's just that most people will want to do those things by default, and remembering "xcv c -R ." is a bit more mental effort than "xcv ." But maybe that's just a personal preference.
Thanks. You'll notice I listed some aliases: fsx, fsc, fsv, fsl. I'm not yet sure what most others will want, myself included, as defaults so I avoided baking in naive opinions. Fortunately aliases should allow us all to tweak accordingly. I appreciate the feedback and look forward to hearing from others.
This is a really cool idea, although you would you be willing to implement it using a file which would cache the cut/copy operations until a paste is done?
As it stands, whether you copy or cut the underlying operation is a cp. This means no matter what you pay the price of creating a copy of each file. There are a couple of ramifications of this, that I can think of at least. One, surprising labeling of files - selinux labels are dependent on how files are created. As such a move does not create new labels, where a copy does. Depending on what the operation is, the user might want to retain or remove the existing label. As it stands, the user cannot do the former. It is also possible that a file cannot be copied/moved to the home directory but to the destination directory only. Two, loss of filesystem move advantage. When you move a file within the same filesystem all that happens is a new link is created in the directory and the old one is deleted. This means the data of the file goes no where. Generally the "copy then delete" method is used between file systems. By doing this manually you cause this process to happen all the time. Worse, it is possible the SRC, HOME, and DST are all different file system, so this would cause three different copies.
However, if you implement a file within the HOME/.xcv directory which contains the source and the method of transfer you can make the transfer a direct source to destination affair.
Overall, I really like this project - could have saved a lot of time with it. Good luck!