ZTree.com  | ZEN  | About...  

 Index   Back

RFR - Wildcards   [Discuss]

By: John Gruener     Orlando, Florida  
Date: Jun 24,2002 at 07:33
In Response to: [Discuss] Rename Find and Replace (John Gruener)


The last major hurdle to finalizing a set of RFR rules is to decide what to do about wildcards.

This can get quite complex, especially if wildcards are specified in both the find and replace strings, and no limitations are put on them.

The first solution, and the simplest approach, is to not permit wildcards at all. Most basic F&R operations can be performed without them, including deletion and insertion.

Examples:

File name: ABEF.ABCDEF.ABC
Replacement: "B"3" = A3EF.A3CDEF.ABC
Deletion: "B"" = AEF.ACDEF.ABC
Insertion: "B"B3456" = AB3456EF.AB3456CDEF.ABC

If wildcards are to be permitted, then a set of rules must be established. It will be up to Kim of course whether and when wildcards might be supported, and what limitations might be imposed.

The basic limitation in the following set of rules is that the replace wildcards cannot represent a different number of characters than are found by the find wildcards, (rule 5). To avoid that limitation would require still more rules. I think that would be beyond what RFR needs to do, at least initially.

Before suggesting the wildcard rules, the following two rules should be understood for all RFR operations, (wildcards or not):

1. Filenames will be searched from left to right, replacing matching strings as they are found.
2. Replaced strings will not be included in the search for the next match.

Here then are my suggested wildcard rules:

1. Two wildcards will be supported: The question mark and asterisk.
2. Wildcards will have the same meaning as they do in the rename mask.
3. If no wildcards are used in the find string, then none may be used in the replace string.
4. If wildcards are used in the find string then they are optional in the replace string.
5. Wildcards used in the replace string must correspond in type and number to those used in the find string.
6. Wildcards in the find string may be used only between two valid filename characters.

Example file name: ABEF.ABCDEF.ABC

Embedded asterisks in find:
"B*E"3" = A3F.A3F.ABC
"B*E"3456" = A3456F.A3456F.ABC
"B*E"*" = AF.ACDF.ABC
"B*E"34*" = A34F.A34CDF.ABC
"B*E"*56" = A56F.ACD56F.ABC
"B*E"34*56" = A3456F.A34CD56F.ABC

Embedded question marks in find:
"B??E"3" = ABEF.A3F.ABC
"B??E"3456" = ABEF.A3456F.ABC
"B??E"??" = ABEF.ACDF.ABC
"B??E"34??" = ABEF.A34CDF.ABC
"B??E"??56" = ABEF.ACD56F.ABC
"B??E"34??56" = ABEF.A34CD56F.ABC

The limitation in the above rules that allows only embedded wildcards in the find string, (rule 6) is to initially give Kim an option of keeping the first wildcard implementation relatively simple and less error-prone. He could further simplify things by initially permitting only the asterisks, or by permitting wildcards in the find string but not the replace string.

Now, if we were to eliminate rule 6 entirely, all wildcards could then be used anywhere.
That would enable the following:

Example file name: ABEF.ABCDEF.ABC

Leading and trailing question marks only in find:
"?A"3" = ABEF3BCDEF.ABC
"?B"3" = 3EF.3CDEF.ABC
"B?"3" = A3F.A3DEF.ABC
"F?"3" = ABE3ABCDEF.ABC

Leading and trailing asterisks only in find:
"*A"3" = 33BCDEF.ABC
"*B"3" = 33CDEF.ABC
"B*"3" = A3.ABC
"F*"3" = ABE3.ABC

Leading and trailing question marks in find and replace:
"?A"?34" = ABEF.34BCDEF.ABC
"?B"?34" = A34EF.A34CDEF.ABC
"B?"34?" = A34EF.A34CDEF.ABC
"F?"34?" = ABE34.ABCDEF.ABC

Leading and trailing asterisks in find and replace:
"*A"*34" = 34BEF.34BCDEF.ABC
"*B"*34" = A34EF.A34CDEF.ABC
"B*"34*" = A34EF.A34CDEF.ABC
"F*"34*" = ABE34.ABCDE34.ABC

Mixed position question marks:
"?B"34?" = 34AEF.34ACDEF.ABC
"B?"?34" = AE34F.AC34DEF.ABC
"?B"34?56" = 34A56EF.34A56CDEF.ABC
"B?"34?56" = A34E56F.A34C56DEF.ABC

Mixed position asterisks:
"*B"34*" = 34A34EF.ACDEF.ABC
"B*"*34" = AEF.ABCDEF34.ABC
"*B"34*56" = 34A5634EF.A56CDEF.ABC
"B*"34*56" = A34EF.ABCDEF56.ABC

Obviously even more complex combinations of wildcards could be used, and it would be up to the user to be sure that the strings made sense, and did not do damage. (A significant potential for damage is present if one uses a leading or trailing asterisk in the find string, and does not use it in the replace string).

It should be evident that without a strict set of rules, the use of wildcards could lead to many questions as to how they should be interpreted. In fact, there may still be some questions, although I think these rules will avoid most, if not all of them.

It should also be evident that even with imposed limitations, a considerable find and replace capability would be available. Of course we could still want more, but I think this is a good start.

Finally, it should also be evident that supporting wildcards in RFR is not a trivial task, and is as complex as the rename mask itself, if not more so. It would be understandable if Kim decides not to support wildcards at all in the initial RFR implementation.

Any questions? ;-)

- John

1,872 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 64 users online (0 registered, 64 guests)
Index | Admin contact |   Forum Time: Mar 28, 2024 - 9:15 am UTC  |  Hits:62,361,133  (13,530 Today )
RSS Feed