Add option to rename file names only

[bew]

Hello!

When giving a list of paths to rename like:

renamer ~/foo/bar ~/foo/other_bar ./a_local_bar

The whole path is given to the program, and when renaming I get a file with:

/home/my_user/foo/bar
/home/my_user/foo/other_bar
./a_local_bar

I'd like to suggest an option to only have a list of file names and not a list of full paths when renaming, so the renaming file would look like:

bar
other_bar
a_local_bar

And for the confirmation step, the filenames changes could be grouped by directories, like:

# in directory: /home/my_user/foo
bar -> new_bar
other_bar -> new_other_bar

# in current directory
a_local_bar -> new_local_bar

---

The only trick/potential-problem I see is when a filename is the same in 2 directories, but is it really a problem? And #17 could help in case something's wrong

---

For the option name, maybe --filenames-only ? Or --same-dir/--keep-dir ?

What do you think of this?

[marcusbuffett]

This is a cool idea, and it also tackles an issue with the current setup, in that if you edit a directory name things can fail. Getting rid of directory names avoids that. Filename being the same in two directories shouldn't be an issue, all that happens behind the scenes is matching up line numbers, so should be fine.

Somewhat related, the /home/my_user problem could be fixed by actually parsing the incoming files and printing them out in a way that would use ~. But if we decide to do file name only then that won't matter

[assarbad]

Just a note on ~, that's again shell behavior (like glob expansion from #39). And what's more there's not just ~ for yourself but also ~jdoe to refer to the home directory of user jdoe. In other words, you can also use a (Bash etc) shell builtin like echo ~ and you'll see the already expanded path. So that's what your program really gets to see in the main function. In order to show a ~ inside the editor you'd have to revert that preprocessing by the shell (ending up with the behavior that is being bemoaned in #39 as "Windows behavior"). Not sure you'll want to open this can of worms.

Simply stripping leading paths seems like introducing less complexity all the while solving already existing problems (when changing directory names).

PS: IIRC the ~ part is based on the same lookups getent uses through glibc/libnss in Bash, whereas $HOME could be overridden. I don't know how consistent different shells across different Unix flavors behave in that regard.

[assarbad]

Started working on this.

I second the idea that this ought to show the /path/to/original -> /path/to/renamed preferably as /path/to/original -> renamed (or even original -> renamed) ... in fact I am wondering why we don't do that already, since renamer doesn't allow changes to intermediate path elements as far as I could see.

FYI: for now I have gone with the option names -n and --name-only.

[mtimkovich]

I created a PR for this (#69)! @bew and/or @assarbad could I have you make sure the code looks good to you?

[mtimkovich]

I merged it anyway :stuck_out_tongue: Reopen if you run into any problems

[assarbad]

Sorry, a bit late to the party. I'll have a look anyway ;)