DosTips.com

Hello. I'm searching, but I cannot found the post where was explained the undocumented wildcards of dir command:

<

>

Please someone can provide the link to the post?.

I am not following your redirection examples. What do you mean by that?

I don't know of any other wildcards besides ? and *.

I usually use Google to search the site for me. The builtin forum search is limited.

dir wildcard site:dostips.com

I had completely forgotten about those beasts, and I no longer remember any of the details on how they work.

I know I have seen a discussion about them. But I can't remember if it was on this site, or if I participated.

A quick test though shows that they are generally available for use with commands that accept wildcards, not just the DIR command.

@Squashman - try DIR "<", DIR "<<<<<<<<<", DIR ">", DIR ">>>>>" etc. You will be surprised


Dave Benham

may be this?
viewtopic.php?f=3&t=5057

Ah yes. Now I remember that thread. Not sure why my Google Foo could not find it.

@npocmaka: yes, that is. thanks.
I will read it. I have this info, that after read it I will merge.

The following wildcard characters can be used in the pattern string.

Wildcard character  Meaning

* (asterisk)
Matches zero or more characters

? (question mark)
Matches a single character

" 
Matches either a period or zero characters beyond the name string

>
Matches any single character or, upon encountering a period or end of name string, advances the expression to the end of the set of contiguous >

<
Matches zero or more characters until encountering and matching the final . in the name

For example I found that you can found files without extension with this:
files in the dir:

a
bbb

find files without extension of 1 length:

C:\dev>dir /b ">"
a

find files without extension of greather or equal to 1 length:

C:\dev>dir /b "<"
a
bbb

@carlos - those rules are not quite right.

@npocmaka - I don't see how you resurrected that thread, unless you had it bookmarked. I had it bookmarked, but I forgot to look. But even if I had, I don't think I would have recognized the title as being relevent.

The rules I had posted in that thread are close, but still not quite complete.

EDIT - I thought I had discovered some better rules, but I was mistaken.

Below are some interesting test cases:

                |                         |      GREEDY NATURE                                                          
file            | "??.??.??" | ">>.>>.>>" | "?a?.??.??" | ">a>.??.??"
----------------+------------+------------+-------------+-------------
a               |  match     |  no match  |  no match   |  no match
ab              |  match     |  no match  |  no match   |  no match
abc             |  no match  |  no match  |  no match   |  no match
a.1             |  match     |  no match  |  no match   |  no match
ab.12           |  match     |  no match  |  no match   |  no match
abc.123         |  no match  |  no match  |  no match   |  no match
a.1.x           |  match     |  match     |  no match   |  no match
ab.12.xy        |  match     |  match     |  no match   |  no match
abc.123.xyz     |  no match  |  no match  |  no match   |  no match
a.1.x.7         |  no match  |  no match  |  no match   |  no match
ab.12.xy.78     |  no match  |  no match  |  no match   |  no match
abc.123.xyz.789 |  no match  |  no match  |  no match   |  no match

                                                         | NON-GREEDY
file            | "*.*.*"  | "*."     | "**." | "abc.*." | "*a*"
----------------+----------+----------+-------+----------+-----------
abc             |  match   | match    | match | match    | match
abc.123         |  match   | no match | match | match    | match
abc.123.xyz     |  match   | no match | match | match    | match
abc.123.xyz.789 |  match   | no match | match | match    | match

                                                         |      NON-GREEDY
file            | "<.<.<"  | "<"      | "<<"  | "abc.<"  | "<a<"    | "<a<<"
----------------+----------+----------+-------+----------+----------+--------
abc             | no match | match    | match | no match | match    | match
abc.123         | no match | no match | match | match    | no match | match
abc.123.xyz     | match    | no match | match | no match | no match | match
abc.123.xyz.789 | match    | no match | match | no match | no match | match

=========================================================

The other fascinating (and scary) discovery that jeb made was that < and > wildcards may be used in command names when executing an external command! "<st.bat" can successfully execute "test.bat".

I remember that this started from SO question and checked my favorites there

