Regular expressions in FOR's set?

#1
I guess I/m using regular expressions here ... right?

Code:
v:\> for %f in ( "::.*\..x." ) echo %f
V:\10.txt
V:\100.txt
V:\a b.txt
V:\ab.txt
V:\abc.txt
V:\alphabet.txt
V:\anagram.exe
V:\avetemp.txt
(snip)
If so, why doesn't the following find any files (or, it seems, even look for them)?

Code:
v:\> for %f in ( "::..\..x." ) echo %f
"::..\..x."
I'd expect it to find filenames (of which there are plenty) with at least two characters before a "." followed by at least three characters, the second of which is "x".
 

rconn

Administrator
Staff member
May 14, 2008
10,321
94
#2
> If so, why doesn't the following find any files (or, it seems, even
> look for them)?
>
> Code:
> ---------
> v:\> for %f in ( "::..\..x." ) echo %f
> "::..\..x."
> ---------
> I'd expect it to find filenames (of which there are plenty) with at
> least two characters before a "." followed by at least three
> characters, the second of which is "x".
WAD - FOR only looks for matching filenames if you include wildcards, and
you don't have any. So FOR assumes you want to substitute a text string.

(And no, I cannot assume that a "::" is equivalent to a wildcard, as it
would break CMD compatibility. Use DO instead.)
 
#3
On Thu, 29 Oct 2009 22:13:17 -0500, rconn <> wrote:

|---Quote---
|> If so, why doesn't the following find any files (or, it seems, even
|> look for them)?
|>
|> Code:
|> ---------
|> v:\> for %f in ( "::..\..x." ) echo %f
|> "::..\..x."
|> ---------
|> I'd expect it to find filenames (of which there are plenty) with at
|> least two characters before a "." followed by at least three
|> characters, the second of which is "x".
|---End Quote---
|WAD - FOR only looks for matching filenames if you include wildcards, and
|you don't have any. So FOR assumes you want to substitute a text string.
|
|(And no, I cannot assume that a "::" is equivalent to a wildcard, as it
|would break CMD compatibility. Use DO instead.)

What CMD compatibility?

I think of "::" as meaning "what follows is a regex". DIR gets it right with
the exact same spec ("::..\..x.").

I can't use DO on the command line.
--
- Vince
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,502
46
Albuquerque, NM
prospero.unm.edu
#4
WAD - FOR only looks for matching filenames if you include wildcards, and you don't have any. So FOR assumes you want to substitute a text string.

(And no, I cannot assume that a "::" is equivalent to a wildcard, as it
would break CMD compatibility. Use DO instead.)
So, if I understand correctly ... you could tack a useless .* ("zero or more of anything") on the end of the regex, and FOR would see it as a wildcard expression?

Code:
for %f in ( "::..\..x..*" ) echo %f
 
#5
On Thu, 29 Oct 2009 22:55:31 -0500, Charles Dye <> wrote:

|So, if I understand correctly ... you could tack a useless .* ("zero or more of anything") on the end of the regex, and FOR would see it as a wildcard expression?
|
|
|Code:
|---------
|for %f in ( "::..\..x..*" ) echo %f
|---------

As kludges go, that's not too bad. But it's still a kludge. IMHO, "::" should
be a tip-off that the following is a regex and thus a file spec (since I can't
think of another reason to put a regex in FOR's set).
--
- Vince
 

rconn

Administrator
Staff member
May 14, 2008
10,321
94
#6
> |So, if I understand correctly ... you could tack a useless .* ("zero
> or more of anything") on the end of the regex, and FOR would see it as
> a wildcard expression?
> |
> |Code:
> |---------
> |for %f in ( "::..\..x..*" ) echo %f
> |---------
That's correct.


> As kludges go, that's not too bad. But it's still a kludge. IMHO,
> "::" should be a tip-off that the following is a regex and thus a
> file spec (since I can't think of another reason to put a regex in
> FOR's set).
Not going to happen -- I've seen a number of .CMD files where the FOR set is
a string set containing (or even starting with) ::, and they're definitely
NOT intended to be regular expressions.

As I've mentioned a few dozen times in the past, FOR is very strictly
limited in terms of possible enhancements due to CMD compatibility concerns.
 
#7
rconn wrote:
| As I've mentioned a few dozen times in the past, FOR is very strictly
| limited in terms of possible enhancements due to CMD compatibility
| concerns.

Since DO is not usable from the command prompt, FOR is our only option for
"once-only" tasks, short of Vince's new CDO idea. How about a new command,
REPEAT, which would be essentially a duplicate of FOR, but without the CMD
compatibility baggage? It could share most of its code with FOR, and only
deviate when one of the compatibility issues comes into play.
--
Steve
 
#9
On Fri, 30 Oct 2009 07:22:09 -0500, rconn <> wrote:

|As I've mentioned a few dozen times in the past, FOR is very strictly
|limited in terms of possible enhancements due to CMD compatibility concerns.

I appreciate that (and keep forgetting it). But it has been that way for a long
time and 4NT/TCC has ... well ... remained compatible. CMD needs to be
one-upped!

--
- Vince
 
#10
On Fri, 30 Oct 2009 07:21:57 -0500, rconn <> was
claimed to have wrote:


>As I've mentioned a few dozen times in the past, FOR is very strictly
>limited in terms of possible enhancements due to CMD compatibility concerns.
This might be a stupid question, but is there an alternative that works
from the command line and is nearly as flexible?

It occurs to me that maybe a better long term solution would be some
sort of FOR eXtension (similar to PDIR), that would be designed without
concern for CMD compatibility, while still maintaining simple looping
capabilities without leaving the command line.