Shell invocation should exit non-0 exit status on failure

[bsolomon1124]

Common convention with lint tools is to exit >0 if errors are found. That is not the case with lintr, either for lint() or lint_package():

$ Rscript -e "lintr::lint_package('myProjName')"
R/rdaPackaging.R:14:9: style: Only use double-quotes.
library('knitr')
        ^~~~~~~
R/rdaPackaging.R:15:9: style: Only use double-quotes.
library('packrat')

$ echo $?
0

[russHyde]

Since lintr is a package, rather than a command line tool, the exit code is the responsibilty of your lintr-calling script.

You could add lints <- lint(...); quit(status=length(lints)), I guess.

[bsolomon1124]

Since lintr is a package, rather than a command line tool, the exit code is the responsibilty of your lintr-calling script.

I don't understand why this mentality dominates the R ecosystem.
Who runs a linter by importing it into an R repl?

Name one other languages that by convention suggests running linters as libraries
rather than as command-line tools.

$ python -m flake8 foo.py
foo.py:1:10: E201 whitespace after '('
foo.py:1:12: E202 whitespace before ')'

$ echo "$?"
1

$ python -m flake8 ok.py
$ echo "$?"
0

Here flake8 defines a main entry point which then raises SystemExit if the number of found issues is > 0.

[russHyde]

Suggest adding a section to the docs to explain how to run lintr at the command line (and return an appropriate exit code from lintr)

[AshesITR]

There is a setting error_on_lint which should do what you want to.

Can you try putting error_on_lint: TRUE into your .lintr and re-run your test?

[bsolomon1124]

Thanks @AshesITR , I verified that error_on_lint will call quit() with an exit code >0.

https://github.com/jimhester/lintr/blob/5e53d7a1435739faf05651f6abc754de67941b5c/R/methods.R#L81

IMO, that should be the default, but understand why there might be reluctance to change it and create backwards incompatibility.

[MichaelChirico]

I believe superseded by #1226