Turns out when you tell Windows 7 something like:
[pre]foo this* that*[/pre]
the first * and the second * have different meanings. The first * means "any character(s)"; the second means "the string that matched the previous regex."
Two questions:
[ol 1]
[li]Is there a way around this stupidity (other than using a different OS)?[/li]
[li]Are there any easy ways to search within files or compare files from the Windows Explorer GUI?[/li]
[/ol]
Thanks. Full-length rant below, no obligation to read it....
%%%%%
I wanted to compare two files. The filenames are similar except for embedded date and time stamps:
[pre]
03/22/2016 04:18 PM 87,446 thisbox-20160322-1600.txt
03/28/2016 09:53 AM 87,589 thisbox-20160328-0950.txt
[/pre]
So the command line went:
[pre]C:\>fc thisbox-20160322-*.txt thisbox-20160328-*.txt[/pre]
I figured no need to type in the rest. Global substitution would take care of it. Ha. Windows 7 came back with:
[pre]Comparing files THISBOX-20160322-1600.txt and THISBOX-20160328-1600.TXT
FC: cannot open THISBOX-20160328-1600.TXT - No such file or folder[/pre]
You see what it did? It picked up "1600.TXT" as a match for "*", as it should have--and then tried to match it in the next parameter, which no one told it to do.
In most global-substitution schemes, "*" means "any combination of 0 or more characters." "What matched the previous global expression" is expressed quite differently. Not with Windows 7.
The same thing happens with ???? substituted for *, by the way, and permutations of * and ????. Also when you end the search key with *.
[pre]foo this* that*[/pre]
the first * and the second * have different meanings. The first * means "any character(s)"; the second means "the string that matched the previous regex."
Two questions:
[ol 1]
[li]Is there a way around this stupidity (other than using a different OS)?[/li]
[li]Are there any easy ways to search within files or compare files from the Windows Explorer GUI?[/li]
[/ol]
Thanks. Full-length rant below, no obligation to read it....
%%%%%
I wanted to compare two files. The filenames are similar except for embedded date and time stamps:
[pre]
03/22/2016 04:18 PM 87,446 thisbox-20160322-1600.txt
03/28/2016 09:53 AM 87,589 thisbox-20160328-0950.txt
[/pre]
So the command line went:
[pre]C:\>fc thisbox-20160322-*.txt thisbox-20160328-*.txt[/pre]
I figured no need to type in the rest. Global substitution would take care of it. Ha. Windows 7 came back with:
[pre]Comparing files THISBOX-20160322-1600.txt and THISBOX-20160328-1600.TXT
FC: cannot open THISBOX-20160328-1600.TXT - No such file or folder[/pre]
You see what it did? It picked up "1600.TXT" as a match for "*", as it should have--and then tried to match it in the next parameter, which no one told it to do.
In most global-substitution schemes, "*" means "any combination of 0 or more characters." "What matched the previous global expression" is expressed quite differently. Not with Windows 7.
The same thing happens with ???? substituted for *, by the way, and permutations of * and ????. Also when you end the search key with *.