1

[Top-posting an update] Results of deeper inquiry, after filing a bug report. It appears that the failure is related to a recent update to the cygwin environment. Where previously the single-quoted parameter '*.log' to the -name option to find was passed to find as a single-quoted '*.log', the current behaviour has that '*.log' expanded to a list of files if there are .log files in the directory in which the find-grep is started.

Changing the invocation to

find . -type f -name \\*.log -exec grep -nHE 'ERROR:' {} \;

causes the literal *.log to be passed to find as desired. More research will be needed to find exactly where the name expansion is happening, but for now this works.

**** end of top-posted update ***

GNU Emacs 24.5.1 (i686-pc-mingw) with a cygwin environment installed at C:/cygwin64 on a Windows 7 machine.

M-x find-grep (aka grep-find), then:

find . -type f -name '*-2017-12-12_09.22.57.log' -exec grep -nHE 'ERROR:' {} \;

finds a number of ERROR: lines in various .log files at various depths in the directory hierarchy where I am working.

One particular file with an 'ERROR:'

./PFF/PFF/PFF.bat-2017-12-12_09.22.57.log

is not found unless I change down a directory level, starting in ./PFF, or unless the parent directory name is [at least] one character longer or shorter (but see below.) e.g. the ERROR: line is found in

./PFF/PFFm/PFF.bat-2017-12-12_09.22.57.log

or in

./PFF/PFF-/PFF.bat-2017-12-12_09.22.57.log

but never in

./PFF/PFF/PFF.bat-2017-12-12_09.22.57.log

whether the original ./PFF/PFF directory is renamed or copied to a [longer-named] parent (when copied, I have both ./PFF/PFF and ./PFF/PFFx directories.)

Then it gets weird - if I have a copy of the ./PFF/PFF directory named ./PFF/PF or ./PFF/P, the ERROR: lines in both copies of the .log file are found (one in each of the directories;) if the duplicate directory is named with three or more characters (e.g. ./PFF/PFM) the original ./PFF/PFF log file is not found (or grepped; not sure yet which.)

It might be worth mentioning that the ./PFF directory does have two other subdirs in addition to ./PFF/PFF (./PFF/PFF_FILE_HANDLING and ./PFF/PFF_CAPTURE_FF) so it doesn't appear that the problem is that ./PFF/PFF is all alone.

find . -type f -name '*-2017-12-12_09.22.57.log' -exec grep -nHE 'ERROR:' {} \;

at the command line works as expected.

Now, I'm leery of find-grep (one of my go-to tools.)

  • Does find-grep-dired in Dired do a better job wrt your problem? – Drew Dec 12 '17 at 17:30
  • Thanks for the suggestion. Unfortunately find-grep-dired finds ERROR: in many files that are uninteresting and takes much longer to run. (There are several thousand "uninteresting" files, each of which gets grepped.) Curiously, find-grep-dired also failed to find any hits in ./PFF/PFF – Donald Locker Dec 12 '17 at 18:02
  • that exact command executed in a bash shell does find the missing file (which is actually how I found it existed; I was gobsmacked!) – Donald Locker Dec 12 '17 at 20:21
  • 1
    "find... at the command line works as expected." -- then it sounds like an Emacs bug. M-x report-emacs-bug – phils Dec 12 '17 at 20:21
  • After 30+ years of Emacsing without problems, I'm not sure I'm comfortable filing a bug report until I've exhausted all possibilities. But you are probably right. Now, if only I could reproduce it with a smaller set of directories/files that are not proprietary. Thanks. – Donald Locker Dec 12 '17 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.