Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to not read from pipe #2582

Closed
AndersMunch opened this issue Aug 15, 2023 · 3 comments
Closed

Add option to not read from pipe #2582

AndersMunch opened this issue Aug 15, 2023 · 3 comments

Comments

@AndersMunch
Copy link

Describe your feature request

I would like an option to tell ripgrep, that despite being connected to a pipe, it should not search standard input, so that it will do a normal recursive search.

Don't know about the name. --no-pipe, perhaps?

Motivation

ripgrep does not work from within Emacs when used as the grep-command on Windows. It exits immediately with error code 1, or hangs.
I suspect this is related to issue #951, something to do with stdin being a "fifo"? I'm not sure what that's supposed to mean, from what I can see Emacs is just running a bog standard inferior process - and indeed trying to run ripgrep as a Python subprocess exhibits the same problem, this hangs:

import subprocess
subprocess.check_output(['rg','SomeSearchTerm'])

But never mind the reason, I would just like an option to fix it.

@BurntSushi
Copy link
Owner

Why doesn't rg foo ./ work?

@AndersMunch
Copy link
Author

Good point. rg foo . does work. I just never used the second argument, so I didn't think of it.

@BurntSushi
Copy link
Owner

The key insight is that by omitting the path argument you are basically saying, "ripgrep, please guess whether to search the current working directory or stdin." Due to idiosyncracies in how processes are created in various contexts, it is impossible for ripgrep to guess correctly 100% of the time.

Repository owner locked and limited conversation to collaborators Aug 16, 2023
@BurntSushi BurntSushi converted this issue into discussion #2585 Aug 16, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants