Living on the Unix Command Line: The Importance of a Prompt

2014/12/06 13:05:19
Print Friendly

Over the last decade, I’ve continued to gravitate more and more toward Unix and the command line while many of my colleagues have gravitated toward GUI applications. This post is not about the pros and cons of GUI vs. CLI or how one is better than the other. Suffice it to say, I live with both, but spend a lot of time working in terminals.

Today we focus on the prompt. Many people leave the prompt set to the default for their distribution, which may be fine, but in my 20 years of Unix use, I’ve found some nice tweaks that make my life easier. I share them here because you may find them useful as well.

The default prompt for a Red Hat Enterprise Linux system looks like the following:

[smj@athena bin]$

This gives me an idea of which user I’m logged in as (smj), which server I’m logged in to (athena) and the current working directory (bin). Unfortunately, in the example above, my current working directory is actually /usr/local/bin. Based on the default prompt, I cannot tell if I’m in /usr/local/bin, /opt/bin, /usr/bin, /bin, or even /home/smj/bin. This presents a problem considering how often much of the Unix directory structure repeats itself.

Another issue I have is that I’m pretty sure I’m logged in to the bash shell, but can’t really be sure. I’ve had to endure many shells in my career, from sh to bash to csh to tcsh to ksh and some I can’t even remember because they appeared so infrequently.

So, to address these problems, I spent time trying to find a prompt that would provide enough information to be useful, while working across several platforms and shells.

My current bash prompt looks like so:

18:30:33 smj@athena:/usr/local/bin
bash $ -->

My current tcsh prompt looks like so:

18:40:01 sjone@procyon:/usr/local/bin
tcsh % -->

There is no color in either prompt. This avoids any issues between different terminal color schemes or terminal types. It works equally fine in the Linux console and hpterm.

You may be asking, why does he need all of this information in the prompt? Let’s review each part of my prompt.

Newline at start

Consider the following text from an open terminal with a prompt containing no information:

total 892
-r-sr-xr-x. 1 root bin 234404 Aug  3 18:35 cdcc
-r-xr-xr-x. 1 root bin  44568 Aug  3 18:35 dccif-test
-r-sr-xr-x. 1 root bin 627422 Aug  3 18:35 dccproc
#cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
#128.82.7.27 e-2104-13 e-2104-13.cs.odu.edu
#netstat --inet
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5011        TIME_WAIT
tcp        0    116 athena.littleprojects.o:ssh 192.168.191.210:5012        ESTABLISHED
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5013        TIME_WAIT
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5014        TIME_WAIT
tcp        0      0 localhost:10024             localhost:58377             TIME_WAIT
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:di-ase      TIME_WAIT
tcp        0      0 localhost:10025             localhost:53230             TIME_WAIT
tcp        0      0 localhost:10025             localhost:56526             TIME_WAIT
tcp        0      0 localhost:10024             localhost:58375             TIME_WAIT
#gvim chicken.txt

Can you quickly glance out it and tell me which commands have been executed? I need some separator on the screen to indicate the individual command executions so I can tell what happened. Without a separator, it looks like one big garbled mess, so I opted for a newline between the prompt and the command executions.

Try it now?

total 892
-r-sr-xr-x. 1 root bin 234404 Aug  3 18:35 cdcc
-r-xr-xr-x. 1 root bin  44568 Aug  3 18:35 dccif-test
-r-sr-xr-x. 1 root bin 627422 Aug  3 18:35 dccproc

#cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
#128.82.7.27 e-2104-13 e-2104-13.cs.odu.edu

#netstat --inet
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5011        TIME_WAIT
tcp        0    116 athena.littleprojects.o:ssh 192.168.191.210:5012        ESTABLISHED
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5013        TIME_WAIT
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:5014        TIME_WAIT
tcp        0      0 localhost:10024             localhost:58377             TIME_WAIT
tcp        0      0 athena.littleprojects.o:ssh 192.168.191.210:di-ase      TIME_WAIT
tcp        0      0 localhost:10025             localhost:53230             TIME_WAIT
tcp        0      0 localhost:10025             localhost:56526             TIME_WAIT
tcp        0      0 localhost:10024             localhost:58375             TIME_WAIT

