recursive search for files using /... -x doesn't work on Windows

[muellerto]

Describe the bug
When I start a recursive file search using /... -x I never find something.

To Reproduce
File search in the current directory works fine:

12 boost_system-vc141-mt-x64-1_66.dll     40 Office2007Aqua.dll
13 boost_thread-vc141-mt-x64-1_66.dll     41 Office2007Black.dll
14 CxImageMfcDll.dll                      42 Office2007Blue.dll
15 IIPCommon.dll                          43 Office2007Silver.dll
16 IIPComponentsModule.dll                44 Office2010.dll
17 IIPDataManager.dll                     45 OpcUaClientModule.dll
18 IIPDesigner.exe                        46 SciLexer.dll
19 IIPHost.dll                            47 Scintilla.dll
20 IIPLicenseModule.dll                   48 ssleay32.dll
21 IIPLoggerModule.dll                    49 TcpPersistenceModule.dll
22 IIPReleaseNotes.txt                    50 ToolkitPro1501.dll
23 IIPSecurityModule.dll                  51 uastack.dll
24 IIPSelectorModule.dll                  52 UserDoc.chm
25 IIPSystemModule.dll                    53 VCCommon.dll
26 IIPWebGuiModule.dll                    54 Windows7.dll
27 IIPWinService.exe                      55 xerces-c.dll
28 Infra3DataTypesModule.dll
------------------------------------------------------------------------------------------------------
[1] 09:53 tm:DES-TM-003 /d/work/Binaries/Als21/OpcuaConnector/17.16.0/x64/Bin
<0> $ /*.dll
 4 Als21OpcuaConnectorModule.dll           5 Als21ValidatorModule.dll
 6 BinaryPersistenceModule.dll            14 CxImageMfcDll.dll
15 IIPCommon.dll                          16 IIPComponentsModule.dll
17 IIPDataManager.dll                     19 IIPHost.dll
20 IIPLicenseModule.dll                   21 IIPLoggerModule.dll
23 IIPSecurityModule.dll                  24 IIPSelectorModule.dll
25 IIPSystemModule.dll                    26 IIPWebGuiModule.dll
28 Infra3DataTypesModule.dll              29 Infra3I3NetServerModule.dll
30 Infra3I3NetWebServiceV10.dll           31 Infra3I3NetWebServiceV20.dll
39 Office2007.dll                         40 Office2007Aqua.dll
41 Office2007Black.dll                    42 Office2007Blue.dll
43 Office2007Silver.dll                   44 Office2010.dll
45 OpcUaClientModule.dll                  46 SciLexer.dll
47 Scintilla.dll                          49 TcpPersistenceModule.dll
50 ToolkitPro1501.dll                     53 VCCommon.dll
54 Windows7.dll                            7 boost_atomic-vc141-mt-x64-1_66.dll
 8 boost_chrono-vc141-mt-x64-1_66.dll      9 boost_date_time-vc141-mt-x64-1_66.dll
10 boost_filesystem-vc141-mt-x64-1_66.dll 11 boost_regex-vc141-mt-x64-1_66.dll
12 boost_system-vc141-mt-x64-1_66.dll     13 boost_thread-vc141-mt-x64-1_66.dll
32 libcrypto-1_1-x64.dll                  33 libeay32.dll
34 libiconv.dll                           35 libssl-1_1-x64.dll
36 libxl.dll                              37 libxml2.dll
38 mfc140u.dll                            48 ssleay32.dll
51 uastack.dll                            55 xerces-c.dll
-> Matches found: 48
[1] 09:53 tm:DES-TM-003 /d/work/Binaries/Als21/OpcuaConnector/17.16.0/x64/Bin
<0> $

When I now add a -x to the same command it does nothing anymore:

 1 VCCommon/1                             29 Infra3I3NetServerModule.dll
 2 WebControls/2                          30 Infra3I3NetWebServiceV10.dll
 3 WebRoot/7                              31 Infra3I3NetWebServiceV20.dll
 4 Als21OpcuaConnectorModule.dll          32 libcrypto-1_1-x64.dll
 5 Als21ValidatorModule.dll               33 libeay32.dll
 6 BinaryPersistenceModule.dll            34 libiconv.dll
 7 boost_atomic-vc141-mt-x64-1_66.dll     35 libssl-1_1-x64.dll
 8 boost_chrono-vc141-mt-x64-1_66.dll     36 libxl.dll
 9 boost_date_time-vc141-mt-x64-1_66.dll  37 libxml2.dll
10 boost_filesystem-vc141-mt-x64-1_66.dll 38 mfc140u.dll
11 boost_regex-vc141-mt-x64-1_66.dll      39 Office2007.dll
12 boost_system-vc141-mt-x64-1_66.dll     40 Office2007Aqua.dll
13 boost_thread-vc141-mt-x64-1_66.dll     41 Office2007Black.dll
14 CxImageMfcDll.dll                      42 Office2007Blue.dll
15 IIPCommon.dll                          43 Office2007Silver.dll
16 IIPComponentsModule.dll                44 Office2010.dll
17 IIPDataManager.dll                     45 OpcUaClientModule.dll
18 IIPDesigner.exe                        46 SciLexer.dll
19 IIPHost.dll                            47 Scintilla.dll
20 IIPLicenseModule.dll                   48 ssleay32.dll
21 IIPLoggerModule.dll                    49 TcpPersistenceModule.dll
22 IIPReleaseNotes.txt                    50 ToolkitPro1501.dll
23 IIPSecurityModule.dll                  51 uastack.dll
24 IIPSelectorModule.dll                  52 UserDoc.chm
25 IIPSystemModule.dll                    53 VCCommon.dll
26 IIPWebGuiModule.dll                    54 Windows7.dll
27 IIPWinService.exe                      55 xerces-c.dll
28 Infra3DataTypesModule.dll
------------------------------------------------------------------------------------------------------
[1] 09:55 tm:DES-TM-003 /d/work/Binaries/Als21/OpcuaConnector/17.16.0/x64/Bin
<0> $ /*.dll -x
[1] 09:55 tm:DES-TM-003 /d/work/Binaries/Als21/OpcuaConnector/17.16.0/x64/Bin
<0> $

It seems that it doesn't even start any search. I can do what I want, I never get a result this way.

Expected behavior
In my example I would expect that it shows the same files as above plus some more files from the sub directories.

Desktop

• OS: Windows 11 Pro
• Terminal: mintty
• CliFM version: 1.15.2
• Installation source: Git from yesterday

The application has been compiled on MinGW using gcc 13.2.0.

Additional context
This is specific for Windows. On my Linux machine it works as expected.

SearchStrategy is 0 in my case, but it doesn't depend on that.

[leo-arch]

Hi @muellerto. Recursive search (-x) is done via find(1), so I'm pretty sure there's some issue with your find version.

To make sure, I added some debugging messages to the function. To enable them, edit misc/cygwin/Makefile and add -DDEBUG_SEARCH to CFLAGS. It should look like this:

CFLAGS += -Wall -Wextra -DCLIFM_DATADIR=$(DATADIR) -DDEBUG_SEARCH

Compile as always and the run the search function with the -x parameter. You should see:

a. The actual command executed (Exec cmd: 'CMD')
b. Whatever message find prints to STDERR.

Please report the results.

[muellerto]

Ah!

Windows has it's own damned find (find.exe), a primitive thing, not earnestly usable for anything, and it's rather a grep than a find. But it comes very early in the path. When I type "find" I get always this one.

Of course I have a nice Unix find working great. But I had to symlink it to fnd.exe to be able to execute it manually. But clifm doesn't know that ...

Will see what I can do.

[leo-arch]

I see. I guess it depends on the installation: in my Windows box it works as expected.

Please let me know what you find.

[muellerto]

It depends on the executable's path. And this is tricky. Windows has two paths:

• a system path for all users
• an individual user path for the current user only

The user path is automatically appended to the system path, and that is what the user gets after logon. You can't change this.

If now a user wants to have a special private implementation of a command which is already in the system path it gets really difficult. And in my case already the very first directory in the system path contains this Windows find, so I can't put my Unix find symlink in any earlier directory in the path, there is no earlier directory. So I added now indeed a new directory at the beginning of the system path which contains only a symlink to my Unix find.exe named also find.exe, nothing else. This solves the problem immediately. But

• it makes all users depend from my private directory, the contained executables and their execution privileges. And having this directory anywhere on a global place wouldn't make it better because the symlink in it points still onto a private user file. OK, I could copy my Unix find.exe into this global directory and set proper privileges for all users, this would be clean and sober ...
• it makes the execution of the original Windows find more complicated. (OK, there will never be anybody who needs it really ...)

Probably you installed MinGW for all users, then it's bin directories get into the system path and you can put them at the beginning. - I have it private, only for me as user, the other users don't see it, that's why I have it in the user path.

Thinking ...

Ha, I have still another opportunity: I start clifm not directly as clifm.exe but using a batch file clifm.bat to give clifm.exe always the --no-bold parameter. It would be easy for me to manipulate the path variable in this batch file before I start clifm. This would make the path manipulation private for this process and I wouldn't need to set the system path or the user path. And all the disadvantages above would be avoided. I think this is the solution.

[leo-arch]

Oh Windows, you did it again! But, seriously, could you share your batch file (with the modified PATH) in case other users need it?

Btw, I'll revert the changes made in the last commit.

[muellerto]

Assume I have a directory with the name c:\usr\replacements. This directory is intended to contain replacements of Windows system commands. I have there a symlink to the Unix find of MinGW, the link is named find.exe. The MinGW installation is somewhere on my disk, doesn't matter.

Then my batch file looks as follows:

@echo off
set PATH=c:\usr\replacements;%PATH%
clifm.exe --no-bold %1 %2 %3 %4 %5 %6 %7 %8 %9

• the first line switches off any runtime echoing from this batch file
• To understand the second line we must keep in mind that a process can change variables in it's own environment just by assigning a new value. So we concat our replacements directory and the current value of the PATH environment variable we got from outside and assign the result back to our own local PATH variable. This variable is valid for this batch file and inherits it's value also to the environments of all processes started by this batch file and their child processes, this is important. That's why clifm is able to find now our symlink for sure in the replacements directory before all other finds anywhere in the path.
• the third line starts clifm with --no-bold and maximum nine additional parameters specified from outside to the batch file

Two ideas:

1. Would be good to have a section somewhere in the PDF file where the external applications used by clifm are listed completely, perhaps also with the commands which start them. Perhaps I need still some more symlinks in my replacements directory.
2. Windows (or also other OS) specific section(s) containing some tips (building, installation, configuration, limitations)

[leo-arch]

Thanks @muellerto!

Regarding your two ideas, I will definitely consider them. Please feel free to contribute yourself to the Wiki.

EDIT: Some of your suggestions are (at least partially) addressed here:
a. Build/install instructions
b. A troubleshooting section mainly aimed at this kind of issues.

[leo-arch]

Tentative list of runtime dependencies.

[muellerto]

Looks good. And doesn't contain further collisions with Windows programs, good so.

sh is still missing.

[leo-arch]

sh is still missing

True. Added.