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

Regexps in configuration file are ignored if no other regexp is present in the command line #1730

Closed
cyrus-and opened this issue Nov 15, 2020 · 5 comments
Labels
doc An issue with or an improvement to documentation.

Comments

@cyrus-and
Copy link

What version of ripgrep are you using?

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

How did you install ripgrep?

brew install ripgrep

What operating system are you using ripgrep on?

macOS 11.0.1

Describe your bug.

If regexps (--regexp) are exclusively specified in the configuration file, then they are ignored.

What are the steps to reproduce the behavior?

$ cat /tmp/.ripgreprc
--regexp
foo
$ echo 'xxx foo xxx' | RIPGREP_CONFIG_PATH=/tmp/.ripgreprc rg

What is the actual behavior?

$ echo 'xxx foo xxx' | RIPGREP_CONFIG_PATH=/tmp/.ripgreprc rg --debug
error: The following required arguments were not provided:
    <PATTERN>

USAGE:

    rg [OPTIONS] PATTERN [PATH ...]
    rg [OPTIONS] [-e PATTERN ...] [-f PATTERNFILE ...] [PATH ...]
    rg [OPTIONS] --files [PATH ...]
    rg [OPTIONS] --type-list
    command | rg [OPTIONS] PATTERN

For more information try --help

What is the expected behavior?

xxx foo xxx

(With foo being highlighted.)

@BurntSushi
Copy link
Owner

Could you please explain why you want to do this?

@cyrus-and
Copy link
Author

I'm using ripgrep as a backend for some script and I'd like to pass all the arguments/configuration in the same way. Using the configuration file seems more elegant than passing individual parameters on the command line which (albeit unlikely nowadays) is subject to limitation.

@BurntSushi BurntSushi added the doc An issue with or an improvement to documentation. label Nov 15, 2020
@BurntSushi
Copy link
Owner

Thanks for clarifying. Ultimately, this would be difficult to fix and I don't think your use case is worth it. I updated the man page's section on config files to clarify this case.

@cyrus-and
Copy link
Author

I see your point and admittedly I'm not aware of the internals, but still this somewhat smells fishy (no disrespect) for a number of reason, e.g., the fact that the usage hints that rg can run without arguments:

rg [OPTIONS] [-e PATTERN ...] [-f PATTERNFILE ...] [PATH ...]

And also that it can be worked around with something like (for the sake of the argument):

$ echo 'xxx foo xxx' | RIPGREP_CONFIG_PATH=/tmp/.ripgreprc rg -e '$x'
xxx foo xxx

Anyway thanks for such a quick action and for this project!

BurntSushi added a commit that referenced this issue Nov 15, 2020
The man page had the correct usage hints, but the -h/--help output was
using an older more incorrect version of the hints.

Closes #1730 (again)
@BurntSushi
Copy link
Owner

BurntSushi commented Nov 15, 2020

Ah, yes, the usage hints in the -h/--help output appear to have gotten out of sync with the man page. The man page has the correct usage hints. I've fixed that.

The usage hints were also written long before the config file functionality existed. So just running rg with no arguments never really made sense. There wouldn't be anything for rg to do. And even with support for config files, this is a rather extreme edge case. Configuration files were never really intended to be a way to supply 100% of all arguments to ripgrep. They are intended to solve the problem of passing common arguments. The only reason why this sort of thing even looks possible is because of the config file format: it's just CLI flags. If the config format were, say, a Yaml file, there wouldn't be any expectation that this would work I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc An issue with or an improvement to documentation.
Projects
None yet
Development

No branches or pull requests

2 participants