0. emacs -Q 1. In the following find-dired invocation adjust `' to the emacs lisp source directory and then evaluate the sexp: (find-dired "" "-name \"*.el\" -exec grep 'const' {} \";\"") => error in process filter: Invalid use of ‘\’ in replacement text This also happens with Emacs 27 but not with Emacs 26. TL;DR: see the attached patch, justification of which follows. AFAICT this error (which is signalled repeatedly with the above invocation) happens when the find-dired output includes a line containing escaped characters that also matches the regexp for the first five columns of the standard Dired display of directory entries used by find-dired-filter. This function calls replace-match to add spaces to the output, and if the matches contain escaped characters, replace-match raises an error. While escaped characters don't occur in the first five columns of the standard Dired display, they could well occur in non-directory output such as that produced by the above find-dired invocation. It seems that find-dired-filter does not expect such output. (Indeed, by default find-dired does not handle such output well, cf. https://stat.ethz.ch/pipermail/ess-help/2021-January/012868.html, which points out issues with the above find-dired invocation; this prompted me to submit this bug report.) This problem was exposed, or at least made much easier to encounter, by this change: commit fb20043b2fec8e8aff6354ec1396fd5ba688b76b Author: Sebastian Reuße AuthorDate: Sat Dec 30 12:41:23 2017 +0200 Commit: Eli Zaretskii CommitDate: Sat Dec 30 12:41:23 2017 +0200 Fix output alignment in 'find-dired' for "ls -h" * lisp/find-dired.el (find-dired-filter): Fix alignment of the file size column when the -h ls option is used in 'find-ls-option'. (Bug#29803) index 3b0613b280..bf815d500d 100644 --- a/lisp/find-dired.el +++ b/lisp/find-dired.el @@ -295,7 +295,7 @@ find-dired-filter (l-opt (and (consp find-ls-option) (string-match "l" (cdr find-ls-option)))) (ls-regexp (concat "^ +[^ \t\r\n]+\\( +[^ \t\r\n]+\\) +" - "[^ \t\r\n]+ +[^ \t\r\n]+\\( +[0-9]+\\)"))) + "[^ \t\r\n]+ +[^ \t\r\n]+\\( +[^[:space:]]+\\)"))) (goto-char beg) (insert string) (goto-char beg) When I revert this change, I don't get the error with the above find-dired invocation anymore. But since the change fixed a bug, it can't just be reverted. One alternative is to replace `[^[:space:]]' by something less permissive. In fact, in the bug thread the author of the patch first proposed the more restrictive `[0-9.,]+[kMGT]?' to match the file size column, and indeed, with this the above error does not occur. But he noted that file size could be displayed in various ways, e.g. with the `ls' option `--si', and thus chose the most permissive regexp. But since that can result in the above error, a better alternative would be a compromise between too permissive and possibly too restrictive, e.g.: `[0-9.,]+[[:alpha:]]?'. With this the above error also does not occur and there is also no misalignment, as can be verified by evaluating the following (suitably adjusted) sexp after making this compromise change in find-dired-filter: (let ((find-ls-option '("-exec ls -ldh {} +" . "-ldh"))) (find-dired "" "-type f")) The Dired fields are aligned just as with the permissive regexp and in contrast to the output when using `[0-9]'. But in fact, it appears possible to return to the simple `[0-9]', i.e. reverting the above commit. It turns out that there are cases of misaligned directory lines with find-dired even with the current permissive regexp added by that commit (but also with the above compromise, and of course also with the simple `[0-9]'). Evaluating the following code illustrates this with the output attached below it: (let ((find-ls-option '("-exec ls -ldh {} +" . "-ldh"))) (find-dired "/tmp" "-type f"))