Closed hupfdule closed 2 years ago
rm
or git rm
to remove a file. I want to keep this consistent.So after all this, I will consider adding quotes around file names (I had this in an early version but removed it to keep the messages cleaner) but I accept users will sometimes have file names containing spaces. I also used to have an extra space in the the "Copied" preface but I removed that also because I thought it looked odd with two spaces. I will reconsider that.
With commit 2fc237fdd1ea9b82294ce9acea6e85c7a49791f9 (and version 2.14) I have added double quotes around logged file names. I have not added any extraneous spacing in the messages because I don't think it adds anything other than longer text.
I note that rm -v
puts single quotes around file names so thus there is precedence to use single quotes but I know from experience that single quotes are sometimes seen (e.g. in files originally sourced from Windows) but double quotes are never/rarely seen. E.g Removed "Don't Stop Believin'.mp3"
rather than Removed 'Don't Stop Believin'.mp3'
.
With that commit I also fixed an error where not all failed file actions are reported as a status code to the shell. Now edir always reports 0 = all files good, 1 = some files bad, 2 = all files bad.
While this is not the most important issue, it would drastically improve readability (especially when modifying a large amount of files) if the output would be columnized so that the actuall file names involved are more clearly visible.
For example this is the current output:
It is very hard to see where the original file name ends and the new file name begins. While this may be a bit easier if the files have common short file extensions, it still hard to skim for filenames with varying lengths and filenames containing spaces.
Therefore I propose formatting the output in the following way:
The following changes are made to the original output format:
Each single one of those changes improves readability, but I think the best readability can be achieved by doing all of them.
Another possibility is using a more formalized output format (similar to the format proposed in #13) that uses special characters instead of plain english for everything that is not part of the file name. Here is an example:
Even the operation in the first column could be replaced by some special character, but it’s a bit harder to find characters whose meaning would be obvious. Single chars "r", "c", "d" (like used in the proposal in #13) would not provide that much benefit over the english terms (at least if the columnization is applied).
Whether this output format should be the only one or should be selectable by a specific commandline option is left to your judgement.