#gvim chicken.txt

Now I can clearly see that the top is the output of some command that has scrolled off the screen, but the cat, netstat, and gvim commands came next. It’s not that I can’t figure out what commands were executed (or even look at the history), but that when I’m comparing commands and output to each other, I need to be able to quickly see which sections of output belong to which commands. For me it’s a legibility and time-saving measure.

Time last command exited

At the beginning of the prompt is a timestamp.


18:30:33 smj@athena:/usr/local/bin
bash $ -->

This timestamp serves as a “poor man’s time command” letting me know (roughly) just how long the previous command took to run. It also serves as a way to keep track of times if I have a meeting or other engagement coming up. I put it in front, so when I see the prompts in sequence I can compare them to one another.

Username

Next is the username.


18:30:33 smj@athena:/usr/local/bin
bash $ -->

I don’t have the same username for each account. I also want to know if I’m running as root or a regular user. Sometimes that forces me to notice that I’m root before I do something dangerous. With one terminal up, this is not a problem. When I’m switching between five, it becomes increasingly important to keep each straight.

Server hostname

And equally useful to the username is the hostname of the server to which I’m connecting.


18:30:33 smj@athena:/usr/local/bin
bash $ -->

With the hostname I can tell different terminal sessions apart and ensure that I don’t make a mistake of typing the wrong command on the wrong server.

Full Path

As noted above, I like seeing the full path in my prompt. This way I can tell where I am on the server.


18:30:33 smj@athena:/usr/local/bin
bash $ -->

I also have a newline inserted after the path because a long path can scroll pretty far across the screen and some terminals have an issue including both the command and a long prompt on the same line.

The whole username@hostname:path exists so I can easily copy and past this string into an SCP command for moving files between servers. This is easier than typing scp myfile username@hostname:path by hand, especially considering hitting <tab> doesn’t work to expand the path for the server you are copying to.

Shell Name

This was one of the last things I added. I use a lot of bash; a LOT OF bash, but occasionally I have accounts (thank you ODU) that are tcsh, or I need to use an ancient server running csh or sh. I wanted to ensure that I could readily identify the shell as I switch between systems, so I have the prompt state which shell is running.


18:30:33 smj@athena:/usr/local/bin
bash $ -->

This means that I actually have login scripts for each shell that attempt to create as close as possible an approximation of the bash prompt. For example, if I’m suffering through an actual Bourne Shell session, I only get this:
sjone@E-2104-13.cs.odu.edu
sh $ -->

For tcsh, I get this:

18:40:01 sjone@procyon:/usr/local/bin
tcsh % -->

The point is that the shell is identified on the line on which I’m typing commands. This way I will know about the shell so I can change my syntax for items, such as redirecting stderr to stdout, when using a shell other than bash.

I do not control all of the servers I log into. Even though I may prefer bash, administrators on other systems have everyone default to tcsh or other shells. I try to ensure that my login prompt reflects this difference, especially when I’m working across several machines.

"The Arrow"

I added the arrow (–>) with an additional space afterwards so I can separate the prompt from the command that has been run. I find this to be useful, much like the newline between prompts, when looking at the output from a series of commands. It allows me to separate the commands I run from their output.

No color

Finally, I work across multiple systems with different terminal emulators, some of which I cannot choose for myself. At work I use PuTTY or Attachmate Reflections. At home I prefer the Mac OS X terminal program, or < a href="https://help.gnome.org/users/gnome-terminal/stable/">gnome-terminal, but I don’t always get to use my home computer for all of my projects. Sometimes, I don’t even get to configure the terminal how I would like!

Imagine that I had selected a color scheme using blue. Now imagine that same blue with a black background. Was that even legible? If cannot change the background to white or gray then I have to strain to read that text. Also, consider yellow on a white background. If I cannot reliably control my background colors, I really can’t select any meaningful foreground colors either.

Hence, I put not color into my prompt.

Setting up the prompt

To generate my prompt, I set the PS1 variable to the following value in my .bashrc file:

PS1='\n\t \u@\h:\w\nbash \$ --> '

The \n provides the newline, the \t provides the time, the \u provides the username, the \h the hostname, the \w the full path, and the rest is just text.

See the bash man page.

TCSH is not that much different:

