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.
I present you with another, better utility: am-i-an-imbecile. It just returns 1. Run it to make sure that you’re good.
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.
Stop that shit. If you want to be pedantic, then start with “exit code is NEVER boolean”