Exit status is 0 even when exiting with an error
Closed this issue · 5 comments
Issue tracker
If any of these values are not included, the issue will be closed and not worked
Issue
I would expect a non-zero value to be returned when there is an error in argument parsing. The below command exits and prints "Error: Unknown option output." but the commands return value is 0.
Debug Report
checksec version: 2.1.0 -- 2019072901
Command run to produce the error
checksec --output json --file=/usr/lib64/libpython3.7m.so.1.0
OS version and Kernel version
N/A
Debug output
N/A
I would expect a non-zero value to be returned when there is an error in argument parsing
But... why? It is like saying "hey, nothing bad happened, just proceed!".
If this change is done and if the CLI changes later on (e.g. we swap order of some operations, change some option flags etc) then someone's CI may silently break after upgrading to newer version (as usually ppl set up automated tooling in a way to crash the build if any command returns value other than 0).
Because something bad did happen?
Exactly the scenario you're describing is what just happened to me, but because the tool did not output non-zero on error it was not obvious that the issue was command line parsing had changed. My setup assumed a 0 value means "OK to parse the resulting output" which then resulted in an error from the JSON engine, as it tried to parse the error message as valid json.
If someone has a CI system dependent on a tool, I would guess they consider argument parsing failure, and the tool not running, to be a failure that should actually kill the build as something in their pipeline is no longer working.
As a side note: All *nix standard tools I just tried output non-zero on argument parsing failures. e.g.
$ file -o /usr/bin/php
file: invalid option -- 'o'
Usage: file [-bcCdEhikLlNnprsvzZ0] [--apple] [--extension] [--mime-encoding]
[--mime-type] [-e <testname>] [-F <separator>] [-f <namefile>]
[-m <magicfiles>] [-P <parameter=value>] <file> ...
file -C [-m <magicfiles>]
file [--help]
[sean@localhost ]$ echo $?
1
Omg, I interpreted it totally opposite, I am sorry!
Yeah. I totally agree it should return non-zero in such cases!
Haha, OK, awesome, I was super confused for a few minutes there =D
resolved in upcoming release (2.2.0)