added exit code term

Author: thomasWeise

bibliography/bibliography.bib

@@ -1413,6 +1413,13 @@ @book{J2024PTOGBSI8IS12E
  urldate = {2024-10-30},
 }
 
+@inbook{J2024PTOGBSI8IS12EETAP,
+ title = {\texttt{exit} -- Terminate a Process},
+ crossref = {J2024PTOGBSI8IS12E},
+ url = {https://pubs.opengroup.org/onlinepubs/9799919799/functions/exit.html},
+ urldate = {2024-10-30},
+}
+
 @inbook{J2024PTOGBSI8IS12ESSSSIS,
  title = {\acrshort[hyper=true]{stderr}, \acrshort[hyper=true]{stdin}, \acrshort[hyper=true]{stdout} -- Standard {I/O} Streams},
  crossref = {J2024PTOGBSI8IS12E},

notation/terms.sty

@@ -33,6 +33,19 @@ is another programming language, which is very successful in system programming
 }%
 %
 %
+\newglossaryentry{exitCode}{%
+name={exit code},%
+description={%
+When a process terminates, it can return a single integer value (the exit status code) to indicate success or failure~\cite{J2024PTOGBSI8IS12EETAP}. %
+Per convention, an exit code of~0 means success. %
+Any non-zero exit code indicates an error. %
+Under \python, you can terminate the current process at any time by calling \pythonilIdx{exit} and optionally passing in the exit code that should be returned. %
+If \pythonilIdx{exit} is not explicitly called, then the interpreter will return an exit code of~0 once the process normally terminates.%
+If the process was terminated by an uncaught \pythonilIdx{Exception}, a non-zero exit code, usually~1, is returned.%
+}%
+}%
+%
+%
 \newglossaryentry{exponent}{%
 name={exponent},%
 description={%

styles/listing.sty

@@ -275,7 +275,7 @@ $\downarrow$~~\expandafter\bashil{python3 #3}~~$\downarrow$%
 %
 $\downarrow$~~\expandafter\bashil{python3 #3}~~$\downarrow$%
 %
-\lstinputlisting[label={exec:#5},style=text_style,caption={The \gls{stdout} and \gls{stderr} as well as the exit code of the program~\href{\csname @pwp@gitUrl:lst:#5\endcsname}{\textil{#3}} given in~\cref{lst:#5}.}]{\csname @pwp@gitFile:exec:#5\endcsname}%
+\lstinputlisting[label={exec:#5},style=text_style,caption={The \gls{stdout} and \gls{stderr} as well as the \pgls{exitCode} of the program~\href{\csname @pwp@gitUrl:lst:#5\endcsname}{\textil{#3}} given in~\cref{lst:#5}.}]{\csname @pwp@gitFile:exec:#5\endcsname}%
 \end{figure}%
 }%
 %

text/back/scripts.tex

@@ -29,12 +29,12 @@
 A unit test executed with \pytest\ will fail and exit with a non-zero exit code if the test, well, fails.
 A static code analysis tool like \ruff\ will fail with a non-zero exit code if it discovers any issue with the code.
 However, our scripts invoking these tools will \emph{not} fail in such cases.
-They will collect the exit code of the tool they are invoking and print it.
+They will collect the \pgls{exitCode} of the tool they are invoking and print it.
 Then they will exit with exit code~0.
 This is necessary for our book building process, which invokes these scripts to construct the outputs of the examples.
-If any of them would fail with non-zero exit code, the book building would fail as well.
+If any of them would fail with non-zero \pgls{exitCode}, the book building would fail as well.
 However, to illustrate that the tools are useful, we must apply them to cases where they would fail.
-So for our book, it is necessary that the scripts just print the exit codes while still returning successfully.
+So for our book, it is necessary that the scripts just print the \pglspl{exitCode} while still returning successfully.
 For a real productive environment, this is usually not what we want:
 We apply the tools to source code precisely to get them to fail on error, because if nothing fails, we know that everything seems to be OK.
 In such a practical environment, you would thus not want to use \emph{our} scripts, but you could use the same comments that we use.
@@ -46,7 +46,7 @@
 It then prints the command with a prepended~\expandafter\textil{\$}.
 Then, it executes it.
 \mypy\ will print its comments and messages to the standard output.
-Finally, the script shows the \mypy\ version and exit code in a brief success or failure message (with a prepended~\expandafter\textil{\#}).
+Finally, the script shows the \mypy\ version and \pgls{exitCode} in a brief success or failure message (with a prepended~\expandafter\textil{\#}).
 \Cref{exec:variables:variable_types_wrong_hints_1:mypy,exec:variables:variable_types_wrong_hints_2:mypy} are example outputs of this script.
 
 \Cref{lst:bash:ruff} works basically the same way, just for \ruff.
@@ -71,7 +71,7 @@
 Either way, the script executes the test cases, prints the results as well as potential errors.
 Notice that we select some options to make the output less verbose, because for this book, we do want listings that are not too long.
 In practical scenarios, you may use different options.
-Either way, the script also prints the command that was executed at the beginning and the \pytest\ version used and the program's exit code at the end of the output.
+Either way, the script also prints the command that was executed at the beginning and the \pytest\ version used and the \pgls{exitCode} of the process at the end of the output.
 \Cref{exec:functions:test_my_math:pytest,exec:functions:test_my_math_2:pytest,exec:functions:test_my_math_3:pytest} are examples for the output of \pytest.%
 %
 \endhsection%

text/main/basics/gettingStarted/firstProgram/firstProgram.tex

@@ -147,7 +147,7 @@
 Indeed, the text \bashil{Hello World!} appears.
 
 Well, before that text, we see the command line that was actually executed, namely the \python\ interpreter with our file's path as parameter.
-And after our program's output, we are notified that \inQuotes{Process finished with exit code~0,} which means that the program has completed successfully and without error.
+And after our program's output, we are notified that \inQuotes{Process finished with \pgls{exitCode}~0,} which means that the program has completed successfully and without error.
 
 Congratulations.
 You now have written, saved, and executed your first ever \python\ program!%

text/main/basics/simpleDataTypesAndOperations/introduction/introduction.tex

@@ -15,11 +15,11 @@
 It must be a text.
 
 The command \pythonil{exit}, on the other hand, can either have no parameter or one parameter.
-If it receives one parameter, this parameter will be the exit code of the program.
+If it receives one parameter, this parameter will be the \pgls{exitCode} of the program.
 Here, \pythonil{0} indicates success.
 If no parameter is provided, this will be used as default value.
 We need to invoke \pythonil{exit} if we use the \python\ console in the \pgls{terminal} explicitly.
-If we just run a program, then after the last instruction of the program was executed, then the interpreter will also terminate with exit code~0.
+If we just run a program, then after the last instruction of the program was executed, then the interpreter will also terminate with \pgls{exitCode}~0.
 Indeed, when we executed our first program in \cref{sec:ourFirstProgram}, we saw exactly that happen in \cref{fig:firstProgram09programResult}.
 Different from the parameter of \pythonil{print}, which must be some text, the parameter of \pythonil{exit} needs to be a number.
 

text/main/basics/variables/typesAndTypeHints/typesAndTypeHints.tex

@@ -108,8 +108,8 @@
 All we have to do is invoke it in the terminal, giving the program to be checked as argument as well as some additional parameters.
 In \cref{exec:variables:variable_types_wrong:mypy}, we invoke \bashil{mypy variable_types_wrong.py --no-strict-optional --check-untyped-defs}, where \textil{variable_types_wrong.py} is the (very fitting) name of the program to check.
 Indeed, \mypy\ tells us that something dodgy is going on in the fourth line of that program, i.e., \pythonil{int_var = int_var / 3}.
-It will fail with an exit code of~\bashil{1}.
-Programs usually return~\bashil{0} as exit code if everything went well and some non-zero value if something went wrong.
+It will fail with an \pgls{exitCode} of~\bashil{1}.
+Programs usually return~\bashil{0} as \pgls{exitCode} if everything went well and some non-zero value if something went wrong.
 And something went wrong, because \mypy\ found the error.%
 %
 \usefulTool{mypy}{%

text/main/controlFlow/exceptions/exceptions.tex

@@ -68,7 +68,7 @@
 %
 \item The control flow immediately leaves the currently executed block of instructions as well as all calling blocks or functions.
 It jumps up in the call hierarchy until reaching code that handles the raised \pythonilIdx{Exception} is reached.
-If no such code exists, the current process is terminated with an exit code different from~\textil{0}.%
+If no such code exists, the current process is terminated with an \pgls{exitCode} different from~\textil{0}.%
 %
 \end{enumerate}%
 %
@@ -199,7 +199,7 @@
 In our original \pythonil{tuple} of inputs that we iteratively passed to \pythonil{sqrt}, the last three elements are \pythonilIdx{inf}, \pythonilIdx{nan}, and \pythonil{-1.0}.
 The call to \pythonil{sqrt} with \pythonil{inf} as argument was performed and failed.
 After that, no further output has been generated.
-Indeed, the control flow has left the \pythonil{for}~loop and the process has been terminated with exit code~1, as the output in \cref{exec:exceptions:use_sqrt_raise} shows.
+Indeed, the control flow has left the \pythonil{for}~loop and the process has been terminated with \pgls{exitCode}~1, as the output in \cref{exec:exceptions:use_sqrt_raise} shows.
 
 Terminating the process may seem rash, but it is not.
 If a programmer used our \pythonil{sqrt} function incorrectly, then this will force them to fix their error.