this post was submitted on 14 Oct 2025
68 points (78.3% liked)
linuxmemes
27796 readers
46 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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)?Thanks, I didn't know they work like that.
I was thinking more along the line of the return 1 example.
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
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.