I've tested some commands that accepts wildcards to see which one will work with ">" and "<" (some commands not listed here http://ss64.com/nt/syntax-wildcards.html - I've marked them with an asterisk )


ACCEPT <>:



DOES NOT ACCEPT <>:

ftp
robocopy
where
forfiles
extrac32
expand
icacls*
more*
takeown*
find* (each filename that match the pattern in is printed like [color=#BF0000]---------- filename[/color] )
replace*

and some other commands:

OK, I think I finally understand the wildcard rules. The issue that was throwing me was the damn short 8.3 names. One has to remember that the mask is always tested against the full long name, as well as the 8.3 short name (if it exists).

The only way I could derive the rules was to work on a drive that had short 8.3 names disabled. The same rules apply to short names, it is just difficult to work them out.


Non-Wildcard character rules

Each non-wildcard character in a mask must generally match itself, with the following exceptions:

" (double quote) is totally ignored, except for the fact that it toggles quote semantics on/off. When on, poison characters and token delimiters should not be escaped. When off, then poison characters and token delimiters must be escaped.

Any combination of trailing {dot} and {space} at end of mask can match the end of name (nothing).

Any {dot} not at end of the mask can match the end of name (nothing), as long as it is immediately followed by * or ?.


Wildcard character rules

* generally matches any 0 or more characters, with one exception (see next rule). The non-greedy wild card is free to match as many or as few characters as are necessary for the remainder of the mask to match.

*. at end of mask matches any 0 or more characters except for {dot}. In actuality, the rule applies with any number of {dot} and {space} characters between the * and terminal {dot}. The regular expression for the term is "[*][. ]*[.]$"

< Matches any 0 or more characters in either the base name or the extension, but never both. A single < cannot match characters in both the base name and the extension. The {dot} is considered to be part of the base name, not the extension. This non-greedy wild card is free to match as many or as few characters as are necessary for the remainder of the mask to match.

? Matches any 0 or more characters, except for {dot}. This wildcard is greedy. The only time it matches 0 characters is when it matches the end of the name, or the position before a {dot}.

> Is identical to ?. The only difference is that it can be placed after a {dot} to prevent the {dot} from matching the end of the name.


Dave Benham

When using dots with "."/".." directories you only could add one unneeded dot:

Z:\test>dir "..."
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\test\..

24.01.2015  14:17    <DIR>          .
24.01.2015  14:17    <DIR>          ..
24.01.2015  14:17                 3 .c
               1 Datei(en)              3 Bytes
               2 Verzeichnis(se), 133.076.926.464 Bytes frei

Z:\test>dir ....
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\test\...

Datei nicht gefunden

When using them on default directories it seems that the last dot is removed and one additional dot is allowed:

Z:\>dir "test."
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\test

24.01.2015  14:48    <DIR>          .
24.01.2015  14:48    <DIR>          ..
               0 Datei(en)              0 Bytes
               2 Verzeichnis(se), 133.074.714.624 Bytes frei

Z:\>dir "test.."
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\test.

24.01.2015  14:48    <DIR>          .
24.01.2015  14:48    <DIR>          ..
               0 Datei(en)              0 Bytes
               2 Verzeichnis(se), 133.074.714.624 Bytes frei

Z:\>dir "test..."
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\test..

Datei nicht gefunden

Only when listing files it seems any number of dots (complete mask <= 256 characters) are allowed:

Z:\>dir "test.bat............................................................."
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\

22.01.2015  14:24               405 test.bat
               1 Datei(en)            405 Bytes
               0 Verzeichnis(se), 133.074.714.624 Bytes frei

No, the dot seems to be part of the extension:

Z:\>>".c" echo c

Z:\>dir "<"
 Datenträger in Laufwerk Z: ist Test
 Volumeseriennummer: 0438-EEA7

 Verzeichnis von Z:\

24.01.2015  14:17    <DIR>          .
24.01.2015  14:17    <DIR>          ..
24.01.2015  14:17                 3 .c
               1 Datei(en)              3 Bytes
               2 Verzeichnis(se), 133.076.926.464 Bytes frei

Note: All tested on WinXp home 32bit SP3.

penpen

@penpen

Note: All my tests are on Win 7.

1) Trailing {dot} / {space} issue

Your examples are comparing apples to oranges.

Yes, the number of allowed trailing dots is limited when specifying the path where the DIR scan is to take place. Also, wildcards are not allowed within the path specification.

But my rule is intended for the actual scan where wildcards are allowed.

Any number of trailing dots and spaces are allowed at the end of a folder name during the scan process

C:\test2>md test

C:\test2>dir /b /ad "tes?..  .. . ."
test

2) With regard to "<" wildcard, does extension dot belong to base name or extension?