set prompt = "\n%P %n@%m:%~\ntcsh \% --> "

Here, the %P provides the time, the %n provides the username, the %m the hostname, the %~ the full path (substituting ~ for my home directory), and the rest is just text.

Other shells do not have these fancy variables for telling time or providing other information, so for those shells I just set them with a text string providing as much meaningful information as I can get. I even have a custom Windows Command Prompt I use when I’m able to set it myself.

Summary

I hope you have found this article a useful resource. Though I realize not everyone is in the same situation I am, having to adapt to many differing environments, I hope that you can take away something useful from this discussion about the importance of a prompt on the command line.

For more information on how to set up your prompt effectively, Carla Schroder has a nice article discussing the use of colors and other features. For more in depth information on the bash prompt, check out the Giles Orr’s Bash Prompt HOWTO from the Linux documentation project. Understudy has a similar article to this which discusses more shells.

Whatever you do, take some pride in your prompt! It doesn’t just have to be that place where you give information, you can also get information.

Research, Research, Research

2014/03/24 21:09:18
Print Friendly

Lately, over the past few years, I’ve been pursuing my Master’s Degree in Computer Science from Old Dominion University. It’s been a crazy ride. Some of the courses have merely been a review of information I already knew. Others were some of the most difficult in my life.

Now, I face a new challenge: the thesis.

I’ve done some preliminary work with Memento, RFC 7089, as developed by my colleagues at Old Dominion University and Los Alamos National Laboratory. Memento is a way of browsing the web as if it were a date in the past. I’ve identified a new use case: avoiding spoilers in TV shows, movies, and books.

I’m working on bringing my work on the Memento MediaWiki Extension into my thesis, which I hope to publish by the end of the year.

Wish me luck!

A memo on Open Source

2010/06/10 03:34:13
Print Friendly

In light of the arrival of the iPhone 4, I’ve been confronted with an age-old question:  what is the current state of open source?

Apple is ruling the future of the phone market with iPhone.  Android is the up-and-coming competitor.  Google is betting on their Linux phone, and betting hard.  Google’s goal is to make money with their ads.  I figured it would work, until I saw that Apple had iAds, something far more media-rich than Google Ads.

Apple is creating the tablet market with the iPad.  Some manufacturers have been working on Android tablets, but they will be late to the game.

Apple is moving into the mobile gaming market with the iPhone/iPod/iPad.  Android hasn’t really started to achieve the level of choice available in the Apple App Store.

Microsoft is continuing to hold onto its desktop OS market.  OS X is making inroads into this market because of Microsoft’s failure to get wide adoption of Windows Vista.  It remains to be seen if Windows 7 can recoup those losses.  Desktop Linux failed on many fronts for many reasons.  OS X and Windows have something Linux lacked, a consistent interface for applications.  Ubuntu is the most promising Desktop Linux available for the average user, but it can’t overcome the inconsistency across the UIs of the thousands of applications it supports.

Microsoft is continuing the hold onto its business server market.  This is the market of file sharing and directory services.  Neither Apple nor the Open Source world have been able to offer an alternative in these areas that has the level of adoption as Windows Servers.

Linux seems to be best suited for appliances, like wireless routers, but it remains to be seen how many hardware manufacturers see it as beneficial to continue to use Linux rather than implementing their own OS and utilities.

Linux seems to be the platform of choice for hosting application servers, like JBoss.  Unfortunately for Linux, most (all?) of these application servers can also be easily run on Windows or OS X.

Linux seems to be the platform of choice for web servers.  This is largely because Linux is inexpensive and IIS is not as feature-rich as Apache.  Apache can be easily run on Windows or OS X.

So, where does Open Source fit into this new world order?

There are several options for the Open Source developer (not in any particular order):

  1. Write applications in Java, Scala, or some other language that is platform independent, in hopes that it will be available on the largest number of platforms.  This will not help you on iOS, where you are stuck with Apple’s API and Apple’s implementation of Objective-C.
  2. Continue to develop applications for the LAMP platform.  As most of the these apps only need the AMP without the Linux, get used to the idea that folks might run it on Windows or OS X.
  3. Write some libraries that can be incorporated into iOS apps.  This may violate Apple’s terms of use, so be careful.
  4. Continue to write desktop applications that only run on Linux.
  5. Android.  Google is actually achieving some consistency for apps on its Linux platform, but not to the degree that Apple’s draconian tactics have achieved.
  6. Make something NEW.  Actually innovate in a way that forces the Apples and the Microsofts of the world to fear, and, eventually copy, the idea/concept/software.  This is an area where open source once shined.

