fixing a major screwup (hopefully with bru and a good regex)

[stevegu]

hi all - i am new here, but have spent about 90 mins reading here and about regex first

so... i screwed up a large bunch (tens of thousands) of folder names

i had wanted to get a count of the total number of folders and sub-folders on a data drive, and was looking for software that would do that for me - unfortunately i found this software: http://www.brothersoft.com/folder-counter-217085.html

but instead of counting all the folders and subfolders and then just giving me the total (yes, i ran it before finding more about it - really dumb, i know), instead it counted the number of files in all of the folders and sub-folders, and then appended that number onto the end of each folder and sub-folder's name, in parentheses, in the form: "folder name (xyz)"

so, i found bru and read some of the forums for a regex which might clean this mess up (there is no "undo" function for this "folder counter" program, which apparently is discontinued and for which there is no forum) - i downloaded the recommended regex coach and started the recommended tutorials at http://www.regular-expressions.info/ - but was hoping that perhaps stefan or GMA or someone here might be able to guide me a bit and speed up my learning curve

what i think i need is a regex that will go to the end end of each folder (but not of each file), and if an end paren ")" exists (only at the very end - ie., nothing to the right of it) which is also preceded by an integer (i have legitimate folder names with parens at the end preceded by an alpha character but no unwanted "folder counted" number in parens at the end), then to delete that end paren and each preceding integer (up to 4 - no folder has more than 9999 files) until a start paren is found and also deleted

so every (x) or (xy) or (xyz) or (xyza), where xyz and a are integers, found only at the very end (nothing to right of end paren) of each folder name (but not file name) should be deleted.

Any help or hints on this for me to try would be very much appreciated

in the meantime i will learn as much as i can about regex on my own in the time i have to do so

thanks much
steve

[stevegu]

ok, found someone to help me with the regex expression, so wanted to report back, and give some feedback on improving BRU (besides a slight renaming "glitch", BRU was awesomely industrial strength, handling this giant job well)

so here is the regex expression that worked (that michael aka mash at regexadvice.com nailed):

pattern:
^(.+)\(\d+\)$

Replacement string:
\1


and here is the link to the regexadvice.com forum posts:
http://regexadvice.com/forums/ShowThread.aspx?PostID=55338#55343

as described, the only problem i had was with BRU's folder renaming convention - i chose to rename all subfolders as well, but what happened was, BRU renamed top level folders before it renamed the sub-directories, which then caused BRU to path error out because the subfolder didn't exist (it's parent's name had obviously changed)

as a result, i had to click through errors probably 2000+ times (out of over 30,000 folders it searched through for the regex renaming) and also had to run BRU 6 or 7 passes so it could reload the new paths so to get through all the subdir layers

one solution for improving BRU would be to have it rename the most deeply embedded folders first

or another would be to at least allow it to have a "silent operation mode" where it continues past each error if you choose, so to avoid the need to click through each one - this would still require many BRU passes to allow reloading the corrected paths, so this isn't the most elegant solution, but would be much much better and easier than needing to manually click "continue" so many times

otherwise, BRU did an admirable job cleaning up the mess with the added regex capability - how did we survive without this before??

thanks and best
s

[stevegu]

one more feature that would be nice would be to be able to save a log of all the error messages, as well as of all the successful renames

thx again

[stevegu]

lastly, perhaps another useful BRU feature (possibly related to the need for a function allowing the renaming of the deepest subfolder levels first, so path errors aren't created further down) would be to be able to select whether to display (and therefore to process) the folders and subfolders in alphabetical order (which is the unchangeable default of how it is done now), or in tree-structure order, which would process each folder and all its sub-folders (in cases where the subfolders are NOT alphabetical with the parent folder) before processing the next folder hierarchy - and maybe even in other possibly useful alternative orders