Regex Rename Issue

KarlG · Yesterday, 10:13 PM

Wasn't sure if I should open a new theme or just add to this one.

Anyway, I wanted to do a mass regex rename of some image files

As you can see the results aren't as expected. The preview shows the correct result but when I actually click ok it turns out completely different.

Is this an error in Sigil or am I doing something wrong?

DNSB · Today, 12:05 AM

If I remember correctly, you are matching any . in the original filename and replacing it with fig. This would include the . between the chapter number and the image number as well as the . prior to jpg.

A search string something like ch(.*?)\.(.*?) and a replacement string of ch\1fig\2 is likely to be closer to what you need.

KarlG · Today, 01:02 AM

Quote:

Originally Posted by DNSB

If I remember correctly, you are matching any . in the original filename and replacing it with fig. This would include the . between the chapter number and the image number as well as the . prior to jpg.

A search string something like ch(.*?)\.(.*?) and a replacement string of ch\1fig\2 is likely to be closer to what you need.

Hi David,

The problem is, there ISN'T a . before jpg. It's just _jpg

DiapDealer · Today, 06:08 AM

Quote:

Originally Posted by KarlG

The problem is, there ISN'T a . before jpg. It's just _jpg

And that may be part of the problem. .01_jpg is not a proper file extension. That may be tripping up the regex rename routine. I'll have to take a look.

DiapDealer · Today, 06:38 AM

Definitely a bug if the preview does not match the end result. I may move this to its own thread since it's not really related to the original F&R minimal match topic.

KevinH · Today, 07:39 AM

It seems none of the original files had a valid file extension?

The RenameResourceList code in OPFModel, extracts the file extension from the original file name, runs the rename, then adds in the extensions.

See https://github.com/Sigil-Ebook/Sigil...Model.cpp#L346

But since no actual file extension existed, it extracted the .01_jpg, .02_jpg, etc as file extensions.

So to handle this case properly, you should use normal rename to add the proper .jpg file extension first to all files, then use the RegexRenamer with the find text properly modified.
Or take the results of the REXRenamer and then run it through a normal rename of file extendions last. Either should work.

It is important that proper file extensions exist so that they can act as fallbacks for missing media-types.

KevinH · Today, 08:01 AM

So not sure if this is a bug or not as there were no valid file extensions to begin with, which the current regex renamer code expects. We might have to modify the renamer code to compare the extracted file extension to a list of known valid file extensions, and then handle the case of invalid file extensions in some other way.

That might work. But doing the rename in 2 passes (as described above) should do the trick.

DiapDealer · Today, 08:16 AM

I agree it may not technically be a bug in the renaming algorithm itself. I was more referring to the fact the regex rename preview is showing something other than what the actual results are turning out to be.

DiapDealer · Today, 08:30 AM

In the meantime, the OP still should be able to achieve what they want with a regex of:

Code:

\.(\d+)_jpg

and a replacement of:

Code:

fig\1.jpg

That keeps both the chapter number and the figure number and places the proper .jpg extension at the end.

KevinH · Today, 08:33 AM

But that only happens when no valid file extensions exists. We could copy the code into the REXRenamer Table to split off the file extension (just like the current shared rename code does now) so they would exactly match even in this strange (no valid file extension) case but then I think the 01, 02, 03 info would get lost, preventing the 2 pass approach from working. But I can not test that to verify.

DiapDealer · Today, 08:53 AM

Yeah, I'm just not sure what would be best here. I'm leaning toward simply throwing a warning that the regex renamer can't continue whenever the regex matches a file without a valid extension. It may be pointless to try and accommodate invalid extensions. Surely these files are going cause problems in other places, no?

DNSB · Today, 02:34 PM

Quote:

Originally Posted by KarlG

Hi David,

The problem is, there ISN'T a . before jpg. It's just _jpg

I suspect that you have read enough on this topic from KevinH and DiapDealer but, having files without valid file extensions is Not A Good Idea.

Yesterday, 10:13 PM	#1
KarlG Connoisseur Posts: 57 Karma: 10 Join Date: Mar 2024 Device: none	Regex Rename Issue Wasn't sure if I should open a new theme or just add to this one. Anyway, I wanted to do a mass regex rename of some image files As you can see the results aren't as expected. The preview shows the correct result but when I actually click ok it turns out completely different. Is this an error in Sigil or am I doing something wrong? Attached Thumbnails

