Shell or Terminal? Shell Scripting – Part 1

Published on September 8, 2022 at 6:45 pm by LEW

Introduction

This is the first post in a series of posts on shell scripting. The purpose of this series is to familiarize you with the shell and writing your own scripts . However we cannot dive directly into writing scripts without a little background information first.

In this post we will be discussing the various shells and terminals that you might run across in Unix Like ( sometimes abbreviated as UN*X or *nix) Operating Systems (OS). While I am using a bash shell, that is no guarantee that your OS will be using bash. For compatibility, I am going to try and stay away from bash specific stuff. The examples in this series of posts should work in most of the common shells you are likely to run across.

Boring Historical Stuff

When I use the word “shell” in the context of this series of posts, I am referring to a text based program running on an OS that allows the user to interact with the computer or device. A more descriptive name would be “command shell”.

Another term you will likely see frequently is “terminal” or “terminal emulator”. A terminal program is a wrapper around the shell program. To understand this concept we will look at the historical context.

In the beginning of the computer age (mid 1960’s), there were no fancy Graphical User Interfaces (GUI). Everything was handled by a text based shell program. Also around this time there was a distinct lack of standardization.

Generally computers were setup on a collection of centralized hardware. Users had no direct access to this hardware. Instead they connected to via a physical device known as a terminal. Terminals had no built in software or programming beyond what was needed to turn it on, and connect to the central computer (mainframe). Originally these terminals were teletypes or teleprinters (paper based system) which had been used for years for sending and receiving messages (so they already had some communications protocols built in). Later variations on theme added a text only video display, and in some cases did away with printers/punch cards/paper tape (early non magnetic storage media).

Jumping forward many years with the advent of the desktop computer, the peripheral market moved to separate monitors and keyboards, with no built in communications protocols. Therefore it was up to the computer OS itself to handle user input/output.

Since there was an existing code base, what better way to handle this than to emulate the old hardware terminal standards in the OS software. VT100 is an example of one of the early terminal emulation programs (introduced in 1978 and used on early video displays).

The DOS/UNIX computers would boot up into a terminal emulator which would have the shell running on it, allowing the user to enter commands and receive feedback.

With the advent of the GUI, computers no longer had to boot into a terminal emulator. However, as powerful as some modern GUIs are, they cant do everything. So there is still a need to access a shell. Only now it is running on a terminal emulator which is displayed in a window of the GUI.

What I am Currently Using

Running the neofetch command in my terminal yields the below information.

NeoFetch of My current system

The neofetch program displays lots of information. The items I want to draw your attention to are the Shell entry (bash) and the terminal entry (konsole).

Lets Talk Different Shells

There are an awful lot of Linux shells available. I stooped counting when I reached fifteen. A lot of these are what I would call niche shells, and most normal users are unlikely to run into them. Below are the two shells I suspect you are likely to be using.

Bourne Shell: One of the early shells, written by Stephen Bourne, and released by Bell Labs back in 1977. This shell is also referred to as “sh”. It is still available on most Unix like systems.

BASH Shell: BASH is an acronym for “Bourne-Again Shell”. It was written by Brian Fox and released in 1989. it was one of the early programs that Linus Torvalds ported to his Linux system. It is currently one of the most popular shells among Linux users, and the default in many distributions.

There are several other shells that you may run across; C shell (csh), Z shell (zsh), and Almquist shell (ash). Other shells are far less common. For the level of scripting we are going to do in this series of posts, the shell should not matter. If you get into more complex scripting, be aware that there are differences between how different shells behaves.

Lets Talk Different Terminal Emulators

If you thought there where to many shells out there, you have not ventured into the world of terminal emulators yet. The terminal emulator you use will be a matter of personal choice. This is one of those near religious arguments to many enthusiasts. In the case of terminal programs, there is quiet an array of features that some have and some do not. While this does not affect how your script runs, it can effect how you work.

At the bottom end there is plain “xterm”. This is part of the X Windows system, so quite common. Nothing fancy here, it is a plain terminal. It can be customized, but that involves using Xresoruces, a subject for another post. I have used it, it works, it does the job. It is just plain.

Lets talk about my current terminal, “konsole”. This is part of the KDE suit of programs, and it has a lot of dependencies. However since I am running KDE Plasma for my desktop, I have them already. If you are not running Plasma, then konsole will drag in a lot of KDE dependencies. I am not a fanatic, and if I was using a Gnome desktop, then I would be using “gnome terminal”. The big question is what do these terminal programs get you that you do not get in xterm?

Both support tabs. That is you can have multiple terminals open in a single window, each on its own tab. Both support customization. They each have their own configuration utilities and do not require editing Xresources. This includes things like notification, color schemes, bookmarks, and keybindings. None of this is essential, but it can make your workflow easier.

There are also a number of non desktop specific terminal programs out there. Alacritty, Terminator, Guake, Yakuake, ant Tilda to name a few.

In the end, for what we will be doing, you can use whatever shell, and terminal you have available, or what ever ones you prefer..

Lets Talk Different Text Editors

This one is real quick. Basically you can edit a script file in any text editor. You can also use a word processor, assuming you remember to save your files as text files, and fix the extensions.

You can also write your scripts in the terminal itself using programs like vim or nano. For simple scripts this is fine. However when things get longer and more complicated it is nice to have a GUI based text editor.

Just for the record, since I am in a KDE environment, I am using the Kate text editor for longer scripts. For shorter scripts, I tend to use vi in the terminal.

Don’t have Access to a System?

The majority of desktop and laptop users run only Windows. So you may not think you have an Unix Like system to work with. Below are two ways you can get access. For what we are doing here, it does not have to be anything overly fancy.

Conclusion

In this first post we went over some basics about command shells and terminal emulators. This centers around what you have installed already, and personal preference. But I wanted to touch on it briefly.

In the next post we will jump into writing a simple script and executing it.

Shell or Terminal? Shell Scripting – Part 1

Simple Script Example! Shell Scripting – Part 2

Command Line Arguments! Shell Scripting Part 3

User Input! Shell Scripting Part 4

Using Functions! Shell Scripting Part 5

Variable Odds and Ends! Shell Scripting Part 6

SharePin It!

Add New Comment

Your email address will not be published. Required fields are marked *