'Find in Files' does not search through files with no extension if no extension is explicit in filter field

[schadjo]

'Find in Files' does not search through files with no extension if no extension is explicit in filter field

[molsonkiko]

@schadjo OK, thanks for clarifying what you meant. Yes, I see files with no extension all the time, so your use case makes a lot more sense now.

It turns out you can do this! You just need to familiarize yourself with globbing, which is discussed to some extent here. A more comprehensive guide could be found by googling glob syntax.

What you want to do is put the filter !*.?* (which excludes all files with at least one character in their extension) in the Filters box.

If you want to restrict which files without extensions you look at, you can just add those filters separately. So *2 !*.?* would search for all extensionless files with names that end with the digit 2

[alankilborn]

::FindFirstFile and ::FindNextFile functions seem to be doing what is desired when searching for e.g. *..
( In fact, for experimenting with these in an easy manner, I found THIS really cool Python program from a StackOverflow answer. )

After a little bit more looking, the problem appears to be in the use of the ::PathMatchSpec Win API function.

---

@molsonkiko said:

...I'm going to keep looking into it

If you don't mind, I'd like to try coming up with a fix for this issue.
But, if you really want to yourself, let me know and I'll cease, as you expressed interest in this issue first.

[molsonkiko]

If you don't mind, I'd like to try coming up with a fix for this issue.

@alankilborn
Go for it!

If I thought it was worthwhile, I could implement glob syntax similar to NavigateTo, which would add cool toys like squarebrace character sets and {x,y,z} unions, but I feel like Notepad++ has too much history to make a breaking change like that worthwhile.

[alankilborn]

Side note: The user manual even mentions ::PathMatchSpec!

[molsonkiko]

I'm not surprised you're having this issue: files with an empty extension shouldn't exist, and most applications won't even create them.

TLDR: if files with that name shouldn't exist, you should consider fixing whatever is creating them (or begging the creator to fix it), not asking Notepad++ to handle your corner case.

I tried making a file with an empty extension using all of the following:

1. Creating one using the GUI in the Windows 10 File Explorer
2. Saving one in Notepad++
3. Creating one with Python.

In every one of those cases, what I got instead was a file with no extension, not a file with an empty extension.

[alankilborn]

files with an empty extension shouldn't exist

I think OP means "no extension".
In other words, I don't know what an "empty extension" would be, other than no extension.

You can create an extensionless file in Explorer, from the command line, and many other ways.
In Explorer and Cmd, you can either use the . or not, e.g. echo x>test or echo x>test. ... both yield the same result, a file with the exact name test in the file system.

[schadjo]

@alankilborn Yes, you are right. My mistake.

I work with a lot of FANUC CNCs which strip any file extensions from the gcode files placed on the machine. When retrieved for editing, they have no extension.

Being able to search though a bunch of no-extension files in multiple subdirectories would be a win for me.

[alankilborn]

So I think the answer here is RTFM (Read The Fine Manual) and this issue may now be closed.

[schadjo]

I see what you're saying, but for 30+ years I've been able to do from a DOS/command prompt dir/s *. and list every file and directory with no extension. It seems counterintuitive to look for *. and not find *. when they exist.

[ioc2e3]

違反直覺

agree ...

( The file exists ) but ( cannot be found ) is really counterintuitive ...

.

[molsonkiko]

So after a bit of fooling around, I've figured out the following:

Suppose you have a file named new2 (no extension). Then:

• *.* matches
• * matches
• ** matches (when in recursive mode)
• w* does not match
• *2 matches

I tested this on Notepad++ 8.5.8, 8.6.4, and 8.5.1, and I'm pretty sure the behavior is consistent. I'd like confirmation from others though.

So in short, it appears that find in files usually works fine for files with no extension, but this is one corner case where it's broken. Of course, this is still a bug, and I'm going to keep looking into it.

[alankilborn]

I'd like confirmation from others

I confirm I get the same results as you for your list.

[alankilborn]

Is a possible solution as "simple" as:

if a user's filter spec ends with ., remove that character and let the search for matching files proceed; then examine results and if a matched filename has a . in it, drop that file from consideration for the content-search phase

EDIT: I'll revise the above into:
if a user's filter spec ends with ., remove that character and let the search for matching files proceed; then examine results and if a matched filename has no . in it, consider it a match (think: implied . at the very end of the name) and move it into the content-search phase of the overall search

[alankilborn]

Similar complaint from 2017:

https://community.notepad-plus-plus.org/topic/13196/find-in-files-search-only-files-with-no-extension/

[alankilborn]

In addition to extensionless files that should be matched with *., directory exclusion of this nature !\*. and !+\*. should exclude extensionless directories (currently it does NOT exclude them).

[alankilborn]

Just a note :

In CMD, because it was compared to existing Notepad++ filter capability earlier #14617 (comment) :

• a dir *. will match files to do contain a . (at the start) such as .gitignore, .editorconfig, etc., as well as other files/dirs that don't contain . (i.e., extensionless files)
• dir .* will match only files that start with a .
• it doesn't seem possible for dir to return only files that have no . whatsoever (but maybe some better CMD guru than me knows how to make it do this??)

A possible future version of Notepad++ could match files that have no . whatsoever, via this filterspec: *. !.*

[alankilborn]

So I came up with some new code for N++ that will allow *. to work.
However, it is somewhat of a performance killer regarding time it takes to search.

Click to view search scenario and timing results details

Searched N++ 8.6.4 source code tree
Find what: \z
Search mode: Regular expression
Filters: *

Roughly 2050 files are hit.

Timing with N++ 8.6.4: ~5s
Timing with new code that supports *. : ~12s

I will continue to look at possibilities to both support *. and retain similar performance to existing N++ code.
I think it might be possible with a lot of restructuring of how locating the fileset to search is done (which is probably a deal-breaker for such code being accepted into N++ -- too much risk).