Automatically Backing up Blogger

2009/02/14 00:26:00
Print Friendly

In my continuing quest to use Google Apps as best I can, I’ve been reading up on the Google Blogger API.

I thought that automatically backing up a blog on Blogger would be easy, but it turned out to be a more complex script that I had originally thought.

Authentication was the part that I was missing. Using curl, I can acquire the authentication information like so:

curl https://www.google.com/accounts/ClientLogin -s -d Email=smj@littleprojects.org -d Passwd=mypassword -d accountType=GOOGLE -d source=blog-backup -d service=blogger

From this line, you get output like so:

012345678902234567890323456789042345678905234567890623456789072345678908234567890
SID=DQAAAHYBADCv2pSv7nflacDNwz3zEDUGtrSvNVDcpkSfddi77b3U5sEaHmP8YLWhmA36F9rk85mL
8J5dqo4apn0T1vKz0fPGI9Xtnuet6cuE2ZzYvrNIwbSC_HjTqF4zudNQnnlDuD2wqZT-g1qXI8KhGAQZV4NexHZoQPlabTsGuRZeIBxj1ALSID=EUBBBIaBADCl-kNxvRVmcQghpt3cqSMfEooKR9flLOUZqwgP9OrZS83gse-KSdTNeXhxsET7FYenDhceP9lIPOmesH-t9qh-AWUHjjMdZEbUNeF9mWyzln6Z-FajaiG-cVFkqW0ZJ8ZbnCP30xXj6xFK6QxaAcqy_9Pej8jhEnxS9E61ftQGPgAuth=EUBBIacAAADK-kNxvRVmcQghpt3cqSMfEooLNMflLNIQqwgP9OrZS83gs-KSdTNeXhxsET7FYePWmaD8Vsy1V4LSUGMUP48Je2TO8OcjBj6HgAtPhiZeX-gKDfagZDK44j4n-Tkb44nhOnp2_QPSnBj3Z2vYwOEDjjG3Q53aQVC2132JKOuGh

The line we’re interested in is the one starting with “Auth=”. This is what we will use to authenticate to blogger so that we can grab our blog backup.

Part two consists of downloading the XML backup of all of your posts.

I knew that I could go to the following URL to get a backup of my blog posts:
http://www.blogger.com/feeds/blogid/archive

where I fill in blogid with the blogID supplied by your URL on Blogger. For example, as I type this, the URL in the address bar is

http://www.blogger.com/post-create.g?blogID=6964696676319111700&postID=8574983142196621787

which tells me that my blogID is 6964696676319111700.

So, to download the blog backup, I use the following URL:
http://www.blogger.com/feeds/6964696676319111700/archive

With the use of the tool curl and some Bourne Shell scripting, the following script can be used to automatically download my XML file containing a backup of my blog from Blogger.

#!/bin/sh
 
# Authentication and authorization
export Auth=`curl https://www.google.com/accounts/ClientLogin -s -d Email=smj@littleprojects.org -d Passwd=mypassword -d accountType=GOOGLE -d source=blog-backup -d service=blogger | grep "Auth="`
 
# Get the xml file and store it into blog-backup.xml
curl -H "Authorization: GoogleLogin ${Auth}" "http://www.blogger.com/feeds/6964696676319111700/archive" &gt; blog-backup.xml<span style="font-size: 85%;">

Now I set cron to run this script once a week and I will have a backup of my blog entries should something horrible befall blogger; or I choose another blogging service.

References:

Backing up other Google Apps Items

2009/01/24 11:55:00
Print Friendly

Currently, I’ve found no other app that promises to back up my Blogger, and Google Docs information using the server-side schedule method I described in my last post.

But, alas, Google has provided hope. There is a Python client library for available to access data on Google’s servers. Check it out; I’m gonna grab the files and see what I can whip up to back up my items.