We have the same temperament then - I've typed in a few responses without sending them.
I hope this reply 'does better' in presenting the approach.
I haven't seen your Parser code (nor do I want to because I'd hate to be in your shoes and I'm not seeking to 'better' your efforts).
The inescapable truth with the system as it stands today, is the fact a dot-character is treated as a delimiter.
That makes it unique, because it is the only delimiter character which can
also appear in the text to be parsed when it is NOT delimiting anything!
And that's why the occurence of a dot as a normal char in a filename causes syntax complications (nay mayhem) when users create EFT statements.
So, how to tell 'dot-as-a-delimiter' from just any old character dots?
I'll bet the only dot that really IS a delimiter is the one separating the filename from the filetype.
While they are easy to find in a "path\filename.filetype" string, they might be more tricky to recognise in an EFT entriy coded by a user.
If spotting a dot-delimiter in a EFT entry is an issue, it is within your control to prevent it happening - don't allow users to enter them!
Specify in the documentation that an EFT statement syntax requires that the '.' that separates the filetype from the filename must be replaced by a '>' .
Now you can 'internally' replace the "dot-as -a-delimiter" with another unique character code which users cannot type.
You could use a char not allowed in filename (<|>), or a hex code like, 07, 09, 0A, 0B, 0C as a placeholder for the 'dot-delimiter'.
When your Parser is 'looking' for the dot-delimiters (say x'07'), normal dots (x'2E') become just another character which can be wild-carded, etc like anthing else.
I admit that this might be a most impractical suggestion but your reply doesn't provide any reasoning to that effect.
It will require some changes to your Parser but I suspect they may well simplify the logic.
To prevent performace issues, I also suggested where/when the dot-replacement process might occur:
Using the above concept of '>' and x'07'...
- The EFT statements would have the replacement (x'07' to '>') applied at he time they are read from storage and ('>' to 'x07') at the time they are written to storage.
The user is totally unaware of this happening. EFT lists, even if lengthy, would incur less of a performance hit than using XFORM to load or save a normal file.
- The filename to be tested against the EFT rules would need to be changed from '.' (x'2E') before the filetype to x'07' just once prior to you beginning the EFT Scan.
I'm sorry that the colloquial 'what if' intro to my suggestion offended you.
Please don't get hung up on two words and when you reply, but help me understand why the proposal is impractical.
You asked for a use case. I can give you two in one.
As I mentioned in an earlier post, combine the LYRICS application you illustrated in the Quick Starter Guide with my first EFT experience using the CFGMAINT file.
(1) User expectation
Any user with experience of Windows and use of wild-cards would expect that a filename like
CFGMaint EXP 2022-10-27 10.54.TXT
would be matched by a pattern of
CFGMaint EXP*.TXT
But EFT needs a more complex pattern of CFGMaint EXP*.*.TXT because the '.' in the "10:54" sequence is erroneously treated as a delimiter.
(2) Your LYRICS application
The filenames included both Track Title and Artist Name.
A quick peek at my iTunes library shows many track titles which include one or more 'dots' and many Artists Names that include one or more 'dots'.
So, depending on exactly what the wild-card is masking, you will probably need a different EFT statement for every extra possible dot somewhere in the filename.
The EFT statement that matches a song filename which contains no dots may(!) well not match one that contains any dots.
The EFT statement that matches a song filename containing one dot may(!) well not match one that contains two dots, and so on.
All because the wild-card '*' is only 'wild' until it hits the next dot.
How can anyone code one (or even a group of) EFT statement(s), and be CERTAIN that it will match ALL relevant targets if the addition of a single dot might throw EFT off the scent?
That's the use case.