- Preamble
- History
- Introduction
- Implementation
- Usage
- Discussion
- Limitations
- Conclusion
- Further Reasearch
- References
One of the finest truths of the world is that there is no one true method to accomplish a given task. Perhaps no class of people know this truth better than programmers, who dedicate their lives to finding provacative and innovative ways to solve problems. By our nature, we are not pleased with finding the simple, "cookie cutter" way to reach our goal. To quench our thirst, we must devise an intricate approach to reach our destination.
Exiting a terminal is a something every programmer has done thousands of times. Thousands of times, a programmer exits a terminal by clicking on the 'x' in the top right corner. This method of exiting is tried and true, battle tested, but makes for a path that has been beaten down to nothing. Fewer programmers exit their terminal session by running the shell command exit. We have decided neither of these methods are sufficient. We have decided to pave our own path, by writing our own shell script to exit a terminal session. This is the story of Exit.sh.
The Bourne-again Shell (Bash) is a command line interpreter and language written by American computer scientist Brian Fox. The shell was designed to be a free-software alternative to the Bourne shell. Bash was initially made for the GNU Project in 1989, but is still used today as the default login shell for most Linux and MacOs distrobutions.
The Bash language syntax is a superset of the Bourne shell which it successfully replaced; Bash inherits brace expansion, command line completion, debugging, and a variety of other expressions – one of which is the exit keyword, which calls for the termination of a script. Keyword exit's output reflects the exit status of an executed command. Exit statuses range from 0 to 255. Exit.sh's behavior will be further discussed in the implementation section of this exposition.
The 'x' button and its sister-platform counterparts have been a staple in graphical user interfaces since their inception in the early 1980. This concept was first formally reseached in Stuart K. Card's, The Psychology of Human – Computer Interaction. In their study, Card and his colleagues refined the ever-popular concept of a Windows, Icons, Menus, and Pointer interface, or WIMP interface. Coined by Merzouga Wilberts, the now-antiquated acronym has been likened to the term GUI. As it's expanded name suggests, WIMP describes the visual representation of containerized programs on the user's screen. These programs would be accessed using a pointer to click on icons or select from menus to achieve to instantiate and input to programs. The widely accessible nature of this arrangement revolutionized computer usage as we know it today – unveiling a world of virtually infinite possibilities for non-programmers, and thus allowed for rapid adoption by companies and households around the globe.
WIMP is not without its flaws, however; the design has been critisized on many fronts – the foremost of which is the lack of consideration for people with disabilities. One example: WIMP-style user interfaces place visually impaired users at a disadvantage, especially when alternate text interfaces are not made available. Exit.sh effectively overcomes this limitation, uniting all developers and end-users alike.
Our approach to Exit.sh aims to mesh elegance and functionality by creating a succinct script to overcome the aforementioned burden that is the 'x' button. This goal is certainly ambitious, and achieving it was no simple feat. One factor which influenced this script's implementation is legibility. It was Linus Torvalds – pioneer of the world-renowned Linux kernel – who said:
UNIX has a philosophy, it has 25 years of history behind it, and most importantly, it has a clean core. It strives for something - some kind of beauty.
- Linus Torvalds
It is an unfortunate truth that many programmers sacrifice legibility for quick or easy application. However as programmers we must strive for legibility, for it is the most tangible and human aspect of coding as an art itself. To write legible code is to preserve this work of art, therefore empowering other developers to create works of their own through style, grace, and transparency. An obsessive focus on these principles combined with our core objectives rendered an extremely daunting task.
According to the Bash official documentation, the exit status of a command is the value returned by the waitpid system call or equivalent functions. Under certain circumstances, the shell will use special values to indicate specific failure modes.
For the shell’s purposes, a command which exits with a zero exit status has succeeded. A non-zero exit status indicates failure. This seemingly counter-intuitive scheme is used so there is one well-defined way to indicate success and a variety of ways to indicate various failure modes. When a command terminates on a fatal signal whose number is N, Bash returns an exit status 128+N.
Parameters can be passed to Bash scripts in the command line interface. Arguments are accessed inside a script with the $ symbol and the argument's respective index.
Our initial implementation, or first official version, of Exit.sh took user arguments. While the exact original implementation was lost in a sea of notes, test scripts, and early concepts, the first official script likely looked something like this:
exit $1
Despite this implementation's bloated or otherwise needlessly complex nature, it permits users to pass their preferred exit status as an argument. For example, a user might want to terminate Exit.sh with exit code 1 as opposed to 0. In practice this would look like:
user@user:~/$ sh exit.sh 1
User arguments do allow for more flexibility on the user's behalf, as there are simply more possible exit statuses. However we opted to take a more streamlined approach, which is only allowing the script to execute with exit code 0. This logic behind this decision will be elaborated on in the discussion section.