You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran rg.exe aa -l > list.txt in bash.exe, but the command never completed.
It stopped at this line rdr.read(...)
The type of rdr was encoding_rs_io::DecodeReaderBytes<&mut &mut std::io::stdio::StdinLock, &mut alloc::vec::Vec<u8>>.
It seems that is_readable_stdin is also true because the redirect on bash.exe was determined to be is_pipe.
The implementation of is_pipe is simple, but I don't know why it is so.
I've looked into it, but I can't identify whether the problem is with winapi-util, Rust std, WSL2, or some other cause. Apologies, but I need ripgrep, so I'm submitting this issue here.
Note: rg.exe aa . -l > f, this works fine.
What are the steps to reproduce the behavior?
rg.exe aaa -l > f on bash.exe
What is the actual behavior?
rg aaaaa --debug -l > a
rg: DEBUG|rg::flags::parse|crates/core\flags\parse.rs:97: no extra arguments found from configuration file
rg: DEBUG|rg::flags::hiargs|crates/core\flags\hiargs.rs:1099: using heuristics to determine whether to read from stdin or search ./ (is_readable_stdin=true, stdin_consumed=false, mode=Search(FilesWithMatches))
rg: DEBUG|rg::flags::hiargs|crates/core\flags\hiargs.rs:1112: heuristic chose to search stdin
rg: DEBUG|rg::flags::hiargs|crates/core\flags\hiargs.rs:1260: found hostname for hyperlink configuration: PC030
rg: DEBUG|rg::flags::hiargs|crates/core\flags\hiargs.rs:1270: hyperlink format: ""
rg: DEBUG|rg::flags::hiargs|crates/core\flags\hiargs.rs:174: using 1 thread(s)
rg: DEBUG|grep_regex::config|crates\regex\src\config.rs:175: assembling HIR from 1 fixed string literals
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: gzip: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: gzip: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: bzip2: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: bzip2: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: xz: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: xz: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: lz4: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: xz: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: brotli: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: zstd: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: zstd: could not find executable in PATH
rg: DEBUG|grep_cli::decompress|crates\cli\src\decompress.rs:502: uncompress: could not find executable in PATH
rg.exe stops here.
What is the expected behavior?
rg.exe should scan under the current directory rather than waiting for stdin input, even without a path specification.
The text was updated successfully, but these errors were encountered:
ripgrep fundamentally has to rely on a heuristic to determine whether to search stdin or to search the current working directory. Something about your environment is advertising a readable stdin. That is what needs to be fixed. The only alternative available to you is to disable ripgrep's heuristic by always providing a path to search.
Are you using a Windows build of ripgrep from WSL2? You should be using a Linux build, which will integrate much better with the rest of the environment.
Please tick this box to confirm you have reviewed the above.
What version of ripgrep are you using?
ripgrep 14.1.0 (rev c9ebcbd)
How did you install ripgrep?
winget, and cargo.exe
What operating system are you using ripgrep on?
WSL2 Ubuntu 22.04.4 LTS
Describe your bug.
The reason for using
rg.exe
on bash.exe: microsoft/WSL#4197I ran
rg.exe aa -l > list.txt
in bash.exe, but the command never completed.It stopped at this line
rdr.read(...)
The type of
rdr
wasencoding_rs_io::DecodeReaderBytes<&mut &mut std::io::stdio::StdinLock, &mut alloc::vec::Vec<u8>>
.ripgrep/crates/searcher/src/line_buffer.rs
Line 418 in c9ebcbd
The search target was mistakenly determined to be Stdin because
grep::cli::is_readable_stdin
returnedtrue
. process is as follows.std::io::stdin().is_terminal()
is_disk
(Windows)is_pipe
(Windows)I wrote the following program and ran it with bash.exe and cmd.exe.
Result:
bash.exe
cmd.exe
It seems that
is_readable_stdin
is also true because the redirect on bash.exe was determined to beis_pipe
.The implementation of
is_pipe
is simple, but I don't know why it is so.The Rust
is_terminal
implementation is thishttps://github.com/rust-lang/rust/blob/737e42308c6e957575692965d73b17937f936f28/library/std/src/sys/pal/windows/io.rs#L83
I've looked into it, but I can't identify whether the problem is with winapi-util, Rust std, WSL2, or some other cause. Apologies, but I need ripgrep, so I'm submitting this issue here.
Note:
rg.exe aa . -l > f
, this works fine.What are the steps to reproduce the behavior?
rg.exe aaa -l > f
on bash.exeWhat is the actual behavior?
rg aaaaa --debug -l > a
rg.exe stops here.
What is the expected behavior?
rg.exe should scan under the current directory rather than waiting for stdin input, even without a path specification.
The text was updated successfully, but these errors were encountered: