Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 15
Like Tree2Likes
A long-standing convention in Linux is that programs return 0 if they run successfully and exit normally, 1 if they fail for some reason. As a result, 0 has come ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,243

    Does anyone know the history of this convention?


    A long-standing convention in Linux is that programs return 0 if they run successfully and exit normally, 1 if they fail for some reason. As a result, 0 has come to mean TRUE and 1 FALSE. For example grep returns 0 if a specified pattern occurs in its input and 1 if it doesn't. But in C code, 0 is FALSE and 1 is TRUE.

    The Linux convention obviously goes back to the earliest days of UNIX. But I read somewhere that UNIX was developed in the Bell Labs, and they were responsible for C too. So why did they use diametrically opposite conventions for return values? It's especially odd because so many other things in UNIX/Linux come from C.
    "I'm just a little old lady; don't try to dazzle me with jargon!"
    www.hrussman.entadsl.com

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,664
    Actually, the "standard" for Unix programs was that they return a non-negative integer (or 0) for success, and negative values (-1 == 255 on some systems where return value in the shell is coerced to an unsigned char) for errors. This is useful for situations where you might want to return some rational value other than 0 for the results, like how many apples are in that bowl? So, -1 might mean "some unknown error", and -2 might mean "file not found".
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,243
    Quote Originally Posted by Rubberman View Post
    Actually, the "standard" for Unix programs was that they return a non-negative integer (or 0) for success, and negative values (-1 == 255 on some systems where return value in the shell is coerced to an unsigned char) for errors.
    Well, that's much closer to libc's convention of integer functions returning -1 for failure and some informative integer for success. So the zero for success is purely a Linux thing? But where did it come from? I know it confused the hell out of me when I was learning scripting.
    "I'm just a little old lady; don't try to dazzle me with jargon!"
    www.hrussman.entadsl.com

  4. $spacer_open
    $spacer_close
  5. #4
    Linux User sgosnell's Avatar
    Join Date
    Oct 2010
    Location
    Baja Oklahoma
    Posts
    494
    C starts counting from zero, not one. Zero is the first, and default number.

  6. #5
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,664
    Quote Originally Posted by sgosnell View Post
    C starts counting from zero, not one. Zero is the first, and default number.
    That's as good a reason as I could come up with! In any case, you might have to ask Linus, and he'd probably say that it was what Unix did! Then you'd have to go back to Kernighan, Thompson, et all - unfortunately, many of those boffins have recently migrated to that server farm in the sky!
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #6
    drl
    drl is offline
    Linux Engineer drl's Avatar
    Join Date
    Apr 2006
    Location
    Saint Paul, MN, USA / CentOS, Debian, Slackware, {Free, Open, Net}BSD, Solaris
    Posts
    1,294
    Hi.

    It seems to me that the shell focuses on control of processes. We could view a process as completing "correctly" in only one way, compared to being able to fail in a number of ways. Among a range of numbers, zero seems to be a good choice to say that a process completed that one "correct" way. Testing for zero is short and simple. If it were to signal an error, additional testing would be required. Note that a negative exit status would require an additional character, and, if anything, early Unix was opposed to anything extra (long program names, gratuitous completion messages, etc.). Processes are subject to signals -- exogenous events. To differentiate errors or anomalies, small positive integers are used for a program-specific exit status, and signals + 200 for "larger" issues. I seem to recall that some early systems / shells allowed a negative exit status, but that that was not portable.

    You can look over the Bourne shell code (for 7th edition): http://minnie.tuhs.org/cgi-bin/utree...usr/src/cmd/sh , but, at a quick glance, I did not see any comments concerning the specific design choice for the exit status of processes. Earlier editions (at the same site) have code for the Thompson shell (very small); I did not look for the Mashey shell. Similarly, skimming the Bell System Technical Journal, July/August, 1978 did not produce any illumination.

    I usually told students that, in the case of shell, "0 is OK", as a way of remembering the seemingly strange choice of design.

    Best wishes ... cheers, drl
    elija and Rubberman like this.
    Welcome - get the most out of the forum by reading forum basics and guidelines: click here.
    90% of questions can be answered by using man pages, Quick Search, Advanced Search, Google search, Wikipedia.
    We look forward to helping you with the challenge of the other 10%.
    ( Mn, 2.6.n, AMD-64 3000+, ASUS A8V Deluxe, 1 GB, SATA + IDE, Matrox G400 AGP )

  8. #7
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,664
    Thanks drl for taking the time to research if there were any comments in the source code. If there ever were, they may have been stripped out over the years, just to clean up the ... Nah! REAL software engineers would NEVER remove someone else's comments from the code, would we?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  9. #8
    drl
    drl is offline
    Linux Engineer drl's Avatar
    Join Date
    Apr 2006
    Location
    Saint Paul, MN, USA / CentOS, Debian, Slackware, {Free, Open, Net}BSD, Solaris
    Posts
    1,294
    Hi.

    As many people tasked with maintenance duties have discovered, "real" programmers often don't comment code at all. There were comments in the shell source, but not very many.

    I was not really expecting to find comments about design in the code -- that's just the wrong place for it, unless there is a specific reason why something non-obvious was coded. On the other hand, Unix(TM) was young then, and there were not many best practices yet. I expected to find perhaps something about design in the BSTJ article by Steven Bourne. Again Unix was new, so it was more of a tutorial -- you can do this, you can do that ... etc.

    Still, I didn't look through all of the 2 dozen or so files, so a diligent searcher might be able to find gold in them thar hills o' code ... cheers, drl
    Welcome - get the most out of the forum by reading forum basics and guidelines: click here.
    90% of questions can be answered by using man pages, Quick Search, Advanced Search, Google search, Wikipedia.
    We look forward to helping you with the challenge of the other 10%.
    ( Mn, 2.6.n, AMD-64 3000+, ASUS A8V Deluxe, 1 GB, SATA + IDE, Matrox G400 AGP )

  10. #9
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,664
    To drl - true enough regarding design comments in the code. I think I must be the exception to that! I ALWAYS put comments in my code about what my intentions are, and why I did something non-obvious the way I did. Why? Because, I know from experience that someone else will have to follow in my footsteps, and leaving at least some trail of breadcrumbs will help them significantly. I know this because of the numerous times I have had to maintain/fix/upgrade other people's code and was scratching my head, saying to myself "Just what the F*** were they trying to do here?!"...
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  11. #10
    Penguin of trust elija's Avatar
    Join Date
    Jul 2004
    Location
    Either at home or at work or down the pub
    Posts
    3,636
    The best programming tutor I have had always said you should write your code as if the person maintaining it is a psychopath with an axe; and your home address. It's surprisingly difficult to do; far simpler to move every now and then
    "I used to be with it, then they changed what it was.
    Now what was it isn't it, and what is it is weird and scary to me.
    It'll happen to you too."

    Grandpa Simpson



    The Fifth Continent

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •