help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working rgrep in windows emacs in 2024? (GNU emacs 29.1, windows 11


From: Steinar Bang
Subject: Re: Working rgrep in windows emacs in 2024? (GNU emacs 29.1, windows 11 Enterprise)
Date: Wed, 14 Feb 2024 09:26:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

>>>>> Eli Zaretskii <eliz@gnu.org>:

>> I've messed with setting the PATH environment variable (from my .emacs)
>> (if windows-emacs
>> (setenv "PATH" (concat 
>> "c:\\ProgramFiles\\ezwinports\\bin;C:\\ProgramFiles\\GnuWin32\\bin;" (getenv 
>> "PATH"))))
>> and I've tried adding to the exec-path
>> (when windows-emacs
>> (push "C:/ProgramFiles/GnuWin32/bin" exec-path)
>> (push "c:/ProgramFiles/ezwinports/bin" exec-path))

> I don't do that because the directory with ports of GNU software,
> including 'find' and 'grep', is on my system-wide PATH.

I tried that now, by removing the above from .emacs, editing PATH for my
user to put C:\ProgramFiles\ezwinports first.  But that still failed
    -*- mode: grep; default-directory: "~/projects/altinn3/app-localtest/" -*-
    Grep started at Wed Feb 14 08:47:34
    
    find -H . -type d "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS" -o 
-path "*/MCVS" -o -path "*/.src" -o -path "*/.svn" -o -path "*/.git" -o -path 
"*/.hg" -o -path "*/.bzr" -o -path "*/_MTN" -o -path "*/_darcs" -o -path 
"*/{arch}" -o -path "*/node_modules" -o -path "*/target" ")" -prune -o ^"^!^" 
-type d "(" -name ".#*" -o -name "*.o" -o -name "*~" -o -name "*.bin" -o -name 
"*.bak" -o -name "*.obj" -o -name "*.map" -o -name "*.ico" -o -name "*.pif" -o 
-name "*.lnk" -o -name "*.a" -o -name "*.ln" -o -name "*.blg" -o -name "*.bbl" 
-o -name "*.dll" -o -name "*.drv" -o -name "*.vxd" -o -name "*.386" -o -name 
"*.elc" -o -name "*.lof" -o -name "*.glo" -o -name "*.idx" -o -name "*.lot" -o 
-name "*.fmt" -o -name "*.tfm" -o -name "*.class" -o -name "*.fas" -o -name 
"*.lib" -o -name "*.mem" -o -name "*.x86f" -o -name "*.sparcf" -o -name 
"*.dfsl" -o -name "*.pfsl" -o -name "*.d64fsl" -o -name "*.p64fsl" -o -name 
"*.lx64fsl" -o -name "*.lx32fsl" -o -name "*.dx64fsl" -o -name "*.dx32fsl" -o 
-name "*.fx64fsl" -o -name "*.fx32fsl" -o -name "*.sx64fsl" -o -name 
"*.sx32fsl" -o -name "*.wx64fsl" -o -name "*.wx32fsl" -o -name "*.fasl" -o 
-name "*.ufsl" -o -name "*.fsl" -o -name "*.dxl" -o -name "*.lo" -o -name 
"*.la" -o -name "*.gmo" -o -name "*.mo" -o -name "*.toc" -o -name "*.aux" -o 
-name "*.cp" -o -name "*.fn" -o -name "*.ky" -o -name "*.pg" -o -name "*.tp" -o 
-name "*.vr" -o -name "*.cps" -o -name "*.fns" -o -name "*.kys" -o -name 
"*.pgs" -o -name "*.tps" -o -name "*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" 
-prune -o  -type f "(" -iname "*.yml" ")" -exec grep --color=always -n --null 
-e "LocalAppMode" "{}" NUL ";"
    FIND: Parameter format not correct

    Grep exited abnormally with code 2 at Wed Feb 14 08:47:34

Looking at the output from getenv it looks like the system setting for
PATH comes before mine:
    C:\Program Files\PuTTY;C:\Program Files\Common 
Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program
 Files (x86)\Pulse Secure\VC142.CRT\X64\;C:\Program Files (x86)\Pulse 
Secure\VC142.CRT\X86\;C:\Program Files (x86)\Common Files\Pulse Secure\TNC 
Client Plugin\;C:\Program 
Files\WindowsPowerShell\Scripts\HP.ClientScriptLibrary;C:\Program 
Files\Git\cmd;C:\Program Files\PuTTY\;C:\Program Files\Calibre2\;C:\Program 
Files\dotnet\;C:\Program Files\Rancher 
Desktop\resources\resources\win32\bin\;C:\Program Files\Rancher 
Desktop\resources\resources\linux\bin\;C:\ProgramFiles\ezwinports;C:\Users\sb\AppData\Local\Microsoft\WindowsApps;C:\Users\sb\apps\apache-maven-3.9.6\bin;C:\Users\sb\apps\bin;C:\Users\sb\.dotnet\tools;C:\Users\sb\AppData\Local\Programs\Microsoft
 VS Code\bin;

It could be that tried putting the settings in the emacs config to avoid
messing with the system PATH setting...?  Or that I was lacking
privileges to change that?

Both config settings (i.e. both setenv on the PATH, and push on
exec-path) are from 2015, and the last one (push on exec-path) has
a commit message starting with "Attempt at", so I've never had success
here, I think.

> Does Emacs find find.exe and grep.exe if you try it with
> executable-find, like this:

>   M-: (executable-find "find") RET

On emacs with .emacs config removed, and C:\ProgramFiles\ezwinports
added to PATH:  "c:/Windows/system32/find.exe"
(so that's why it didn't work)

On emacs without the PATH setting and the .emacs config in place:
"c:/Windows/system32/find.exe"

So the .emacs config doesn't work and probably never have.

>   M-: (executable-find "grep") RET

On emacs with .emacs config removed, and C:\ProgramFiles\ezwinports
added to PATH:  "c:/Windows/system32/find.exe"

So that was promising.

On emacs without the PATH setting and the .emacs config in place:
nil

So, yeah, that has never worked.

>> But neither of the above settings have ever given me a working rgrep.

> Which means what?  What do you see if you try invoking rgrep?  Please
> show everything you type at rgrep's prompts and the output and/or
> error messages you get as result.

Sorry about that! Forgot!

Included above.

But I guess that means that if I can put C:\ProgramFiles\ezwinports
first in the SYSTEM PATH then rgrep in emacs should work?

I'll try (somewhat locked down corporate machine, so it can sometimes be
hard to find out what I am allowed and not allowed to do...).

>> Ezwinports is Emacs maintainer Eli Zaretskii's old port of linux/unix
>> command line tools to windows:
>> https://www.gnu.org/software/emacs/manual/html_node/efaq-w32/EZWinPorts.html
>> 
>> Do these still work for 64bit windows?

> Yes.  I use them every day on 64-bit Windows 11.

Just a side note: the find was both a win64 and a win32 version, and I
picked the win64 version.  But the grep was just a win32 version.

Does that matter/have any unforseen consequences?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]