rg prints text "<stdin>" when input is given via stdin #1223

arunvelsriram · 2019-03-18T13:48:22Z

What version of ripgrep are you using?

$ rg --version
ripgrep 0.10.0
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

How did you install ripgrep?

brew install rg

What operating system are you using ripgrep on?

OS X High Sierra

Describe your question, feature request, or bug.

When I do rg over content passed through stdin, the output contains the text "<stdin>" along with the matches. It started to happen recently after I updated some of my bash configs and those are not related to rg. Does anyone know why this is happening?

$ ls | rg test
<stdin>
test.json
test.txt
test.yaml

The text was updated successfully, but these errors were encountered:

BurntSushi · 2019-03-18T13:51:03Z

Please follow the issue template and include the --debug output. Please also include --trace output.

arunvelsriram · 2019-03-18T14:01:38Z

Sorry missed that.

$ ls | rg --debug test
DEBUG|grep_regex::literal|grep-regex/src/literal.rs:58: literal prefixes detected: Literals { lits: [Complete(test)], limit_size: 250, limit_class: 10 }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 0 literals, 0 basenames, 8 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
<stdin>
test.json
test.txt
test.yaml

$ ls | rg --trace test
DEBUG|grep_regex::literal|grep-regex/src/literal.rs:58: literal prefixes detected: Literals { lits: [Complete(test)], limit_size: 250, limit_class: 10 }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 0 literals, 0 basenames, 8 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
TRACE|grep_searcher::searcher|grep-searcher/src/searcher/mod.rs:685: generic reader: searching via roll buffer strategy
TRACE|grep_searcher::searcher::core|grep-searcher/src/searcher/core.rs:61: searcher core: will use fast line searcher
<stdin>
test.json
test.txt
test.yaml

BurntSushi · 2019-03-18T14:28:27Z

My guess is that this is a user error somewhere. I cannot reproduce it. I was hoping the debug output would show the argv, but it looks like that isn't quite working as I'd like. Do you have an rg alias somewhere? Run alias rg or command -V rg to see. For example, this is how things could be messed up:

$ alias rg="rg --with-filename"
$ ls | rg test
<stdin>
test.py

More concretely, try

$ ls | \rg test
test.py

to force that you aren't using an alias.

arunvelsriram · 2019-03-18T17:04:30Z

It's not aliased as far as I checked.

$ alias rg
-bash: alias: rg: not found

$ command -V rg
rg is /usr/local/bin/rg

ls | \rg test
<stdin>
test.json
test.txt
test.yaml

BurntSushi · 2019-03-18T17:09:08Z

Then I don't know. You'll likely need to debug this yourself since I cannot reproduce it and I can't quite figure out how this could be happening. The first step here would be to just compile master and see if the bug has been fixed already. If not, you'll want to debug this code:

ripgrep/src/args.rs

Lines 1471 to 1482 in 0913972

    
               /// Returns true if and only if file names containing each match should 
        
               /// be emitted. 
        
               fn with_filename(&self, paths: &[PathBuf]) -> bool { 
        
                   if self.is_present("no-filename") { 
        
                       false 
        
                   } else { 
        
                       self.is_present("with-filename") 
        
                       || self.is_present("vimgrep") 
        
                       || paths.len() > 1 
        
                       || paths.get(0).map_or(false, |p| p.is_dir()) 
        
                   } 
        
               }

Namely, it seems like that's returning true for you, but I don't know why.

arunvelsriram · 2019-03-18T19:12:23Z

Thanks for the input.

I noticed one more thing. Its happening only in my home directory. It feels like a user error to me as well. I will debug this further and update here.

BurntSushi · 2019-04-08T12:29:50Z

I'm going to close this out since I can't reproduce it. Please feel free to comment again if you have more details!

iiey · 2019-05-28T13:04:18Z

please reopen this issue as a bug because I have the same problem:

16.04.1-Ubuntu

ripgrep 0.10.0 (rev 8a7db1a918)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

