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

Should use exit code to distinguish between no results and an invocation error #1298

Open
wincent opened this issue Jan 11, 2019 · 3 comments

Comments

@wincent
Copy link

wincent commented Jan 11, 2019

ack, grep, and rg all return a different exit code when there is an error (different from the usual "1" which means "no results"). It would be nice if ag did the same.

Related rg issue: BurntSushi/ripgrep#948

@svaniksharma
Copy link

I don't know whether this issue was never closed, or whether haven't examined the recent code, but die(), the function utilised for reporting errors in ag and defined in util.c, looks like the following:

void die(const char *fmt, ...) {
    va_list args;
    va_start(args, fmt);
    vplog(LOG_LEVEL_ERR, fmt, args);
    va_end(args);
    exit(2);
}

The exit(2) at the end returns 2 as the exit code. However, the code returned in main during normal operation (no errors) is

return !opts.match_found;

Essentially, the above returns 1 if no results are found and 0 if results are found.

I'm not sure whether you would like to distinguish between specific errors or whether you just wanted to know whether an error occurred during operation via the exit status. I personally don't know the internals of ag very well, but as far as I can tell, die() is used for reporting all errors and exiting when an error occurs. Unless there are certain places where this doesn't occur, I think your issue has been solved.

@wincent
Copy link
Author

wincent commented Feb 20, 2019

@s1l3ntcat: I reported this based on the behavior of (what I think is) the latest release, v2.2.0:

$ ag --non-existent > /dev/null
ag: unrecognized option `--non-existent'
zsh: exit 1

It is possible this has already been fixed in master.

@svaniksharma
Copy link

@wincent: That would explain things. It's strange they didn't close your issue though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants