EXIT(1P)

πŸ’… PROLOG πŸ’…

okay bestie, real talk before we get into it: this page is part of the POSIX Programmer's Manual. the Linux version of this whole situation might be different (so like, go check the matching Linux manual page for the deets on how Linux actually behaves), or honestly it might not even be implemented on Linux at all. πŸ™ˆ


✨ NAME ✨

exit β€” make the shell dip out. that's it. that's the whole job. πŸ’–


🌸 SYNOPSIS 🌸

exit [n]

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the exit utility makes the shell leave its current execution environment, and it takes the exit status you give it β€” that's the unsigned decimal integer n. πŸŽ€

here's the tea tho:

  • if the current execution environment is a subshell environment, the shell exits from that subshell environment with the exit status you specified, and then it keeps going in the environment that invoked that subshell environment. so like, the subshell leaves, the party continues. πŸ’ƒ
  • otherwise, the shell utility itself terminates, with the exit status you specified. bye forever. πŸ‘‹

and if n is specified but its value is not between 0 and 255 inclusively, the exit status is undefined. like, nobody knows what happens. it's giving chaos. πŸ’€

also! a trap on EXIT gets executed before the shell terminates β€” with one exception: if the exit utility is invoked in that trap itself, then the shell exits immediately. no extra steps. periodt. ✨


πŸ‘‘ OPTIONS πŸ‘‘

None. literally zero. nothing to see here. πŸ’…


πŸ“ OPERANDS πŸ“

go look at the DESCRIPTION. it's all in there, babe. 🫢


🌈 STDIN 🌈

Not used. untouched. unbothered. ✨


πŸ’œ INPUT FILES πŸ’œ

None. πŸŽ€


🧚 ENVIRONMENT VARIABLES 🧚

None. nope. zero. 🌸


⭐ ASYNCHRONOUS EVENTS ⭐

Default. πŸ¦‹


πŸ’– STDOUT πŸ’–

Not used. she's not talking to stdout today. πŸ™ˆ


πŸ”₯ STDERR πŸ”₯

standard error shall be used only for diagnostic messages. that's its one job. πŸ’…


πŸŽ€ OUTPUT FILES πŸŽ€

None. πŸ“


🌸 EXTENDED DESCRIPTION 🌸

None. πŸ’œ


✨ EXIT STATUS ✨

okay so the exit status shall be n, if you specified it β€” with the caveat that the behavior is unspecified if n is not an unsigned decimal integer, or if it's greater than 255. unspecified!! 😭

otherwise? the value shall be the exit value of the last command that was executed, or zero if no command was executed. cute.

and one more lil detail bestie: when exit is executed in a trap action, the "last command" is considered to be the command that executed immediately preceding the trap action. πŸ“


πŸ¦‹ CONSEQUENCES OF ERRORS πŸ¦‹

Default. πŸ‘‘

heads up: the following sections are informative. (iykyk) πŸ’«

πŸ’œ APPLICATION USAGE πŸ’œ

None. πŸŽ€


🌈 EXAMPLES 🌈

exit with a true value:

exit 0

exit with a false value:

exit 1

propagate error handling from within a subshell:

(
    command1 || exit 1
    command2 || exit 1
    exec command3
) > outputfile || exit 1
echo "outputfile created successfully"

slay. 🫢


πŸ‘‘ RATIONALE πŸ‘‘

so, like explained in other sections, certain exit status values are reserved for special uses, and applications should only use them for those exact purposes. respect the reserved list, bestie:

  • 126 β€” a file to be executed was found, but it was not an executable utility.
  • 127 β€” a utility to be executed was not found.
  • >128 β€” a command was interrupted by a signal.

now the messy part: the behavior of exit when you hand it an invalid argument or an unknown option is unspecified, because all the historical implementations did their own thing. not iconic, just facts. 😭

a value larger than 255 might get truncated by the shell, and then it's unavailable even to a parent process that uses waitid() to get the full exit value. so like, the full value? gone. πŸ’€

it is recommended that implementations which detect any usage error should cause a non-zero exit status β€” or, if the shell is interactive and the error doesn't cause the shell to abort, store a non-zero value in "$?". but even that wasn't done historically in all shells. so yeah. πŸ™ˆ


πŸŽ€ FUTURE DIRECTIONS πŸŽ€

None. πŸ’…


⭐ SEE ALSO ⭐

  • Section 2.14, Special Built-In Utilities

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group.

In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. (it's the final boss. πŸ‘‘)

The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


okay that's the whole page bestie, we ate and left no crumbs 🫢✨ this was IEEE/The Open Group, 2017, signing off πŸ’…πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from