How to? Do a particular regular expression...

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Please excuse my by now well-documented density, but I want to simultaneously match several file types in a "PDir" command. I have tried (using what is, as far as I can tell, POSIX "Extended Regular Expressions" syntax):
Code:
PDir /A-D /(...fields that I am interested in...)  "::.\\\.this$|.\\\.that$|.\\\\.andanother$|.\\\\.ext$"
And this, put simply, doesn't work at all:
Code:
TCC: (Sys) The system cannot find the file specified.
 "Z:\The Current Directory\::.\\\.this$|.\\\.that$|.\\\\andanother$|.\\\ext"
So, several questions:

Does "PDir" even support regular expressions? (The docs say "extended wildcards", but not "regular expressions.)

Does TCC even support POSIX "Extended Regular Expression Syntax" at all?

Why is the directory name included in the error message? (I have a guess, but it's only a guess)...

And most importantly, using any of the the supported regular-expression syntaxes (I'm not fussy), how do I express what I am (obviously, I hope) trying to express?

And, as I side question that came up in attempting to do the above, what is the exact syntax of the option command to set the regular syntax to POSIX? "Option regularexpressionsyntax" doesn't do it ("Unknown option name"). (Rex, it would be nice if all of the option names were documented somewhere. If it is, either in the local or online help file, I can't find it...)
 
Feb 23, 2012
238
3
#2
Pdir definitely supports regular expressions; I use regular expressions with Pdir all the time.
What exactly are you trying to find? Can you provide a real example of a regular expression string and the filename that you expect it to find?

Please excuse my by now well-documented density, but I want to simultaneously match several file types in a "PDir" command. I have tried (using what is, as far as I can tell, POSIX "Extended Regular Expressions" syntax):
Code:
PDir /A-D /(...fields that I am interested in...)  "::.\\\.this$|.\\\.that$|.\\\\.andanother$|.\\\\.ext$"
And this, put simply, doesn't work at all:
Code:
TCC: (Sys) The system cannot find the file specified.
"Z:\The Current Directory\::.\\\.this$|.\\\.that$|.\\\\andanother$|.\\\ext"
So, several questions:

Does "PDir" even support regular expressions? (The docs say "extended wildcards", but not "regular expressions.)

Does TCC even support POSIX "Extended Regular Expression Syntax" at all?

Why is the directory name included in the error message? (I have a guess, but it's only a guess)...

And most importantly, using any of the the supported regular-expression syntaxes (I'm not fussy), how do I express what I am (obviously, I hope) trying to express?

And, as I side question that came up in attempting to do the above, what is the exact syntax of the option command to set the regular syntax to POSIX? "Option regularexpressionsyntax" doesn't do it ("Unknown option name"). (Rex, it would be nice if all of the option names were documented somewhere. If it is, either in the local or online help file, I can't find it...)
 
Feb 23, 2012
238
3
#3
To be clearer:
If you want PDIR to find all files with extensions txt, pdf, or doc, you can use the OR operator in the following way:
pdir "::txt$|pdf$|doc$"
That line works to print all files that end with one of those three strings.
However, you seem to be after something else, with all of your ".\\\\" and ".\\\." prefixes. What are you trying to accomplish with those prefixes?
 

samintz

Scott Mintz
May 20, 2008
1,203
11
Solon, OH, USA
#4
It looks like you are trying to display all the files with certain extensions. Like all the .c, .cpp, .h, and .hpp files in a directory.

pdir "::\.(c|cpp|h|hpp)$"

-Scott
 
#5
To list all files with a fixed (small) set of extensions, you should use INCLUDE LISTS, not regular expressions, e.g. Scott's example:

pdir *.c;*.cpp;*.h;*.hpp

Note that AFAIK regular expression syntax is for filenames, not whole paths. Use the standard /s (or /s3, /s+5) style syntax; or you can use the d1\**\xxx syntax in the middle of the path to indicate "any depth below this".
 
#6
Avi and Scott, you both hit the nail on the head as to what I am trying to do, and you both you identified what the problem(s) were. I was (stupidly! :confused:) looking for a back slash immediately preceding the extension when I shouldn't have been looking for a backslash at all given that it would only appear in the full path of the file much less appearing in the file name immediately preceding the extension. But your suggested solution was only partially correct in that it also identified files with extensions that were not immediately preceded by a period (such as ".atxt"), Avi. (Frankly, I am a stickler.) So the final expression that did exactly what I wanted was "::\.(this|that|andanother|ext)$" (and the double quotes are necessary).

As always, thank you both very much. - Dan
 
#7
>>> "::.\\\.this$|.\\\.that$|.\\\\.andanother$|.\\\\.ext$"

Hmmm! You seem to be looking for files with names that end in

?\.this
?\.that
?\.andanother

Do you have files with such names? I'd get rid of those literal backslashes ("\\") and the dot before them.

"::\.this$|\.that$|\.andanother$|\.ext$"

And in the third and fourth spec, thete's an extra backslash. The last one, for example, means

[any char]\\[any char]ext[end of line] (I doubt that's what you meant).
 
#8
Steve, I (for some reason) didn't see your posting about "INCLUDE LISTS" (for I don't know whatever reason(s)) until after I had solved the problem using multiple patterns. And "INCLUDE LISTS" just fall into that general category of "embarrassment of riches" that TCC has so many of. However, is there really any advantage to doing that given that the "pattern matching" solution is already coded, tested, and working?
 
#9
Once you solved a problem, alternate solutions are usually irrelevant. I had used include lists since 4DOS days; the code is presumably much simpler (and thus faster) than the regex method. However, if your tested solution is "fast enough", changing may cause more problems than benefit (esp. detecting mistypes). So I'd say "use what you have".