Odd file matching behaviour using '*'

[AndrewKember]

I wonder if anyone can shed any light on my problem, or if it's a Textpad bug? The problem is this:
When I use Find In Files and put '*' in the 'In Files' field (without the quotes) Textpad doesn't search files without extensions.

My understanding of * is that in this context it means 'all files'. Is this wrong?
I'm using Textpad 4.7.3 on Win2k. Thanks for reading.
Andrew.

[mo]

*.* ?

[AndrewKember]

The problem with *.* is that it means <anything><dot><anything>.
I'm trying to search files that don't have an extension, so the <dot> is not present. Normally, this would be achieved using just * on its own, in grep or some other unixy tool.

I'm trying to search both files called things like 'mycode.c' and also 'Makefile', for example.

[MudGuard]

*. to match files without extension, *.* to match files with extension

Don't ask me why, just blame microsoft ...

Separate different patterns by a space, thus:

Code: Select all

*. *.*

should do the trick.[/code]

[AndrewKember]

Nicely done, Mudguard. This does indeed work, but raises another issue:

If *.* is one of the expressions in the In Files, all others are ignored (including *.).

It's as if a *.* search is dealt with as a different case to other searches, as though it is assumed that *.* matches everything, so no other filters are needed. Can anyone confirm this?

Thanks.

[Drxenos]

Nicely done, Mudguard. This does indeed work, but raises another issue:

If *.* is one of the expressions in the In Files, all others are ignored (including *.).

It's as if a *.* search is dealt with as a different case to other searches, as though it is assumed that *.* matches everything, so no other filters are needed. Can anyone confirm this?

Thanks.

You have to remember that * and . mean different things in Windows and Unix file globbing. In Unix, * means to match anything, but a leading dot (which is used to signify invisible files). Other than that, a dot in a unix box means nothing special.

For Windows, it really depends on the version. *.* has always meant every file, and *. has always meant files without an extension. Newer versions of Windows also understand * as meaning every file. dot on Windows is convoluted. For short (8+3) names, dot is special. Every short name "contains" a dot, regardless if it has an extension or not. For long names, Windows is more like Unix (except for the whole "leading dot is a hidden file"). Long names may contain zero or more dots, and the last one signifies the file type (like the extension is 8+3 names, but may be longer than 3). So, the short of it is that what a * matches in Windows for globbing is not as clear cut as it is in Unix.

Whew.

[Drxenos]

deleted. Above corrected.

[AndrewKember]

I hear what you're saying, Drxenos, but regardless of which files *.* catches in the In Files box, it shouldn't affect other expressions in the box, I don't think. Here's an example (single quotes are not actually typed in):

Searching for 'foo' in files '*.*'
Files found: 'dir\somefile.c, dir\anotherfile.h'

Searching for 'foo' in files 'Makefile'
Files found: 'dir1\Makefile, dir2a\Makefile'

Searching for 'foo' in files '*.* Makefile'
Files found: 'dir\somefile.c, dir\anotherfile.h'
There is no sign of the 'Makefile' files here, despite the term in the search box.

[Drxenos]

I hear what you're saying, Drxenos, but regardless of which files *.* catches in the In Files box, it shouldn't affect other expressions in the box, I don't think. Here's an example (single quotes are not actually typed in):

Searching for 'foo' in files '*.*'
Files found: 'dir\somefile.c, dir\anotherfile.h'

Searching for 'foo' in files 'Makefile'
Files found: 'dir1\Makefile, dir2a\Makefile'

Searching for 'foo' in files '*.* Makefile'
Files found: 'dir\somefile.c, dir\anotherfile.h'
There is no sign of the 'Makefile' files here, despite the term in the search box.

I see what you are saying now. I just ran your "searches" in the file open dialog box. You're correct, TextPad's file globbing doesn't work like Window's Shell.

[AndrewKember]

Thanks for the confirmation - it's good to know I'm not going crazy (or using a quirky install).

Cheers!