The most mind-bogglingly stupid behavior I've ever seen in an OS (and I started with CP/M) 1

[jmkelly]

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 *.

 

[guitarzan]

>the first * and the second * have different meanings.
No they don't. They are the same. More specifically, whatever * is on the left is what it will be on the right. Makes sense to me.

>The most mind-bogglingly stupid behavior I've ever seen in an OS
Hyperbole much?

I'm sure it is possible to do what you want with a FOR / IN / DO statement. Then, you control the behavior rather than hoping a command will work as per your precise needs.

http://ss64.com/nt/for.html

 

[DSummZZZ]

I don't think it's mind boggling stupid at all. The OS can't assume you want to compare just any old file with the "left" file. You could end up comparing the "left" file with the "left" file. Useless. It has been that was as long as I can remember using FC.
What is (I won't say stupid) sloppy is trying to compare more than one file with more than one file using wildcards.

Anyway, there is no file compare within Explorer, but there are GUI based file compare utilities and editors you could down load.
Also, after doing a search from Explorer using [Windows Key] + F in a particular folder, you can search within files by clicking the "File Contents" button.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[strongm]

>Makes sense to me.
And me. It is also the documented behaviour (since DOS 3 or 4, as I recall, so late 1980s). For example,

https://technet.microsoft.com/en-gb/library/bb490904.aspx

Here's the relevant extract

•Using wildcards

You can use wildcards (that is, * and ?) in filename1 and filename2. If you use a wildcard in filename1, fc compares all the specified files to the file specified by FileName. If you use a wildcard in filename2, fc uses the corresponding value from filename1.

 

[goombawaho]

Always
Blame
The
Computer
NOT
Yourself
!!!!!!!

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[SamBones]

That may be the way Microsoft chose to do it, but that doesn't mean it's correct. In a proper OS like UNIX, the wildcard means one thing, try to match this file with a wildcard, just as jmkelly was expecting.

And the first and second '*' DO have different meanings. The first says look in the current directory for files that match this pattern. The second asterisk doesn't have that meaning at all. It just gets replaced with whatever the first one matched. If MS was smart, the asterisk would do the same thing regardless of position in the command line, and come up with a different character or pattern to replace what was matched (like the '&' or '\1' in a sed search/replace).

I share jmkelly's rage. He is justified.

 

[xwb]

Makes sense to me. Have you discovered the tab key for command line completion? Type

fc thisbox-20160322-tab thisbox-20160328-tab

Tab is only one key: no shift and is always in the same place.

 

[strongm]

Seriously? Am I allowed to feel rage, then, because the Unix shell wildcards won't match leading dots, and therefore fail to meet jmkelly's assertion that a global wildcard should match "any combination of 0 or more characters."

 

[guitarzan]

SamBones:

Yep, that is one way of looking at it.

Another is that NO, perhaps they would be smart to make DIFFERENT symbols to do what YOU want! But they didn't go that route... they chose to use one symbol (*) to mean one thing (all matches found in the first parameter). When you use TWO wildcards, you are repeating that symbol (*), so whatever the wildcard matches is REPEATED!!!

Maybe you do not like that, but that is how it works, and it is consistent and makes logical sense. But it is not the only way it could work..... yours and jmkelly's interpretations are perfectly valid also! It just illustrates what DSummZZZ alluded to: it awkward to use two wildcards in one statement. You end up hoping that the programmers way back when chose YOUR interpretation of how two wildcards should work!

 

[jmkelly]

Thanks to all for your comments. I guess you can tell I read MS-DOS documentation as little as I possibly can. It still irks me that in a GUI that's 20 years old, if I want to compare two files I still have to pop to a shell (or download an add-on utility). Of course I'm not sure my pet Linux distro is any different in that regard, but popping to a shell in Unix/Linux doesn't seem like that big of a deal (which probably says nothing good about Unix/Linux!). Not biased much, not me.
My idea of proper regex syntax is, your regex symbols always mean the same thing, and if you want to do something other than match, like refer back to something already matched, you use something like (%1), (%2), etc. So you could write a line like:

[pre]
ren foo*bar*baz* foo-(%1)-bar-(%2)-baz-(%3)
[/pre]
and foo1bar2baz3 would become foo-1-bar-2-baz-3, fooFOObarBARbazBAZ would become foo-FOO-bar-BAR-baz-BAZ, etc. Very useful behavior, IMHO, and more straightforward than "* = any char(s) first time, those same chars second time."

 

[Beilstwh]

So if you like UNIX commands, then simply load the Cygwin and put the bin directory in your PATH. all the commands, including find, work just fine.

Bill
Lead Application Developer
New York State, USA

 

[strongm]

> It still irks me that in a GUI that's 20 years old

What is irksome is that Microsoft used to include a GUI comparison tool, windiff, in XP (and earlier

 

[hairlessupportmonkey]

All you need is in free file sync

http://www.freefilesync.org/manual.php?topic=comparison-settings

ACSS - SME
General Geek

 

[strongm]

Don't think that addresses the OP at all. FileSync is a pretty capable folder synchronisation tool, but you can't select specific files to compare, you can't compare files in the same folder, and you can't compare content of files with different names.

 

[hairlessupportmonkey]

I. Compare by file time and size

This variant considers two files with the same name as equal when both modification time and file size match. The following categories are distinguished:

file exists on one side only
left only
right only
file exists on both sides
different date
left newer
right newer
same date
equal
conflict (same date, different size)


II. Compare by file content

Two files with the same name are marked as equal if and only if they have the same content. This option is more useful for consistency checks rather than backup operations since a bitwise comparison can be slow.

file exists on one side only
left only
right only
file exists on both sides
equal
different content


III. Compare by file size

Two files with the same name are considered equal if they have the same file size. Since it's possible for files with the same size to have different content, this variant should only be used when file modification times are not available or reliable, e.g. in certain MTP and FTP synchronization scenarios.

file exists on one side only
left only
right only
file exists on both sides
equal
different size

ACSS - SME
General Geek

 

[hairlessupportmonkey]

You might even get it to compare files with different names. Havent tried.



ACSS - SME
General Geek

 

[strongm]

I am well aware of what FileSync does - you might want to read the documentation you have quoted very carefully.

>You might even get it to compare files with different names. Havent tried.
You haven't tried? So you don't even know? I'll tell you, as above, it doesn't.

 

[hairlessupportmonkey]

OK, before I get my arms and legs pulled off

I have used Autoit a small amount (ducks) and there are some nifty tools / commands in that to *help*

https://www.autoitscript.com/site/autoit/

You can write some pretty flexible scripts and applications. Even your own GUI.

No, I haven't used it for this purpose.



ACSS - SME
General Geek

 

[Beilstwh]

Like I said earlier, load the CYGWIN onto your windows machine and use the unix commands like find and comp which have MANY more options then the windows command.

Bill
Lead Application Developer
New York State, USA

 

[johnherman]

Another advantage to Bill's suggestion of getting unix utilities - the unix sort is much more flexible than the MS sort.

==================================
adaptive uber info galaxies (bigger, better, faster, and more adept than cognitive agile big data clouds)