Update: FWIW, this "undocumented feature" is deep within the OS, using '<' in the argument to FindFirstFile/FindNextFile apis also treats it the same way as '*'. It appears that this is the only undocumented character that exhibits this behaviour. Weirdness indeed.
What can I say? Sorry, but I completely misread the sense of your constanation. Your right! It appears that CMD is treating '<' in the same way as '*'
P:\test>dir "<.bak" Volume in drive P is Winnt Volume Serial Number is D822-5AE5 Directory of P:\test 27/08/03 00:47 608 286744.pl8.bak 28/08/03 20:20 801 287272.pl8.bak 31/08/03 12:42 729 287900-2.pl8.bak 31/08/03 09:58 1,056 287900.pl8.bak 05/09/03 15:37 2,015 289016-2.pl8.bak 05/09/03 09:56 1,092 289106.pl8.bak 05/09/03 17:26 1,165 289250.pl8.bak 08/09/03 10:49 742 b-sort.pl8.bak ...
I'm really surprised that I have never encountered this behaviour before...but then, I would never have thought to look for it:)
It is weird, as far as I am aware, completely undocumented, and very annoying. I cannot even begin to fathom how and why this would have been done!
In reply to Re: Re: Re: Unexpected file test (-f) result on Windows
by BrowserUk
in thread Unexpected file test (-f) result on Windows
by DaveH
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |