born@shell

As some of you know – but which you usually don’t notice on this blog –, I study Computational Linguistics, a discipline that can be characterized as “that which Google does” – a characterization as precise as it is vague. In this field, I study linguistic phenomena and the computational methods used to analyze them, and I sit, as its name suggests, a lot in front of a computer. And thus I had an idea.

As announced in one of the first blog posts (in German) – and as suggested by the blog subtitle –, this blog is about how I see the world and that which constitutes my world and its view thereof. Since I am a student for quite a while now (*cough*) and because I am more and more within the depths of computers, I found it to be appropriate to present this world to you as well.

Therefore, I would like to start with a small post on my shell setup (explanation follows), that at the same time introduces the new category “Technically Speaking”, which will focus on computer-related stuff. As you will see (today just a bit, though – in other posts or tutorials it will be clearer), this world is a text-based one, and even if it is not a literary one, it might be a world unknown to some of you.


echo $SHELL

The shell is the direct and unvarnished interface to the command world underlying all graphical user interfaces. With it you communicate your commands directly to the computer and the shell is known as a command-line interpreter (CLI).1 You input your text-based commands to this command-line interpreter by means of a prompt of a command-line interface (also CLI), which is displayed as the terminal.

Now, if you spend a lot of time in the shell world, you start to type a lot of stuff repeatedly that would be executable much more conveniently if you had a shorthand for that; furthermore, you might want to modify the appearance or layout of your command-line interface to suit your personal needs or to have everything accessible or visible at all times. Thus, modifications can be achieved by adding shorthands or functions for doing things that require a lot of typing in just a single character or word, and by changing the actual appearance of your CLI.

In today’s post I want to focus on the second aspect, which is also called bash or prompt customization, as an introductory note.



source .bash_prompt

Now, as suggested, the prompt denotes the command-line interface, the area of the terminal where you input your commands. To give you an image of how that looks, here is a screenshot of a very simple prompt (the command pwd stands for print working directory, where the working directory is the directory you’re currently in):

Screenshot #1. A very simple shell prompt.

Screenshot #1. A very simple shell prompt.

So this looks quite boring. The actual environment in which a programmer/developer works in looks different for everybody, of course. The variant I am about to show you is thus just the one I feel most comfortable working in. But before I explain the details of my prompt, first just take a look at it:

Screenshot #2. My own shell prompt, the user name is redacted for security reasons.

Screenshot #2. My own shell prompt, the user name is redacted for security reasons.

As we can see, there are always at least two lines necessary: the first line of the prompt contains some basic information and the second line provides the actual input field for the commands (identifiable by the the dollar sign ($) at the beginnig of the line). They are followed by one or more optional output lines.

The basic information looks for example like this (it is color-coded as to correspond to my prompt, although yellow is displayed here as light orange to make it more readable and white is displayed black here due to different backgrounds; <> denote placeholders and all optional elements are surrounded by curly braces):

[5]<username>@Leos-MBP(22:17, Ⓜ46.5%):~/Documents/git/dotfiles {on master{*}}{▸▸▸▸▸▸▸▸▸▸}


Here, [5] is the number of todos in my terminal-based todo application<username> is my username, which I redacted for security reasons in the above screenshot; Leos-MBP is my computer name; 22:17 is the time; Ⓜ46.5% is the amount of used memory; ~/Documents/git/dotfiles is the relative path to the current directory; master is the currecnt branch in a git repository and * indicates that there are some modifications2; and ▸▸▸▸▸▸▸▸▸▸ is the current battery status.

The appearance of the prompt is usually defined in the (usually) invisible file called .bash_prompt. To make any changes effective, this file has to be intialized with every opening of your terminal; this happens through the command source .bash_prompt, which is in the also usually invisible file .bash_profile.3


Let’s take a look at two useful shorthands at the end, which are pictured above, g and d. As we can see (lines 1-3), the working directory changes from ~ (the so-called home directory) to ~/Documents/git, the place where my git projects are, due to the command g. The command d (third-to-last line), on the other hand, results in getting to the directory ~/Desktop, which is, well, my desktop. Put differently, you can from any directory you’re in basically “jump” to any other customly defined directory by means of just a single character or word.

Such simple shorthands are called aliases in the shell world, which are defined e.g. in the file .bash_profile,4 which looks like this:

alias g='cd ~/Documents/git'
alias d='cd ~/Desktop'


It should be clear, though, that your abbreviations can be as short or long as you want them to be. For example, one of the commands could as well have been defined as alias gitdir='cd ~/Documents/git'. You should take care, however, that your own shorthands don’t overlap with already existing commands. In that case, it could be that you overwrite built-in or separately installed commands and that this leads to functions or scripts depending on those commands to fail.

Because there are a lot of examples on the internet that can serve as an inspiration for your own bash custimization5 which are not used in an identical environment with the same software you use, you should still make sure to define your aliases or functions suited towards your individual environment. For example, I once found the alias gs for the command git status, which in my case overlapped with the standard command of the Ghostscript software suite. Thus, I chose the alias gst, as you can see in the second screenshot.

And now: exit


Mumon

—————————————————————

Footnotes

1 Historically, there have been a lot of kinds of shells, although bash, the bourne again shell is probably the most well-known one. It is widely established as the default shell on many *nix-systems (e.g. Mac und Linux).

2 The two last pieces of information are only displayed when I am in a git repository, obviously.

3 This file defines the default settings for your shell. Sometimes it is just called .profile or .bashrc. In other shells it is again named differently. For simplicity’s sake I only refer to .bash_profile in the main text.

4 It would be nicer and clearer, though, to define these aliases in a separate file, e.g. .bash_aliases. This would also be needed to be initialized in .bash_profile (source .bash_aliases).

5 Just to get you started, these are some nice git repositories containing such dotfiles for bash customization: Mathias Bynens, Paul Irish, Simon Owen, and Zach Holman.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.