Solved DIR command : weird response

July 4, 2019 at 07:52:04
Specs: Windows 7, 8GB
I've come across this multiple times, and each time I figure whether this is a bug or not.
I can't seem to find it in Google

This is the case:

Presume a file called test.abc to be existing:

C:\temp> echo X > test.abc


When I do the below query, I'm actually looking for other files, but the above file - test.abc - is nevertheless listed as matching my query:

C:\temp> dir *abc*.* /b
test.abc

C:\temp>


Now I see that the string "abc" does appear in the reported file, but I can't explain this:
I'm asking that the string named "abc" (without double quotes) to be present in the part of the file BEFORE a dot.

The dot is not a wildcard according to Microsoft (* and ? is), so why is he doing this ?

message edited by Looge


See More: DIR command : weird response

Reply ↓  Report •

✔ Best Answer
July 4, 2019 at 09:27:24
It's not a wildcard, it's just ignored. The logic goes back to the FAT12/FAT16 days, where the period in "name.extension" was implicit. FA32 and NTFS explicitly save the period, but the pattern "*.*" still had to return all files, with and without extension, with and without a period. Whoever wrote the DIR function probably found it easier to just strip any ".*" from the file search. Powershell doesn't have to follow conventions from the late 1970's, so it doesn't.

You won't find any official documentation on it, much like anything else about CMD, but if you have a Microsoft service contract with credits / hours to burn you could put out a call to any MS graybeards that studied CMD's logic. If one answers your call, he'll probably give all kinds of warnings that the behavior isn't binding, and is subject to change.

Is it a bug? Yes. Will it ever change? No.

EDIT: It could also come from FindFirstFile(), but I'm apparently not going to write a C++ program to test it.

How To Ask Questions The Smart Way

message edited by Razor2.3



#1
July 4, 2019 at 08:05:19
Not weird, just the way things are. The dot in a wildcard expression can match a single dot or no character. That means that *.* can match blank, and so *txt*.* can match anything that *txt would match.

Try doing "dir *" and "dir *.*" on a directory containing files with and without extensions.

Entirely predictable once you understand the rules, so not weird.

Edit: As an aside, note that if you were to use the more modern PowerShell, rather than the old-fashioned command prompt, you would find that things work in the way you expect.

message edited by ijack


Reply ↓  Report •

#2
July 4, 2019 at 08:17:14
I have two questions with that: do you know of Microsoft information that confirms that the dot is actually a wildcard ?

Two, and that may the more actual problem: how do I do this correctly ? How do I look for text that is ONLY in the file name (before the dot), not in the extension ? ( Forget about files without extension, I'm not concerned with these )


Reply ↓  Report •

#3
July 4, 2019 at 08:26:49
> Edit: As an aside, note that if you were to use the more modern PowerShell, rather
> than the old-fashioned command prompt, you would find that things work in the
> way you expect.

Yes but is not relevant to my question


Reply ↓  Report •

Related Solutions

#4
July 4, 2019 at 08:55:44
There's a Microsoft blog here that explains things rather more fully: https://blogs.msdn.microsoft.com/je...

Note that "." is not a wildcard per se, but has a very specific meaning.

I've given you the solution - use a modern command processor. That you feel it is not relevant is - with all respect - not my problem.

message edited by ijack


Reply ↓  Report •

#5
July 4, 2019 at 09:27:24
✔ Best Answer
It's not a wildcard, it's just ignored. The logic goes back to the FAT12/FAT16 days, where the period in "name.extension" was implicit. FA32 and NTFS explicitly save the period, but the pattern "*.*" still had to return all files, with and without extension, with and without a period. Whoever wrote the DIR function probably found it easier to just strip any ".*" from the file search. Powershell doesn't have to follow conventions from the late 1970's, so it doesn't.

You won't find any official documentation on it, much like anything else about CMD, but if you have a Microsoft service contract with credits / hours to burn you could put out a call to any MS graybeards that studied CMD's logic. If one answers your call, he'll probably give all kinds of warnings that the behavior isn't binding, and is subject to change.

Is it a bug? Yes. Will it ever change? No.

EDIT: It could also come from FindFirstFile(), but I'm apparently not going to write a C++ program to test it.

How To Ask Questions The Smart Way

message edited by Razor2.3


Reply ↓  Report •

#6
July 4, 2019 at 12:04:33
Razor2.3:

Is it a bug?

Of course not, it simply another undocumented feature. :-)

MIKE

http://www.skeptic.com/


Reply ↓  Report •

#7
July 4, 2019 at 12:17:01
"Is it a bug? Yes."

I think it was a deliberate design decision. People expect "*.*" to return all files, not just those with an extension, to remain consistent with DOS. (To be fair, in the DOS days almost all files had some extension.) The logical consequence of that is that ".*" has to accept a blank expansion, and the rest follows.


Reply ↓  Report •

#8
July 4, 2019 at 12:56:54
Having special logic to handle "*.*" isn't the bug. It's how it's behaving for the OP. It's not that I can't see what is happening. I've even pointed out the basis for the special logic. It's that it's an unintuitive gotcha that goes against every new user's expectations. Ignoring an explicit period your user gave you for an implicit period you add is incorrect behavior.

If I wanted to introduce logical fallacies, and I kinda do, I'd say the only reason you're not agreeing it's a bug is because you've spent so long learning what CMD does that you've lost sight of what it should do.

How To Ask Questions The Smart Way

message edited by Razor2.3


Reply ↓  Report •

#9
July 4, 2019 at 16:27:32
I'm a perfectionist. That means I like to fix things that are almost perfect.

> you've spent so long learning what CMD does ...

I think you meant "you've spent so long knowing what CMD does ..."

Same here, even if I haven't used it much in recent years.

-- Jeff, in Minneapolis


Reply ↓  Report •

#10
July 5, 2019 at 00:04:16
"Having special logic to handle '*.*' isn't the bug."

Except, if you actually read what the Microsoft developer explained, that's not what happens. The special logic is to handle '.*' or '.?', not '*.*', and the rest follows.

But that's OK - what matters is what happens rather than what either of us believes.


Reply ↓  Report •

#11
July 5, 2019 at 00:12:45
Yes, and what happens is buggy! :P

How To Ask Questions The Smart Way


Reply ↓  Report •

#12
July 5, 2019 at 00:35:18
> I've given you the solution - use a modern command processor. That you feel it is not
> relevant is - with all respect - not my problem.
>

No, you haven't given THE solution, you have given A solution.

message edited by Looge


Reply ↓  Report •

#13
July 5, 2019 at 00:42:23
Thanks, that answers two questions:
- It's a bug
- It's not documented (blog is helpful but not considered part of documentation)

message edited by Looge


Reply ↓  Report •

#14
July 5, 2019 at 00:50:27
-> solution :

dir *abc*.^<* /b



Reply ↓  Report •

Ask Question