Linux Terminal

In some of my classes you will need to work with a Linux system without access to a graphical user interface (GUI). This document provides some hints about how to best do that.

Unix Overview

I wrote a Unix Overview that describes some basic concepts that are relevant to the Unix/Linux command line. It includes a chapter on the basic commands and a chapter on shell scripting. The document is old and a bit dated in some respects, but you may still find it useful.

There are many other online references for the basic shell commands. This command reference from FOSSwire.com seems reasonable.

Text Editors

On most Linux systems you can use one of the following three text editors in a terminal session:

nano. This is a simple editor that you can figure out by just using. It displays a list of commonly used commands at the bottom of the screen. The commands are (mostly) control characters. Use ^G to get more help.
emacs. This is a "power editor." It is hugely extensible and configurable. With proper plugins, and a lot of experience, you can use Emacs almost like a full IDE. On the negative side, Emacs has an enormous learning curve. You will not be able to just figure it out without the help of a tutorial, cheat sheet, or focused study. Most likely you'll need all three.

However, learning Emacs has value for its own sake. It is available for many platforms and has an active user community. Also, as you get better with it, you may find you like it more and more. Once you are fluent with using Emacs, you will likely find it very fast. I'm a heavy Emacs user, and I find myself frequently shutting down whatever complex environment I'm using and reaching for Emacs when I want to get real work done!
vim (or Neovim). This is another power editor. Like Emacs, it is cross-platform, hugely extensible, configurable, and has an active user community. Like Emacs, it has a large learning curve. Like Emacs, you may find that once you are fluent with it, using it is very fast.

There is a playful rivalry between Emacs users and Vim users as to which editor is the best. Both are good. However, they work very differently. Emacs uses many obscure control character sequences as commands. Vim is a moded editor; you must switch back and forth between "command mode" and "insert mode" as you use it. In both cases you can do your editing without touching the mouse or even lifting your hands from the home position on the keyboard, which is why they can be very fast.

You will find Nano quick and easy to use. However, I invite you to consider taking the plunge and really learning either Emacs or Vim (pick one). Install the editor of your choice on all your systems and start using it for all your editing needs. It will be excruciating at first, but by the end of the semester you might be surprised to find that you like it!

Session Management

What you want to avoid doing is this:

Start your text editor to edit a file in your program.
Exit your text editor.
Start your text editor to edit a different file in your program.
Exit your text editor.
etc...

All text editors suitable for programming allow you to load multiple files at once and switch between them. This includes Nano, Emacs, and Vim. Spend the time to find out how that works for your editor. If you are starting your editor for each file you want to edit, you are definitely not doing things the right way.

You also want to avoid this:

Start your text editor to edit the files in your program.
Exit your text editor.
Compile your program. Take note of the error messages.
Start your text editor to edit the files in your program to fix your errors.
Exit your text editor.
Compile your program. Take note of the error messages.
etc...

There are several ways to avoid this tedious process. I will describe them in order from the simplest to the fanciest. All the methods below can work well, however.

You can create multiple SSH sessions with your system. Run your editor in one session and keep the other session open for compiling and testing your program. When you want to try compiling, save your changes in the editor without exiting the editor, then switch to the other SSH session to run the compiler. This also allows you to keep the error messages in view (with their line numbers) while you fix the errors in the other SSH window.
Use job control. You can suspend the foreground process, such as your text editor, using ^Z. This does not terminate your editor, it only pushes it into the background in a suspended (non-executing) state. You can then issue commands to compile your program. When you want your editor back, use the fg command to return it to the foreground.

This procedure is similar to the first one except that it only requires a single SSH session and doesn't require that you manage multiple windows. Do a Google search for "linux job control" to find links to tutorials on the details of how to do this.
Use the features of your editor. Both Emacs and Vim (I'm not sure about Nano) have the ability to launch the make utility from inside the editor. They can show you the error messages produced in a separate pane and even jump to the location of those errors in your source files (in a very IDE-like manner). You can execute arbitrary programs while staying inside those editors, so you can even test your program without leaving the editing environment.
Use tmux. This is a terminal multiplexer utility. It allows you to create multiple pseudo-terminals with the output of each displayed in separate panes of a single SSH session window. Tmux also allows you to create multiple virtual "windows" each holding a collection of one or more pseudo-terminals. Although only one virtual window at a time can be displayed in a single SSH session window, the other virtual windows (and their associated pseudo-terminals) are still active. Tmux allows you to detach from a window, log out, return at a later time, and then reattach to the same window. This lets you start a long-running process without having to sit by the SSH session the entire time waiting for it to end before you can leave.

You should familiarize yourself with one of these methods for session management to make your experience using the terminal easier and more productive. Perhaps you believe that using a terminal session as a development environment would be too difficult. But if you are unfamiliar with the powerful editors and session management tools available there, you may be trying to use a needlessly inefficient workflow.