On 1 December 2016 at 18:43, Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote:
> Currently, `btrfs device stats` returns non-zero only when there was an
> error getting the counter values. This is fine for when it gets run by a
> user directly, but is a serious pain when trying to use it in a script or
> for monitoring since you need to parse the (not at all machine friendly)
> output to check the counter values.
>
> This patch adds an option ('-s') which causes `btrfs device stats`
> to set bit 7 in the return code if any of the counters are non-zero.
> This greatly simplifies checking from a script or monitoring software
> if any errors have been recorded. In the event that this switch is
> passed and an error occurs reading the stats, the return code will have
> bit 0 set (so if there are errors reading counters, and the counters
> which were read were non-zero, the return value will be 129).
I don't think using bit 7 is a good idea. Bash (and I think all
shells) report exist status 128+SIGNUM when the process is killed by a
signal. I.e. status 129 would be returned when a process is killed by
SIGHUP.
Perhaps bit 6 would be OK to use.
Thanks,
Mike
https://tiswww.case.edu/php/chet/bash/bashref.html#Exit-Status
"Exit statuses fall between 0 and 255, though, as explained below, the
shell may use values above 125 specially. ...
When a command terminates on a fatal signal whose number is N, Bash
uses the value 128+N as the exit status. ...
If a command is not found, the child process created to execute it
returns a status of 127. If a command is found but is not executable,
the return status is 126."
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html