MultiRename v1.8

Filemanagers, partitioning tools, etc.
Message
Author
User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

MultiRename v1.8

#1 Post by SFR »

Not much to say, yet another batch file renamer, written in Bash and Gtkdialog-0.8.4...

I used to use gFnRename, which is a great tool, but unfortunately it treats any string after the first dot as extension, so files like "my.file.txt" weren't processed as I wanted them to be.
MR does it differently (see Notes below).

Although I believe no major bugs are in the code, this is an initial release and I've been the only tester (for now), so it's better to take a careful look at "New Name" column before pressing the 'Commit' button and, at least in the initial period, work only on copies of important files.
And of course, please report any spotted bugs.

I wrote this app on Fatdog and briefly tested on TahrPup.
___________

Notes:

- MultiRename treats any string after the last dot as extension, but it can also recognize some common double extensions like .tar.gz, .tar.xz, etc.

- operations can be performed independently on basename or on extension or on both of them (base and extension are treated as one entity)

- operations are performed sequentially, just like they are arranged in the GUI (from top to bottom), i.e. if you select 'Prepend abc' and 'Case to Upper' options, 'Prepend' is performed first and then 'Case to' on the resulting filename: file -> abcfile > ABCFILE

- the 'offset' can be a negative number, e.g. '-1' is the position right after the last character, '-2' is the position before last character and so on

- if the resulting filename is the same as original, it won't be displayed in "New Name" column.
This is quite important to know, because even I caught myself a few times thinking that there must be something wrong with the code when nothing got displayed, until I realized the fact that the options I chose didn't actually change the name.


Known issues:

