Any reason of adding `.` at the end of command on Windows?

[chansey97]

Any reason of adding `.` at the end of command on Windows?

[chansey97]

I think I know what happened here:

When the command-line arguments did not explicitly indicate the search path (e.g. . or ./), ripgrep would use a heuristic to guess users' intention, i.e. whether searching in the current directory or in stdin via a pipe, see hiargs.rs#L1104 and lib.rs#L170. Unfortunately, on Windows (might be also on Mac), ripgrep guesses "users want to search in stdin via a pipe", so Emacs process hangs.

A simple experiment to make the above process code work:

(let ((p (apply 'start-process "rg" "newbuffer123"
                "C:/env/ripgrep/ripgrep-14.1.0-x86_64-pc-windows-msvc/rg.exe"
                (list "SomeTextInFiles"))))
  (process-send-string p "1. SomeTextInFiles1\nxxxxxx\n2. SomeTextInFiles2\nyyyyy\n3. SomeTextInFiles3\n")
  (process-send-eof p))

This code work, Emacs can display the result.

1. SomeTextInFiles1
2. SomeTextInFiles2
3. SomeTextInFiles3

Process rg<1> finished

However as you see that, ripgrep searched "SomeTextInFiles" in the string content, i.e. "1. SomeTextInFiles1\nxxxxxx\n2. SomeTextInFiles2\nyyyyy\n3. SomeTextInFiles3\n" instead of directory.

---

Some suggestions:

1. Make the command-line consistent on Windows, Linux and Mac OS, i.e. explicitly provide the search path instead of leaving ripgrep to guess. Remove (member system-type '(darwin windows-nt)) condition.
2. The search path (or "multiple directories search") should be implemented as a separate feature instead of hardcoded as . or added through rg-command-line-flags.

[drvink]

Yes, @chansey97's description is what my fix was for.