Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 08 Dec 2016, 06:14
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Filesystem
MultiRename v1.8
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [30 Posts]   Goto page: 1, 2 Next
Author Message
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Wed 30 Sep 2015, 12:47    Post subject:  MultiRename v1.8
Subject description: A batch file renamer
 

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!
multirename-1.8.pet
Description  MD5: 58e46b95b4274d4096f9acf1f66e0276 multirename-1.8.pet
pet

 Download 
Filename  multirename-1.8.pet 
Filesize  8.81 KB 
Downloaded  209 Time(s) 
multirename_NLS-1.7.pet
Description  Langpack (de).
pet

 Download 
Filename  multirename_NLS-1.7.pet 
Filesize  1.92 KB 
Downloaded  122 Time(s) 
Screenshot.jpg
 Description   
 Filesize   101.67 KB
 Viewed   739 Time(s)

Screenshot.jpg


_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.

Last edited by SFR on Mon 13 Jun 2016, 10:16; edited 11 times in total
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Wed 30 Sep 2015, 12:48    Post subject:  

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...

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.

Last edited by SFR on Mon 13 Jun 2016, 10:18; edited 10 times in total
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1149
Location: Japan

PostPosted: Sat 03 Oct 2015, 04:30    Post subject:  

Otsukaresama! Laughing
Don't know how to say this in English Crying or Very sad

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.
gtkdialog_sortorder.png
 Description   
 Filesize   212.9 KB
 Viewed   699 Time(s)

gtkdialog_sortorder.png

Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Sat 03 Oct 2015, 06:24    Post subject:  

MochiMoppel wrote:
Otsukaresama! Laughing
Don't know how to say this in English Crying or Very sad

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! Smile

Quote:
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.

Quote:
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?

Quote:
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'. Wink
Will be fixed in next version.

Quote:
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!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1149
Location: Japan

PostPosted: Sat 03 Oct 2015, 06:29    Post subject:  

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 Crying or Very sad

                                                                             < lies, rumors and false claims removed > Embarassed


    

Last edited by MochiMoppel on Sat 03 Oct 2015, 08:08; edited 2 times in total
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Sat 03 Oct 2015, 07:01    Post subject:  

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).

Quote:
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..? Wink
If I manage to preserve already renamed items, like it is in gFnRename, that won't be a problem anymore, I believe.

Quote:
Here is a show stopper: MultiRename doesn't like foreign languages Crying or Very sad

See screenshot.

Greetings!
no, it's a problem of selected option ;).jpg
 Description   
 Filesize   5.42 KB
 Viewed   640 Time(s)

no, it's a problem of selected option ;).jpg


_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1149
Location: Japan

PostPosted: Sat 03 Oct 2015, 08:34    Post subject:  

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.
Quote:
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
Quote:
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..? Wink
I knew you would say this Laughing 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.
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Sat 03 Oct 2015, 10:53    Post subject:  

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:
Quote:
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.

Quote:
Quote:
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..? Wink

I knew you would say this Laughing 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. Wink

[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.]

Quote:
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. Wink

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.

Last edited by SFR on Sat 03 Oct 2015, 15:46; edited 3 times in total
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Sat 03 Oct 2015, 15:43    Post subject:  

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!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1149
Location: Japan

PostPosted: Sun 04 Oct 2015, 04:47    Post subject:  

Much, much better! Laughing 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.
Back to top
View user's profile Send private message 
saintless


Joined: 11 Jun 2011
Posts: 3713
Location: Bulgaria

PostPosted: Sun 04 Oct 2015, 06:02    Post subject:  

Very useful script. Works well with cyrillic file names.
Thank you, SFR!
multirename1.3.jpg
 Description   
 Filesize   87.92 KB
 Viewed   543 Time(s)

multirename1.3.jpg


_________________
Farewell, Nooby, you will be missed...
Back to top
View user's profile Send private message MSN Messenger 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Sun 04 Oct 2015, 08:40    Post subject:  

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.

Quote:
- The warning after hitting Commit is frightening (and contains a typo Wink ).

Realy? Fixed. Wink

Quote:
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! Smile

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1149
Location: Japan

PostPosted: Sun 04 Oct 2015, 22:12    Post subject:  

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).
duplicate_warning.png
 Description   
 Filesize   28.29 KB
 Viewed   501 Time(s)

duplicate_warning.png

Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1531

PostPosted: Mon 05 Oct 2015, 06:10    Post subject:  

@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!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
666philb


Joined: 07 Feb 2010
Posts: 3019
Location: wales

PostPosted: Wed 07 Oct 2015, 04:50    Post subject:  

hi SFR,

i'm getting this error on the pinstall.sh
Code:
multirename-1.4/pinstall.sh: line 23: syntax error near unexpected token `fi'

_________________
Tahrpup, built with trusty tahr packages http://murga-linux.com/puppy/viewtopic.php?t=96178
Quickpet_Precise, install popular apps quickly http://www.murga-linux.com/puppy/viewtopic.php?t=83642
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [30 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Filesystem
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0876s ][ Queries: 12 (0.0056s) ][ GZIP on ]