never, ever overwrite files

[jrpie]

After PR #48 there still remains a case where vimv can overwrite files:
Suppose the directory structure is

.
├── myfile
└── t
    └── myfile

vimv will show

myfile
t

Renaming myfile to t/myfile will cause an overwrite.
Moreover the directory structure might have changed since the user started vimv.

This PR adds a check to never overwrite files ever. A warning is printed, but the renaming process continues, as it is probably easier to recover from a situation where one file was not moved correctly then from the situation where vimv stopped working in the middle of the renaming process.
Furthermore the PR reduces code duplication.

[thameera]

@jrpie Thanks. If I understand correctly, the return 1 in safeMove() combined with the set -eu on the top would cause the script to fail fast, rather than continuing the renaming process, correct?

[jrpie]

oh, yes, you're right. Sorry, I was not familiar with set -e, should have properly tested the code. The idea of returning 1 was to only increase count when the file is actually moved. Failing fast is not what I wanted to do.
As in my first message, I'd argue that only printing a warning but continuing would be better (but that is certainly debatable…)

[jrpie]

Is safeMove "${dest[i]}.${EXT}" "${dest[i]}" || : ignore error idiomatic to avoid exiting on error due to set -e?