$ ls | rg --trace a
DEBUG|grep_regex::literal|grep-regex/src/literal.rs:58: literal prefixes detected: Literals { lits: [Complete(A), Complete(a)], limit_size: 250, limit_class: 10 }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 0 literals, 0 basenames, 8 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
DEBUG|globset|globset/src/lib.rs:424: glob converted to regex: Glob { glob: "**/build*", re: "(?-u)^(?:/?|.*/)build.*$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('b'), Literal('u'), Literal('i'), Literal('l'), Literal('d'), ZeroOrMore]) }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 1 literals, 3 basenames, 6 extensions, 0 prefixes, 1 suffixes, 0 required extensions, 1 regexes
TRACE|grep_searcher::searcher|grep-searcher/src/searcher/mod.rs:685: generic reader: searching via roll buffer strategy
TRACE|grep_searcher::searcher::core|grep-searcher/src/searcher/core.rs:61: searcher core: will use fast line searcher
<stdin>:a

$ ls | rg --debug a
DEBUG|grep_regex::literal|grep-regex/src/literal.rs:58: literal prefixes detected: Literals { lits: [Complete(A), Complete(a)], limit_size: 250, limit_class: 10 }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 0 literals, 0 basenames, 8 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
DEBUG|globset|globset/src/lib.rs:424: glob converted to regex: Glob { glob: "**/build*", re: "(?-u)^(?:/?|.*/)build.*$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('b'), Literal('u'), Literal('i'), Literal('l'), Literal('d'), ZeroOrMore]) }
DEBUG|globset|globset/src/lib.rs:429: built glob set; 1 literals, 3 basenames, 6 extensions, 0 prefixes, 1 suffixes, 0 required extensions, 1 regexes
<stdin>:a

Step to reproduce it :

Create a folder with some subdirs:

mkdir a b c
ls | rg a
a

Create a folder with minus symbol "-"

mkdir -
ls | rg a
<stdin>:a

Edit: it yields same problem when I'm under folder contained '-' directory regardless what we grep:

$ cat text.txt | rg abc
<stdin>:abc def
<stdin>:def abc

BurntSushi · 2019-05-28T13:10:11Z

@arunvelsriram Could you confirm whether this is the same underlying issue? i.e., Does the output of ls include a - file/directory somewhere?

arunvelsriram · 2019-05-28T18:44:57Z

@BurntSushi Actually, I changed my machine recently and didn't face the issue after that. However, I tried the steps provided by @iiey and am able to replicate the issue.

arunvelsriram · 2019-05-28T18:45:50Z

Sorry, am not sure if my old machine listed a - on ls.

jpninanjohn · 2019-05-31T11:13:11Z

I had a look into the suggested part of the code and tried to debug this.

ripgrep/src/args.rs

Lines 1188 to 1204 in 0913972

    
               /// Return the default path that ripgrep should search. This should only 
        
               /// be used when ripgrep is not otherwise given at least one file path 
        
               /// as a positional argument. 
        
               fn path_default(&self) -> PathBuf { 
        
                   let file_is_stdin = self.values_of_os("file") 
        
                       .map_or(false, |mut files| files.any(|f| f == "-")); 
        
                   let search_cwd = 
        
                       !cli::is_readable_stdin() 
        
                       || (self.is_present("file") && file_is_stdin) 
        
                       || self.is_present("files") 
        
                       || self.is_present("type-list"); 
        
                   if search_cwd { 
        
                       Path::new("./").to_path_buf() 
        
                   } else { 
        
                       Path::new("-").to_path_buf() 
        
                   } 
        
               }

When paths are empty, a default path is given which is what is got by paths.get(0). This default path is also -.

Most cases when there is no directory with the name "-", paths.get(0).map_or(false, |p| p.is_dir()) will return false, in the case there is such a directory called "-", it will return true.

Then I don't know. You'll likely need to debug this yourself since I cannot reproduce it and I can't quite figure out how this could be happening. The first step here would be to just compile maste
r and see if the bug has been fixed already. If not, you'll want to debug this code:

ripgrep/src/args.rs

Lines 1471 to 1482 in 0913972

/// Returns true if and only if file names containing each match should

/// be emitted.

fn with_filename(&self, paths: &[PathBuf]) -> bool {

if self.is_present("no-filename") {

false

} else {

self.is_present("with-filename")

|| self.is_present("vimgrep")

|| paths.len() > 1

|| paths.get(0).map_or(false, |p| p.is_dir())

}

}

Namely, it seems like that's returning true for you, but I don't know why.

The solution I am thinking is to skip the check if its a directory, if the path is the default one. I'm not sure if this is correct though.

jpninanjohn · 2019-06-03T08:50:30Z

@BurntSushi

BurntSushi · 2019-06-03T09:19:39Z

I don't need to be pinged. Either someone can investigate and fix this issue, or I'll do it myself when I get a chance. This is not a high priority bug.

BurntSushi closed this as completed Apr 8, 2019

BurntSushi added invalid An issue that is not actually a bug or a feature that already exists. question An issue that is lacking clarity on one or more points. labels Apr 8, 2019

jpninanjohn mentioned this issue Jun 5, 2019

Fix stdin being printed when '-' exists as directory in path being searched #1292

Closed

BurntSushi reopened this Aug 1, 2019

BurntSushi closed this as completed in 9268ff8 Aug 1, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rg prints text "<stdin>" when input is given via stdin #1223

rg prints text "<stdin>" when input is given via stdin #1223

arunvelsriram commented Mar 18, 2019

BurntSushi commented Mar 18, 2019 •

edited

Loading

arunvelsriram commented Mar 18, 2019

BurntSushi commented Mar 18, 2019 •

edited

Loading

arunvelsriram commented Mar 18, 2019

BurntSushi commented Mar 18, 2019

arunvelsriram commented Mar 18, 2019

BurntSushi commented Apr 8, 2019

iiey commented May 28, 2019 •

edited

Loading

BurntSushi commented May 28, 2019

arunvelsriram commented May 28, 2019

arunvelsriram commented May 28, 2019

jpninanjohn commented May 31, 2019 •

edited

Loading

jpninanjohn commented Jun 3, 2019

BurntSushi commented Jun 3, 2019

rg prints text "<stdin>" when input is given via stdin #1223

rg prints text "<stdin>" when input is given via stdin #1223

Comments

arunvelsriram commented Mar 18, 2019

What version of ripgrep are you using?

How did you install ripgrep?

What operating system are you using ripgrep on?

Describe your question, feature request, or bug.

BurntSushi commented Mar 18, 2019 • edited Loading

arunvelsriram commented Mar 18, 2019

BurntSushi commented Mar 18, 2019 • edited Loading

arunvelsriram commented Mar 18, 2019

BurntSushi commented Mar 18, 2019

arunvelsriram commented Mar 18, 2019

BurntSushi commented Apr 8, 2019

iiey commented May 28, 2019 • edited Loading

BurntSushi commented May 28, 2019

arunvelsriram commented May 28, 2019

arunvelsriram commented May 28, 2019

jpninanjohn commented May 31, 2019 • edited Loading

jpninanjohn commented Jun 3, 2019

BurntSushi commented Jun 3, 2019

BurntSushi commented Mar 18, 2019 •

edited

Loading

BurntSushi commented Mar 18, 2019 •

edited

Loading

iiey commented May 28, 2019 •

edited

Loading

jpninanjohn commented May 31, 2019 •

edited

Loading