Skip to content
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

doesn't work in a nonexistent dir #1291

Closed
torkve opened this issue Jun 4, 2019 · 5 comments
Closed

doesn't work in a nonexistent dir #1291

torkve opened this issue Jun 4, 2019 · 5 comments
Labels
bug A bug.

Comments

@torkve
Copy link

torkve commented Jun 4, 2019

What version of ripgrep are you using?

ripgrep 11.0.1
+SIMD -AVX (compiled)
+SIMD +AVX (runtime)

How did you install ripgrep?

cargo install ripgrep

What operating system are you using ripgrep on?

Ubuntu 19.04

Describe your question, feature request, or bug.

When the CWD is a nonexistent directory, and ripgrep is invoked, it always fails even if target is a valid absolute path. GNU grep works in this case.

If this is a bug, what are the steps to reproduce the behavior?

0 ➜ mkdir somepath
0 ➜ cd somepath/
0 ➜ rm -rf ../somepath/
0 ➜ rg something /etc/hostname 
No such file or directory (os error 2)
2 ➜ 

According to strace, ripgrep invokes getcwd() at some point and fails with it.

If this is a bug, what is the actual behavior?

0 ➜ RIPGREP_CONFIG_PATH= rg --debug something /etc/hostname 
DEBUG|grep_regex::literal|/home/torkve/.cargo/registry/src/github.com-1ecc6299db9ec823/grep-regex-0.1.3/src/literal.rs:59: literal prefixes detected: Literals { lits: [Complete(something)], limit_size: 250, limit_class: 10 }
DEBUG|globset|/home/torkve/.cargo/registry/src/github.com-1ecc6299db9ec823/globset-0.4.3/src/lib.rs:435: built glob set; 0 literals, 0 basenames, 11 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
No such file or directory (os error 2)

If this is a bug, what is the expected behavior?

I expect ripgrep to fail only in cases when any relative paths are used, while the only-absolute-paths command should be successfully executed.

@BurntSushi
Copy link
Owner

Could you please describe the use case for running ripgrep in a directory that doesn't exist?

@torkve
Copy link
Author

torkve commented Jun 4, 2019

I just cd'ed into some temporary directory, created by my tests runner application (running somewhere in the background). And then I was doing some debugging.
When tests runner finished its work, it just removed that temporary directory, so it became nonexistent.

@torkve
Copy link
Author

torkve commented Jun 4, 2019

I may agree to some extent that this case is not very typical, and probably one should watch the directory they work in, and do not execute commands in some their random terminal session :)
But even with that, the error misguides because user assumes that problem is with the file, not the cwd.

@BurntSushi BurntSushi added the bug A bug. label Jul 11, 2019
@afrubin
Copy link

afrubin commented Aug 28, 2019

Could you please describe the use case for running ripgrep in a directory that doesn't exist?

I encountered this bug because I was in a network mounted directory but the network connection (OneDrive via rclone in this case) had been closed.

It did cause quite a bit of confusion until a colleague suggested I check the working directory. This had not occurred to me because I was searching a completely different part of the file system.

@yump
Copy link

yump commented Nov 3, 2019

I encountered this because I was sitting in /proc/$some_app_pid, rg-ing through smaps. I restarted some_app, and thought it would suffice to rg /proc/$(pgrep some_app)/smaps, but instead got this confusing error, "No such file or directory (os error 2)".

BurntSushi added a commit that referenced this issue Feb 17, 2020
It turns out that querying the CWD while in a directory that no longer
exists results in an error. Since the CWD is queried every time ripgrep
starts---whether it needs it or not---for dealing with glob matching,
ripgrep winds up being completely useless inside a non-existent
directory.

We fix this in a few different ways:

* Firstly, if std::env::current_dir() fails, then we fall back to trying
  to read the `PWD` environment variable.
* If that fails, that we return a more sensible error message so that a
  user can at least react to the problem. Previously, the error message
  was inscrutable.
* Finally, we try to avoid the problem altogether by building empty glob
  matchers if not globs were provided, thus side-stepping querying the
  CWD completely.

Fixes #1291, Closes #1400
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants