XYplorer Beta Club

Hi all,

I was a little unsure about posting this, because this isn't a Regex forum! Having said that, I haven't found as much help on anything anywhere else

Anyway, in case someone can point me in the right direction, here's what is driving me nuts:

I have a group of folders with names like these What I'd like to do is remove everything inside the "[]" brackets, including the brackets themselves

The Regex pattern I've been experimenting with is: This actually works no problem (I can remove any generated double spaces later with a simple 'search and replace') EXCEPT when the text inside brackets *** is at the very end *** of the string . . . then it just gets ignored, so my result using this Regex is
As you can see, the second string remains untouched

Has anyone any ideas? I do understand if you don't have time and I'll keep searching, but I'd be grateful for a pointer in the right direction

My ultimate aim is to write a Regex pattern that will match anything in [] or () brackets and remove them all in one go, but I can see the use of having this as two seperate patterns becase removing both might not always be needed

Thanks

Biggy

I'm aware that this thread is somewhat related to this post. I'd just like to append a reference here, in case someone stumbles upon the "where did I saw this before...?!" question as I did...

The best reference for regular expression I've ever seen is here: http://www.regular-expressions.info/

Concerning what you're attempting..
1) The reason you see failures when the bracket is first or last is because "+" means match the previous pattern 1 or more times. You could just replace them with "*" (match zero or more times) and it should work.

2) But there's no reason to grab the content outside of the brackets, XY will only make the replacement on the matching pattern, so you can reduce the pattern to just the bracketed contents.

3) Now to match either () or [] you need to use character sets, and because the characters [] are used to signify a character set and () for a capturing group within a regular expression we end up with something that is really really ugly looking. (At least if use caution and escape everything..)

Placing this in the Regexp rename field should do what you want: What this means:

TheQwerty,

Replace + with * . . .

Doh, doh, DOH

Although I'm new to Regex, I had seen this and tried to use it in a few 'test' patterns . . . can't believe I completely overlooked it when trying to create this pattern

Thanks very much. I'm now going to take some time studying your regex and getting to know it!


.

I want be involved in that game

TheQwerty wrote: 2) But there's no reason to grab the content outside of the brackets, XY will only make the replacement on the matching pattern, so you can reduce the pattern to just the bracketed contents.

Great.

Placing this in the Regexp rename field should do what you want:

Code: Select all

[\(\[][^\)\]]*[\)\]] > 

Greater

To solve this special challenge i add an blank in front of the regex: FROM:
Elton John - Best of [128kbs] live in London (LIVE).mp3
Enya [320] Hits and Remixes (2008).mp3
Simple Minds Waterfront Collection [mp3].mp3
TO:
Elton John - Best of live in London.mp3
Enya Hits and Remixes.mp3
Simple Minds Waterfront Collection.mp3

works with that regex in one go.
Because we match " (.*)" and " [.*]" including the leading space.

(That means OTOH: if there is no space in front of the ('s or ['s of the file name, this regex will fail)
EDIT: This RegEx should work no matter if there is an space or not.
(because of the additional "*" which means non-or-more of the previous RegEx pattern, here the "\s" )
[/color]



To see the blank better here i have add them in "\s" notation instead of just using an simple space.
And since most regex meta chars don't have to be escaped inside an character class, i have removed those back slashes not needed.

HTH?

Stefan wrote:And since most regex meta chars don't have to be escaped inside an character class, i have removed those back slashes not needed.

Indeed the parser doesn't need them to be escaped within the character class, but I always find it much friendlier (even if it is uglier) for the human parser.