Closed muellerto closed 7 months ago
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.
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.
I see. I guess it depends on the installation: in my Windows box it works as expected.
Please let me know what you find.
It depends on the executable's path. And this is tricky. Windows has two paths:
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
find.exe
into this global directory and set proper privileges for all users, this would be clean and sober ...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.
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.
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
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.--no-bold
and maximum nine additional parameters specified from outside to the batch fileTwo ideas:
replacements
directory.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.
Tentative list of runtime dependencies.
Looks good. And doesn't contain further collisions with Windows programs, good so.
sh
is still missing.
sh
is still missing
True. Added.
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:
When I now add a
-x
to the same command it does nothing anymore: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
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.