- files/dirs with newline (0x0a) in their names are not supported, but I did my best to handle everything else (like *`"|$\) properly.
But keep in mind that there are filesystems (e.g. vfat) that won't accept some special characters.
___________

NLS pet contains the following translations:
- German (L18L) [needs updating]

Have fun &
Greetings!
Attachments
multirename_NLS-1.7.pet
Langpack (de).
(1.92 KiB) Downloaded 461 times
Screenshot.jpg
(101.67 KiB) Downloaded 1118 times
multirename-1.8.pet
MD5: 58e46b95b4274d4096f9acf1f66e0276 multirename-1.8.pet
(8.81 KiB) Downloaded 614 times
Last edited by SFR on Mon 13 Jun 2016, 14:16, edited 11 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#2 Post by SFR »

Changelog

Version 1.0:
- initial release

Version 1.1:
- Fix: small bug in error handling.
- Removed the ability to go to parent directory using 'Backspace' key - checking the condition every time user presses arrow keys makes the browsing a bit too sluggish.
Additionally, with this feature removed MR will run (almost) perfectly with Gtkdialog-0.8.0.

Version 1.2:
- Fix: proper sorting of numbers within text (thanks to MochiMoppel)

Version 1.3:
- Preservation of items in "New Name" column (thanks to MochiMoppel)

Version 1.4:
- Fixed a typo (thanks to MochiMoppel)
- Added missing 'gettext' in one spot
- Column headers now clickable (thanks to MochiMoppel)

Version 1.4-1:
- Fixed a bug in pinstall.sh (thanks to 666philb)

Version 1.5:
- Fix: renaming didn't work if an item contained leading or trailing spaces

Version 1.6:
- Fix: revert gettext in one spot
- Enhancement: manual renaming of selected item (Right-Click or Shift+Enter)

Version 1.7:
- Manual editing: focus the destination field and fill it with old name if new name doesn't exist (thanks to MochiMoppel)
- Manual editing: the dialog now pops up under mouse pointer, not in the centre of the screen
- gettext fix (thanks to L18L)
- Added German translation to NLS pet (thanks to L18L)

Version 1.8:
- a bit faster Preview
- added keyboard shortcuts to 'Show hidden', 'Numeric sort', 'Preview' and 'Commit' buttons
- 'Old Name' column header has fixed initial width (300px), which means it doesn't auto-resize anymore, so even in case of long filenames the 'New Name' column is always visible
- added 'Numeric sort' togglebutton - it toggles the use of sort's '-V' switch.
It "resolves" the problem that with '-V' all numbers are sorted naturally, but unicode characters aren't.
Without '-V' it's the other way around. Now you can choose...
Last edited by SFR on Mon 13 Jun 2016, 14:18, edited 10 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#3 Post by MochiMoppel »

Otsukaresama! :lol:
Don't know how to say this in English :cry:

Not surprisingly I didn't find bugs. I'm not really a suitable tester because I don't need this tool, which limits my eagerness to dig deeper.

Surely I've noticed the biggest improvement over gFnRename: The "Rename" button is now called "Preview". Good.

Something that in my view needs urgent fixing is the way selections are treated. After each preview the selection is lost, and if after a preview all files aren't manually reselected, the next preview will again destroy the selection. Very frustrating. See how gFnRename retains the selection and even allows adding files to the selection and then renaming only those added files. I've tried to achieve the same effect by removing your "destructive" cp -f $TMPDIR/list_main $TMPDIR/list_mod statement in the func_review and find the result much better, but not perfect. I'm sure you'll figure it out.

This brings me to my biggest problem with gFnRename and MultiRename: Both accept only directories, not files. Look at the screenshot. My task is to rename the single digits of the first 9 files in /abc to 2digits (1 to 01). Because of the strictly alphabetic sort order in gtkdialog it becomes already a nightmare to select those files in MultiRename. Losing this selection will trigger a barrage of unprintable curses.

I think it would be a great improvement if MultiRename could accept multiple files. This would eliminate the manual selection process, sorting problems and the danger of losing the selection. Everything in the list is the selection, very similar to the ROX bulk renamer.
Attachments
gtkdialog_sortorder.png
(212.9 KiB) Downloaded 1103 times

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#4 Post by SFR »

MochiMoppel wrote:Otsukaresama! :lol:
Don't know how to say this in English :cry:

Not surprisingly I didn't find bugs. I'm not really a suitable tester because I don't need this tool, which limits my eagerness to dig deeper.

Surely I've noticed the biggest improvement over gFnRename: The "Rename" button is now called "Preview". Good.
Hey Mochi

Thanks for testing & feedback! :)
Something that in my view needs urgent fixing is the way selections are treated. After each preview the selection is lost, and if after a preview all files aren't manually reselected, the next preview will again destroy the selection. Very frustrating. See how gFnRename retains the selection and even allows adding files to the selection and then renaming only those added files. I've tried to achieve the same effect by removing your "destructive" cp -f $TMPDIR/list_main $TMPDIR/list_mod statement in the func_review and find the result much better, but not perfect. I'm sure you'll figure it out.
Yeah, I know what you mean. I'll see what I can do about it.
This brings me to my biggest problem with gFnRename and MultiRename: Both accept only directories, not files.
Hmm, I don't understand... In what sense?
Look at the screenshot. My task is to rename the single digits of the first 9 files in /abc to 2digits (1 to 01). Because of the strictly alphabetic sort order in gtkdialog it becomes already a nightmare to select those files in MultiRename. Losing this selection will trigger a barrage of unprintable curses.
Ah, I didn't check the 'file-[number].ext' scenario, only '[number].ext' and thought 'sort -h' is good enough.
Took me a while to figure it out, but turned out to be as easy as 'sort -fV'. ;)
Will be fixed in next version.
I think it would be a great improvement if MultiRename could accept multiple files. This would eliminate the manual selection process, sorting problems and the danger of losing the selection. Everything in the list is the selection, very similar to the ROX bulk renamer.
I'm not sure I understand, again... You can quickly select all items with CTRL+A, if that's what you mean by "Everything in the list is the selection".

Thanks again &
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#5 Post by MochiMoppel »

SFR wrote:I'm not sure I understand, again... You can quickly select all items with CTRL+A, if that's what you mean by "Everything in the list is the selection".
No, that's not what I mean. I mean that MultiRename now accepts only folders as arguments. The list in MultiRename will always show the content of a complete folder. Could be hundred of files, though the user is only interested in 10 files to rename. If he could select those 10 files in ROX, then drag&drop to MultiRename, this could mean that the resulting list in MultiRename contains only those 10 files. All of these files are to be renamed, no need to select anything within this list. The selection process is already finished when MultiRename receives the filespecs. This is how it is done in ROX bulk renamer.

Here is a show stopper: MultiRename doesn't like foreign languages :cry:

                                                                             < lies, rumors and false claims removed > :oops:


    
Last edited by MochiMoppel on Sat 03 Oct 2015, 12:08, edited 2 times in total.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#6 Post by SFR »

MochiMoppel wrote:No, that's not what I mean. I mean that MultiRename now accepts only folders as arguments. The list in MultiRename will always show the content of a complete folder. Could be hundred of files, though the user is only interested in 10 files to rename.
As you can see I was highly inspired by gFnRename, but e.g. pRename also operates on whole directories (but gives you no option to work only on selected items).
If he could select those 10 files in ROX, then drag&drop to MultiRename, this could mean that the resulting list in MultiRename contains only those 10 files. All of these files are to be renamed, no need to select anything within this list. The selection process is already finished when MultiRename receives the filespecs. This is how it is done in ROX.
One problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.
But even this is highly problematic, because if you drop more than one file there, they're separated by spaces, so filenames with spaces will be splitted in two (or more).
On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..? ;)
If I manage to preserve already renamed items, like it is in gFnRename, that won't be a problem anymore, I believe.
Here is a show stopper: MultiRename doesn't like foreign languages :cry:
See screenshot.

Greetings!
Attachments
no, it's a problem of selected option ;).jpg
(5.42 KiB) Downloaded 1030 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#7 Post by MochiMoppel »

SFR wrote:As you can see I was highly inspired by gFnRename, but e.g. pRename also operates on whole directories
pRename....that can hardly be a bechmark for you.
One problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.
This has nothing to do with gtkdialog. Arguments are handled by the script before entering gtkdialog. You call a function, now it's func_readdir, which prepares the list. I don't see a problem. Filenames with spaces should also be no obstacle
On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..? ;)
I knew you would say this :lol: It's a question of workflow. More often than not I have the files already selected in ROX or at least "in focus" and want to do something with them. I don't want to start anew in a different application. If I would start the day with a "Let's rename some files today", then fire up your renamer and start selecting, only then you would be right. It wouldn't make a difference. Still would leave the problem of having unrelated files in the list. But it's your choice, I'm not in a position to tell you what you should do.

As for the show stopper: Sorry for that, the show can go on.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#8 Post by SFR »

Ok, I just uploaded v1.2, but only with the 'sort' fix for now; have to really rethink how to properly implement preserving the preview of already renamed items...

MochiMoppel wrote:
One problem is that Gtkdialog does not offer drag'n'drop functionality, except into <entry> widget.
This has nothing to do with gtkdialog. Arguments are handled by the script before entering gtkdialog. You call a function, now it's func_readdir, which prepares the list. I don't see a problem. Filenames with spaces should also be no obstacle
Oh, I thought you meant drag'n'dropping onto the window of already working application.
Yes, dropping onto the app's icon or invoking from command line would work work, of course.
On the other hand - if a user can make the effort to select those files in ROX, why can't (s)he make the same effort in MultiRename..? ;)
I knew you would say this :lol: It's a question of workflow. More often than not I have the files already selected in ROX or at least "in focus" and want to do something with them. I don't want to start anew in a different application. If I would start the day with a "Let's rename some files today", then fire up your renamer and start selecting, only then you would be right. It wouldn't make a difference. Still would leave the problem of having unrelated files in the list. But it's your choice, I'm not in a position to tell you what you should do.
Have to rethink that, too, but since I prefer the "browse" way, I think it would be too much hassle to maintain two approaches.
So, let's say it's a TO-DO with LOW priority. ;)

[EDIT: Damn! I pressed 'Edit' instead of 'Quote' and entered a new post within this very post, deleting it. Hopefully I recreated it as it was.]
As for the show stopper: Sorry for that, the show can go on.
Don't worry, it did happen to me a few times, too. ;)

Greetings!
Last edited by SFR on Sat 03 Oct 2015, 19:46, edited 3 times in total.
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#9 Post by SFR »

me wrote:have to really rethink how to properly implement preserving the preview of already renamed items...
Alright, I managed to implement that quite gracefully and everything seems to work just fine.

Btw, in order to remove a specific item from "New Name" column, it's just a matter of selecting it, unchecking everything on the right pane and clicking 'Preview' button.
Clicking the 'Refresh' button will remove them all.

First post updated.

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#10 Post by MochiMoppel »

Much, much better! :lol: Good work!

Only minor points:
- I suggest that you set column-header-active to true. Might be useful to sort the 2nd column and have all renamed items at the top for further fine tuning, even if it means that the sorting is lost after a preview. Resorting is still easier than having scattered renamed files in the list.

- The warning after hitting Commit is frightening (and contains a typo :wink: ). A similar message, warning that all intended changes will be lost when the dialog shows Renamed items >0 and the user hits one of the top buttons would make the dialog almost fail safe.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#11 Post by saintless »

Very useful script. Works well with cyrillic file names.
Thank you, SFR!
Attachments
multirename1.3.jpg
(87.92 KiB) Downloaded 925 times

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#12 Post by SFR »

MochiMoppel wrote:- I suggest that you set column-header-active to true. Might be useful to sort the 2nd column and have all renamed items at the top for further fine tuning, even if it means that the sorting is lost after a preview. Resorting is still easier than having scattered renamed files in the list.
Hmm, on a second thought it might be useful, indeed. Done.
- The warning after hitting Commit is frightening (and contains a typo ;) ).
Realy? Fixed. ;)
A similar message, warning that all intended changes will be lost when the dialog shows Renamed items >0 and the user hits one of the top buttons would make the dialog almost fail safe.
It's not a bad idea, but introduces some technical difficulties regarding 'Show hidden' togglebutton - if a user has chosen 'No', the button gets toggled anyway (although hidden files are not shown).
And even if I employ some tricks with refreshing, in order to reinstate previous state of the button, in such a case the warning message is displayed twice in a row.
Same would happen with checkbox, btw.
At this moment I don't see an elegant solution for this...
saintless wrote:Very useful script. Works well with cyrillic file names.
Thank you, SFR!
Thanks, Toni! :)

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#13 Post by MochiMoppel »

Could be a bit "unfriendly" when preview happily produces invalid duplicates and only when the user hits Commit he is informed that "One or more names are duplicated". Finding the duplicates could be a nuisance. Some kind of hint before hitting Commit might be better. Maybe something like this:
  • [ "$NEW_NAME" = "$OLD_NAME" ] && NEW_NAME=""
    [[ $(<$TMPDIR/list) == *$NEW_NAME$'\n'* ]] && NEW_NAME="$NEW_NAME (DOUBLE!)"
In case of only 1 duplicate this would eliminate the naming conflict, so additionally a flag might have to be set to prevent the commit.

The best solution I've seen so far would give a warning ("n files will not be renamed because of duplicate names. Proceed anyway?". If the user confirms the renaming proceeds, but leaves the unprocessed files together with their conflicting new names in the list. The user then can concentrate on these remaining files and change the pattern until finally all files are successfully renamed (indicated by an empty New Names column).
Attachments
duplicate_warning.png
(28.29 KiB) Downloaded 912 times

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#14 Post by SFR »

@Mochi: Both methods would be problematic, because conflicts can occur not only in "New Name" column alone, but also in relation between "New Name" & "Old Name", e.g. if you rename only the first file:

Old | New
file -> file2
file2

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#15 Post by 666philb »

hi SFR,

i'm getting this error on the pinstall.sh

Code: Select all

multirename-1.4/pinstall.sh: line 23: syntax error near unexpected token `fi'
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#16 Post by SFR »

666philb wrote:hi SFR,

i'm getting this error on the pinstall.sh

Code: Select all

multirename-1.4/pinstall.sh: line 23: syntax error near unexpected token `fi'
Thanks, Phil. Fixed and reuploaded.

Btw, the error (caused by a lonely 'fi' at the very end of the script) wasn't disturbing the proper execution during normal install, but probably could break it while building with Woof-CE...

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#17 Post by SFR »

Version 1.6

I added an option to manually rename selected item.
Just right-click (or shift+enter) it and appropriate dialog will show up.

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#18 Post by MochiMoppel »

Hi SFR, manual editing ... it's getting sophisticated :lol:

I was a bit confused by the dialog. My proposal:
- Avoid the impression that the first field is editable
- Always fill the second field with a default. Makes editing much easier
- Put the focus on the second field, not the first

This worked better for me:
  • <frame '$(gettext "Rename the item manually")'>
    <hbox>
    <entry editable="false" has_frame="false">
    <variable>varMANUAL_OLD</variable>
    <input file>"'${TMPDIR}/manual_old'"</input>
    </entry>
    <pixmap stock-icon-size="3"><input file stock="gtk-go-forward"></input></pixmap>
    <entry has_focus="true">
    <variable>varMANUAL_NEW</variable>
    <input>N="'$(<${TMPDIR}/manual_new)'"; [ "$N" ] && echo $N || echo "'$(<${TMPDIR}/manual_old)'"</input>
    </entry>
    </hbox>
    </frame>

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#19 Post by SFR »

MochiMoppel wrote:Hi SFR, manual editing ... it's getting sophisticated :lol:
Hi Mochi

Well, suspiciously often there's a black sheep in a group of similarily named files:
01-somename
02-another
03 -black sheep
04-this one's normal
Manual editing is quite helpful in such cases.
I was a bit confused by the dialog. My proposal:
- Avoid the impression that the first field is editable
- Always fill the second field with a default. Makes editing much easier
- Put the focus on the second field, not the first

This worked better for me:
<frame '$(gettext "Rename the item manually")'>
<hbox>
<entry editable="false" has_frame="false">
<variable>varMANUAL_OLD</variable>
<input file>"'${TMPDIR}/manual_old'"</input>
</entry>
<pixmap stock-icon-size="3"><input file stock="gtk-go-forward"></input></pixmap>
<entry has_focus="true">
<variable>varMANUAL_NEW</variable>
<input>N="'$(<${TMPDIR}/manual_new)'"; [ "$N" ] && echo $N || echo "'$(<${TMPDIR}/manual_old)'"</input>
</entry>
</hbox>
</frame>
Hmm, 'has-focus' crossed my mind - I don't know why didn't I use it.
Anyway, I like the changes and they will be in next version (thanks!), with slight modification of <input>...</input> part, because some characters in names (especially <) can break it, so we have to use cat instead:

Code: Select all

<input>[ -s "'${TMPDIR}/manual_new'" ] && cat "'${TMPDIR}/manual_new'" || cat "'${TMPDIR}/manual_old'"</input>
(of course I also added '-n' to both 'echo -n "$MANUAL... > $TMPDIR/manual...' lines)

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#20 Post by MochiMoppel »

SFR wrote:we have to use cat instead
Beware, this will make you a candidate for the Useless Use of Cat Award

If you need to employ a (useful) cat, make it a cat with a tail:

Code: Select all

<input>cat "'${TMPDIR}/manual_old'" "'${TMPDIR}/manual_new'" | tail -1</input>
(of course I also added '-n' to both 'echo -n "$MANUAL... > $TMPDIR/manual...' lines)
In my version '-n' must not be added to echo "$MANUAL_OLD", only to echo -n "$MANUAL_NEW", otherwise cat will not work as expected. It seems to work, but I haven't tested with all your odd filenames, so I leave it as an idea.

Post Reply