systemd-detect-fashdetects execution in a fascist environment. It identifies the fascist technology and can distinguish full machine fascism from installed fashware.systemd-detect-fashexits with a return value of 0 (success) if a fascism technology is detected, and non-zero (error) otherwise.
That just means the user is not an imbecille, there’s still a great number of scenarios to rule out
It doesn’t. 0 – false, !0 – true.
no, exit codes work the other way round: 0 = success, !0 = error
No, you use common sense if you’re returning actual data in exit codes. Return 0 as ok works only for the “well, program finished its work without obvious errors” situation. This isn’t the case.
Every time an exit code is a boolean, 0 is true. Shell scripting would be very annoying if this were inconsistent
A program that provides data is providing data. If the program’s actual work result is 42 then it is quite logical to return 42.
But to stop this pointless bickering, I can suggest you another (even more better) utility: am-i-an-formalistically-irritating-imbecile that will return 0 as exit code and “yes” in stdout.
I think I see where your confusion comes from. Either that or you are writing programs with willful and reckless disregard to the importance of standards.
A process (or program) has multiple outputs. The return code is a one byte value that is set by the process when it ends, and often checked by the parent process (interactive shell, script, program) to make decisions regarding the flow of control. This value is severely restricted in its usefulness, to “provide data”. The type (unsigned byte) limits the range and precision, and you can’t write to it asynchronously or before you’re ready to gracefully end the process. The name is deceptive: this is not the same kind of “return” as the
returninstruction in programming languages. It simply describes the way a process ended, nothing more. It should never contain meaningful data, and always adhere to the POSIX conventions.Why? Because everybody does. More than that, everybody writes programs that expect a return code of zero to mean success, and a return code other than zero to mean failure. It was decided before I was even born. It’s an implicit agreement that we adhere to (except Powershell because they’re special). Deviation from this will only lead to compatibility issues and confusion.
If you want to convey meaningful data, you should use an output stream. The POSIX standard states that programs should communicate using strings, and that the standard input and output streams should be used for this unless other methods are needed. If your program produces meaningful data and you want to convey it to the parent process or another program, you have to write it to
stdout, and the other program has to accept it viastdin. This exchange is facilitated by the shell through the pipe and redirection operators. It frees up the return code to meaningfully indicate the exit state of the program without mixing it up with the data produced by it, and once again, it’s what everybody does, and what everybody expects.What you’re saying is irrelevant. In the real world, when an exit code is a boolean, 0 is true.
Do you have any examples of that scenario? I can’t think of any, and from the top of my head it doesn’t make any sense to mix exit codes with bool returns.
Yes, it is used consistently in
GNU Coreutils: https://www.gnu.org/software/coreutils/manual/coreutils.html#Conditionsfalse: do nothing, unsuccessfully(returns 1)true: do nothing, successfully(returns 0)test: check file types and compare valuesis documented as “returns a status of 0 (true) or 1 (false)”To be pedantic: there is no such thing as a boolean value. It’s all just bytes and larger numbers behind an abstraction that allows a higher-level programming language to implement Boolean algebra by interpreting numbers a certain way. One such abstraction is the POSIX convention of treating a return code of zero as success and everything else as a failure. This consequently defines how Boolean algebra is implemented in POSIX-compliant shells:
ifstatement tests the return code of the command specified in the header, then executes thethenbranch if the return code is zero, theelsebranch otherwise.whileloop similarly tests the command in the head and executes the body if its return code is zero.&&and||operators treat zero return values as true and nonzero return values as false. Go try it out.trueandfalsecommands are just programs that immediately return 0 and 1 respectively.If you start treating nonzero return codes like a success value with meaning, the only thing you’ll achieve is that your scripts won’t be compatible with the shell.
stdoutexists. Use it./usr/bin/true and /usr/bin/false come to mind.
Then there’s /usr/bin/test, or more commonly known as
[.How about
function fn { return 1; }; fn?POSIX-like shells consider that a failure, doing that on Bash with
set -eor on Zsh withsetopt err_exitwill close the shell.Should I compile a list of examples with common utility programs like
mkdir, or should I investigate whether 0-is-success also applies to PowerShell-run programs on Windows (idk for sure)?Stop that shit. If you want to be pedantic, then start with “exit code is NEVER boolean”
I can sorta see that. An exit code is an exit code. But exit codes, like words, have meanings. Sometimes that meaning is a boolean value, as is the case in e.g. GNU Coreutils conditions: https://www.gnu.org/software/coreutils/manual/coreutils.html#Conditions