Today, 06:38 AM	#5
DiapDealer Grand Sorcerer Posts: 27,940 Karma: 198500000 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Definitely a bug if the preview does not match the end result. I may move this to its own thread since it's not really related to the original F&R minimal match topic. Last edited by DiapDealer; Today at 06:47 AM.

Today, 07:39 AM	#6
KevinH Sigil Developer Posts: 8,108 Karma: 5450184 Join Date: Nov 2009 Device: many	It seems none of the original files had a valid file extension? The RenameResourceList code in OPFModel, extracts the file extension from the original file name, runs the rename, then adds in the extensions. See https://github.com/Sigil-Ebook/Sigil...Model.cpp#L346 But since no actual file extension existed, it extracted the .01_jpg, .02_jpg, etc as file extensions. So to handle this case properly, you should use normal rename to add the proper .jpg file extension first to all files, then use the RegexRenamer with the find text properly modified. Or take the results of the REXRenamer and then run it through a normal rename of file extendions last. Either should work. It is important that proper file extensions exist so that they can act as fallbacks for missing media-types. Last edited by KevinH; Today at 08:12 AM.

Today, 08:01 AM	#7
KevinH Sigil Developer Posts: 8,108 Karma: 5450184 Join Date: Nov 2009 Device: many	So not sure if this is a bug or not as there were no valid file extensions to begin with, which the current regex renamer code expects. We might have to modify the renamer code to compare the extracted file extension to a list of known valid file extensions, and then handle the case of invalid file extensions in some other way. That might work. But doing the rename in 2 passes (as described above) should do the trick. Last edited by KevinH; Today at 08:13 AM.

Today, 08:30 AM	#9
DiapDealer Grand Sorcerer Posts: 27,940 Karma: 198500000 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	In the meantime, the OP still should be able to achieve what they want with a regex of: Code: \.(\d+)_jpg and a replacement of: Code: fig\1.jpg That keeps both the chapter number and the figure number and places the proper .jpg extension at the end. Last edited by DiapDealer; Today at 08:32 AM.

Today, 12:05 AM	#2
DNSB Bibliophagist Posts: 39,684 Karma: 154147704 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	If I remember correctly, you are matching any . in the original filename and replacing it with fig. This would include the . between the chapter number and the image number as well as the . prior to jpg. A search string something like ch(.?)\.(.?) and a replacement string of ch\1fig\2 is likely to be closer to what you need.

Today, 08:16 AM	#8
DiapDealer Grand Sorcerer Posts: 27,940 Karma: 198500000 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I agree it may not technically be a bug in the renaming algorithm itself. I was more referring to the fact the regex rename preview is showing something other than what the actual results are turning out to be.

Today, 08:33 AM	#10
KevinH Sigil Developer Posts: 8,108 Karma: 5450184 Join Date: Nov 2009 Device: many	But that only happens when no valid file extensions exists. We could copy the code into the REXRenamer Table to split off the file extension (just like the current shared rename code does now) so they would exactly match even in this strange (no valid file extension) case but then I think the 01, 02, 03 info would get lost, preventing the 2 pass approach from working. But I can not test that to verify.

Today, 08:53 AM	#11
DiapDealer Grand Sorcerer Posts: 27,940 Karma: 198500000 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Yeah, I'm just not sure what would be best here. I'm leaning toward simply throwing a warning that the regex renamer can't continue whenever the regex matches a file without a valid extension. It may be pointless to try and accommodate invalid extensions. Surely these files are going cause problems in other places, no?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
pdf regex question - regex that wraps to a new line	flyash	Conversion	1	09-05-2021 09:00 AM
Class Rename Issue	Paulie_D	Editor	2	03-29-2021 12:09 PM
Predefined regex for Regex-function	sherman	Editor	3	01-19-2020 05:32 AM
regex - issue with spaces?	cybmole	Editor	43	12-31-2013 12:49 PM
regex Issue when Importing	river	Calibre	3	06-16-2009 11:03 AM