Very interesting find - it appears that a file/folder name consisting of an extension without a base name is a special case.

C:\test2>copy nul b.x
        1 file(s) copied.

C:\test2>copy nul .x
        1 file(s) copied.

C:\test2>copy nul .b.x
        1 file(s) copied.

C:\test2>dir /b /a-d
.b.x
.x
b.x

C:\test2>dir /b /a-d "<"
.x

C:\test2>dir /b /a-d "<x"
.b.x
.x
b.x

C:\test2>dir /b /a-d "b<"
File Not Found

C:\test2>dir /b /a-d "<<"
.b.x
.x
b.x

C:\test2>dir /b /a-d "<b<"
File Not Found

So my rule still stands, with one exception:

A single < cannot match characters in both the base name and the extension. The {dot} is considered to be part of the base name, not the extension. There is one exception: If the name consists solely of an extension, without a base name, then the {dot} is considered to be part of the extension. WRONG - As penpen shows later on, it matches due to the short 8.3 name that does not have an extension

Note that this rule is counter to the normal definition of the extension. For example, the FOR command expansion modifiers always consider the dot to be part of the extension:

C:\test2>for %F in (b.x) do @echo baseName="%~nF"  extension="%~xF"
baseName="b"  extension=".x"

C:\test2>for %F in (.x) do @echo baseName="%~nF"  extension="%~xF"
baseName=""  extension=".x"

C:\test2>for %F in (.b.x) do @echo baseName="%~nF"  extension="%~xF"
baseName=".b"  extension=".x"

Dave Benham

Just to nitpick, since it's pretty obvious what you meant in the context, but there is no such thing as a pathname that "consists solely of an extension, without a base name". Technically, a file ".x" has name ".x" and no extension. For example, "dir /x .x" will show a made-up SFN name and an empty SFN extension.

From the horse's mouth: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
- "All file systems follow the same general naming conventions for an individual file: a base file name and an optional extension, separated by a period" - which implies that the name is mandatory, the extension optional.
- "However, it is acceptable to specify a period as the first character of a name. For example, ".temp"." - which implies that ".temp" is the name.

That said, names like ".temp" are uncommon in Windows, and have always been confusing even to Microsoft's own. For example, one of the well respected MSDN blogs offers the following, which directly contradicts the formal spec: http://blogs.msdn.com/b/oldnewthing/archive/2008/04/14/8389268.aspx - "Such files are considered to have an extension but no name."

And, of course, how any particular program parses ".x" is left to the respective programmers' imagination.

Liviu

That would explain why "<" matches ".x" - The designers of the "<" treat the entire name as a base name, with no extension. So no exception is needed after all.

Except...

The tests that I ran indicate a name like ".bat" is an extension:

C:\test>echo @echo It's alive!>".bat"

C:\test>.bat
It's alive!

C:\test>for %F in (.bat) do @echo baseName="%~nF" extension="%~xF"
baseName="" extension=".bat"

I think I will keep my rule with the exception as is


Dave Benham

You wouldn't be the only one, as I pointed already. However, copy that ".bat" file to a plain FAT drive, then try run it from there - the SFN will have no extension, and will fail to execute. In other words, the low-level FS (file-system) guys followed the spec to the letter, while the high-level cmd/explorer guys played it by the ear. Not so much of a surprise there

Liviu

Wow

Good to know. Thanks.


Dave Benham