The Command Line II: Shells and getting around the filesystem

Share

Welcome to the second post. In this post we are going to leave all the philosophising behind and get down to learning some real command line skills. So strap yourself in for a whirlwind guide to moving around the file system; creating, moving and copying files; setting permissions and getting basic information about your system all from the spartan interface of the Unix command line. Hopefully at the end you’ll get a glimpse of the awesome power that this interface places at your finger tips and maybe inspire you to learn more about this amazing tool.

Starting a terminal and Bash

The first step in learning the command line is finding out where to start. As we saw in the last post, the days of the terminal being the sole interactive portal to a computer are, thankfully, long in the past. Instead we will use a terminal emulator which will let us access the command line from the familiar surroundings of our graphical interface. So, before we do anything else we are going to open up a terminal. If you are running Linux or OSX you are in luck as a terminal is included with the OS, you’ve just got to find it. If you are running Windows then you going to need to get a bit creative to get a Unix like shell. To get yourself up and running follow the following instructions for whatever platform your on:

OSX:

  1. Hold down COMMAND and hit the spacebar.
  2. In the top right the blue Spotlight “search bar” will pop up.
  3. Type: terminal
  4. Click on the Terminal application that looks kind of like a black
    box.
  5. This will open Terminal.
  6. You can now go to your Dock and CTRL-click on the terminal icon to
    pull up the menu, then select Options->Keep In Dock.

Linux:

  1. If your running Linux I am going to assume that you already know
    how to open a terminal.
  2. If this is not the case then you need to have a look around for
    ‘Terminal’ or ‘Shell’ in the applications menu of your window
    manager.
  3. Linux is great but different distributions do the craziest things
    and its hard to give a one size fits all explanation, so I’m not
    going to.

Windows:

  1. Your going to have get a shell from somewhere else
  2. Amazon EC2 has virtual instances that are available for a cheap
    hourly rate (they also do Windows instances) — a micro instance
    is perfect for what we are going to be doing and its free!
  3. Use VirtualBox or similar software to virtualise a Linux instance
    on a PC.
  4. Cygwin is an open source posix-compatible unix environment that can
    be installed in Windows – http://www.cygwin.com/
  5. Install Linux on your PC (you can dual boot)
  6. Get a free Unix shell account (for example Arbornet offers free
    accounts on Unix systems http://www.arbornet.org/index.php)

Hopefully you now have a terminal up and running. Unlike other programs there shouldn’t be a splash screen and no wizard introducing you to the program. What you should see is just an open window with some text at the top right corner. The text should look something like:

Jasons-MacBook-Air:bioinformatics-org jason$

This is what my terminal looks like. The text to the left of the `$’ (it may be a `%’ on your system) is configurable and will differ between systems but it generally gives you some information about your system. In this case the host name (the computer name) is ‘Jasons-MacBook-Air’, my current directory is ‘bioinformatics-org’ and my username is ‘jason’. After the ‘$’ sign is where you input will show up when you start typing something. In future examples, to save space, I will omit the text and just start with a `$’, but keep in mind that there is normally text and it is configurable (see below for examples). The text and the `$’ are collectively called the prompt and whenever you see the prompt it means that the terminal is waiting for you to start typing, or, you could say, it is prompting you to type something. So what we need now is something to type and our first task will be to find out what shell we are running.

When we started the terminal a program started running a program called the `shell’. The shell is what is presenting the prompt and waiting for our commands. This program provides the environment in which we are going to get our work done; it provides a set of basic tools for making our way around the file system, creating and moving files. It also gives us access to, and a way to execute, more sophisticated programs that either came with the OS but aren’t a part of the shell, were written by other people or are programs you have written yourself. The commands we can use and the syntax, or `language’, we must use differ depending on what flavour of shell you are running. There are a number of different shells that you can use depending on your personal preferences, a short list includes csh, tcsh, zsh, Dash and sh, but most users today run into a shell called Bash, short for Bourne Again SHell. This shell is standard on OSX and in most Linux distributions, although Ubuntu uses a variant of Bash called Dash, which is for most purposes completely compatible with Bash but which can cause problems occasionally if you don’t know you are running Dash. In these blog posts we will be using Bash, mainly because it is probably the most common shell but also because it isn’t too hard to use the other shells once you have learned one of the others. So what we want to do now is make sure we are running the Bash shell. One quick and dirty way of checking is to look at the prompt — in Bash it should be `$’, in csh, and its variants like tcsh, it will be `%’. But this is configurable and may not always be the case so to make absolutely sure we will issue our first command. The command line is case sensitive, for example `Echo’ is different from `echo’, so at your prompt type the following command making sure you follow exactly the case of the various letters:

$ echo $SHELL

Now press ‘Return’ and you should see the following:

$ echo $SHELL
/bin/bash
$

What has happened here is that you have typed in a command, the shell has interpreted and executed the command, printed out the output and presented you with a new prompt for your next command. With the command `echo $SHELL’ you have asked the shell to print (echo) the contents of the variable $SHELL. Don’t worry about what a variable is, we will cover that in later posts, for now just understand that $SHELL contains some text corresponding to the shell that is currently running. So if you ask the shell to print $SHELL you will soon know what flavour of shell you are using. If you are running Bash then this variable contains the path (once again we will cover what a `path’ is soon) of the Bash executable. If you see something else, for example ‘/bin/tcsh’, you aren’t running Bash but something else. If you are on Ubuntu you may get something like ‘/bin/dash’ but, as mentioned above, this is fine as this shell is almost completely compatible with Bash. If you see ‘/bin/sh’, ‘/bin/csh’ or ‘/bin/tcsh’ then you need to get bash running. You can do this by typing the following at your prompt and press return.

$ bash

If Bash is available on your system then the first shell would have executed the Bash program which will now be sitting there waiting for you to interact with it. Also note that your prompt may have changed as well, probably from ‘%’ to `$’. We can now check if bash is running by performing the same command as before:

$ echo $SHELL
/bin/bash
$

Hopefully you should now have ‘bin/bash’ as the output of this command. As mentioned this command is printing out the contents of the variable $SHELL, which contains the path of the shell executable. On Unix systems the /path is the location in the file system of executable files. It is worth getting your head around paths early. Essentially a path is just a list of directories, or folders if you are used to the graphical interface, that leads to the executable file. In Unix path names are separated by the symbol `/’. You may be familiar with the Windows convention of separating paths with the backslash, `\’, but it is easy to remember the Unix convention by noticing that it is the same delimiter is used in website urls. This is no accident by the way, the internet was born on Unix machines, and mostly still runs on Unix machines, and the delimiters used in urls came from the Unix way of specifying file locations — a website url is just a computer name and a path to a file on that machine. So, getting back to our example, when we printed $SHELL the output is telling us that in the directory ‘/bin’ there is a program called ‘bash’ which is the program we are using as a shell. And this brings us to our next topic — the filesystem.

Learn More

In my experience programmers are control freaks. We like things just so. Reflecting this, almost everything is configurable on a Unix system, including the prompt. In this small section of text you can put just about any information that you think is useful, including the number of files in the current directory, uptime, laptop power, new mail message, stopped jobs count, the time, the date or you can write a script that retrieves any information you want, from the web or from your system, and present it in the prompt. You can even colorise your prompt. Extensive guides exist on the web for customising your prompt but it is good to keep a few things in mind. I find a long prompt distracting, if you have War and Peace in your prompt it is going to be hard spotting your commands, particularly when scrolling back to look at what you have done. Personally I find the current directory a useful addition to the prompt as you can tell at a glance where you are in the file system, and, if you are working remotely on a number of systems and have a number of terminals open, your username and hostname are useful bits of information as you can tell at a glance which system your on. Having said that you are free to do whatever the hell you like — its your prompt. For some useful guides to hacking your prompt check out the links below:

The File System

The first thing to keep in mind is that the file system is the same regardless of whether you on the command line or in a graphical interface. So if you initially get lost you can easily open up a graphical window (Finder in the Mac, or whatever window manager your using in Linux) and click around to find out where you are in a more familiar manner. Having said that keep in mind that on Windows and OS X the file system explorers do hide a lot of detail from you. The file system in a Unix system, and most other systems as well, is a hierarchal structure consisting of nested directories starting with the ‘root’ directory denoted by ‘/’. The root directory contains a number of different directories, which themselves contain files and directories which contain other files and directories and so on. Although there are efforts to standardise the structure of Unix file systems, in reality there can be a great deal of variation in what directories exist, where they are located and what they contain. However, in general, there is a kind of overall pattern that you can expect to see in the typical Unix system, and this is set out in the figure below. This shows a typical Linux filesystem and, as an example of a slightly different file system, the OSX system. Apple, as usual, has to be different and includes capital letters in directory names, I find this quite annoying as you then need to make extra keystrokes, ie. shift, to reference these directories. Apart from this, however, there are probably more similarities between the Linux filesystem and the OSX filesystem then there are differences (ignoring a number of technical details such as .DStore files etc that need not concern us at this stage).

The unix file system.

The unix file system.

Included in this figure are the type of files that you can usually expect to find in particular directories. Things like ‘bin’ and ‘sbin’ tend to hold important system executables, and log files are generally found in the ‘var’ subdirectory (see this here for a more in depth explanation of the unix filesystem). The most important for the typical user is their home directory, which is found in the ‘home’ subdirectory in Linux and the ‘Users’ subdirectory in OSX. These directories hold the home directories which generally are named after the login name of the user. For example on my Mac my home directory is ‘Users/jason’ — jason being my login name (and coincidentally my actual name). Your home directory is (generally) the directory you land in when you first log onto a Unix system and is the directory of which the contents of which are directly under your control. In any directory above your home directory you are unlikely to have write permissions, which means you can’t create or edit files. There is a good reason for this, mostly you wont be able to delete or alter any important system files or go into other users home directories and start moving stuff around. Of course if you are the admin of the machine then you will need to change these files when administering your computer but we will go through permissions and the admin user later. For the moment we will confine ourselves to our home directory.

Understanding this stuff in a theoretical sense is more difficult than seeing it in action so lets move on and start exploring the system on the command line.

Where am I?

At the moment we are blind. We don’t where we are or what is around us. So lets start finding out some basic information about our immediate environment. If you still have your terminal open (if not open it) type in the command ‘pwd’ as shown below:

$ pwd
/Users/jason/bioinformatics-org/
$

What we have done here is ask the shell what our present working directory is, or to put it simply — where are we? In my case the shell responded with the directory I am currently in, starting from the root (‘/’) directory and listing every sub-directory down through the file system until we got my present position (‘bioinformatics-org’). The command ‘pwd’ is easy to remember because the command is an acronym for ‘present working directory’ — the directory you are currently working in. As we haven’t learnt to move around yet it is likely that when you type in ‘pwd’ your home directory will be returned, ie ‘/home/[your login name]’ on Linux or ‘/Users/[your login name]’ on a Mac. Now type the following at the prompt and press return:

$ ls /
Applications     System        cores        net      tmp
Developer        User Guides   dev          opt      usr
Developer-3.2.5  Users         etc          private  var
Library          Volumes       home         sbin     sw
Network          bin           mach_kernel 
$

So if I told you that the command ‘ls’ is called ‘list’ then you can probably work out that we have asked the shell to list something. In this case we have asked the shell to list the contents of the root directory (remember that the symbol ‘/’ is the root directory). In this case it has then listed the contents of my root directory which you can compare to the figure above and see that many, but not all, of the directories listed match the directories set out for OSX in that figure. If your on a Linux system the listing will be different and more like the Linux file system described in the figure. The other thing to note is that to list the root directory we typed a command, ‘ls’, and then we provided what is called an ‘argument’ to the command (namely ‘/’). Try the following:

$ ls
ai  css  imgs index.org lesson1.org publish.el
resources
$

In this case we typed ‘ls’ but did not provide it with an argument. In this case the default action was for ‘ls’ to list the current directory. In the above example it listed the files and directories in the directory that I am using to construct this website. In your case it would have listed whatever files and directories exist in whatever directory you are currently situated (the directory returned by the ‘pwd’ command). Commands used at the command line almost always use this pattern. That is a command followed by arguments to that command. What arguments, if any, are necessary depend on the command used; in the case of ‘ls’ the argument is the directory that you want to list and if no argument is provided then the ‘ls’ command will assume you mean the current directory. Remember when we printed the value of $SHELL in section ?, we used the command ‘echo’ and provided an argument, namely $SHELL. Try using echo to print some other things, your first name, the first line of Anna Karenina or try giving it no argument and see what happens.

There is one other thing we need to know about providing commands at the command line and that is the use of options. In the case of ‘ls’ consider the following. In Unix you can cause a file to be ‘hidden’ by beginning the filename with a period. For example the file “some-text.txt” is a visible file, but, the file “.some-text.txt” is distinct from the first file and is a ‘hidden’ file. In almost all unix home directories there are a series of hidden files that provide configuration options for programs run on the system. For example bash uses hidden files for a variety of configuration purposes (more on those later) and the two most common bash hidden files are ‘.bash_profile’ and ‘.bashrc’. So try the following exercise — first just run ‘ls’ without any arguments (list the current directory):

$ ls
Applications  Dropbox            Music     Sites     
bin           elisp              Pictures  src
blast2go      Install Xcode.app  Public    tcoffee
Desktop       Library            QtSDK     VIDEO_TS    
Documents     Movies             quicklisp      
Downloads     molmol             sequences        
$

This is the listing of my home directory. Now try typing the following and pressing return.

$ ls -a
.                         .bash_profile~            .idlwave                  .slime-history.eld        Music
.#temp                    .bashrc                   .inkscape-etc             .ssh                      Pictures
..                        .bashrc.bak0              .lesshst                  .stuff                    Public
.CFUserTextEncoding       .cache                    .multiseqdb               .subversion               QtSDK
.DS_Store                 .calibre_calibre GUI.lock .multiseqrc               .t_coffee                 Sites
.MacOSX                   .config                   .ncbirc                   .viminfo                  VIDEO_TS
.RData                    .cups                     .org-timestamps           Applications              bin
.Rapp.history             .cytoscape                .profile                  Calibre Library           blast2go
.Rhistory                 .dvdcss                   .profile.bak0             Desktop                   elisp
.Trash                    .emacs                    .recently-used.xbel       Documents                 molmol
.Xauthority               .emacs.d                  .sbcl                     Downloads                 quicklisp
.Xcode                    .eshell                   .sbclrc                   Dropbox                   sequences
.adobe                    .fontconfig               .serverauth.29555         Install Xcode.app         src
.bash_history             .fonts                    .serverauth.54991         Library                   tcoffee
.bash_profile             .gnome2                   .slime
Movies
$

You can see the difference, ‘ls -a’ listed a whole heap of hidden files that were not shown when just ‘ls’ was used. The difference in the second command was that I specified the option ‘-a’. When given this option ‘ls’ will list all files, including hidden files. Of course your listings are going to be different based on which directory you are in and what files have been created but this should give you an idea (if you are not in your home directory there may be no hidden files, although ‘ls -a’ will always show to extra listings, namely ‘.’ and ‘..’ which we will look at later). Most Unix commands have options and ‘ls’ in particular has a whole bunch. To have a look at the options that can be used with ‘ls’ type the following and press return:

$ man ls

This command will bring up the manual page (see the sidebar) for ‘ls’, on my system I counted approximately 40 different options for ‘ls’, all of which affect the output of ‘ls’. You are able to use any combination of these options that makes sense, either entering all the single letter (or number) options behind one dash, or breaking them up into separate options all with a dash. Another option for ‘ls’ is the long listing option (-l), when this option is used ‘ls’ will list all the files and directories in long form, providing more information than is apparent when using the short form listing. When used in conjunction with the -a option ‘ls’ will then provide the long from listing of all the files and subdirectories in the directory. I generally compact all the options behind a single dash, so the command is ‘ls -al’ but ‘ls -a -l’ is also valid:

$ ls -al
total 104
drwxr-xr-x  12 jason  staff    408 25 Mar 15:58 .
drwxr-xr-x  59 jason  staff   2006 21 Mar 10:55 ..
-rw-r--r--@  1 jason  staff   6148 21 Mar 20:27 .DS_Store
drwxr-xr-x  13 jason  staff    442 20 Mar 22:19 .git
drwxr-xr-x   4 jason  staff    136 23 Mar 12:12 ai
drwxr-xr-x   3 jason  staff    102 23 Mar 16:15 css
drwxr-xr-x   4 jason  staff    136 23 Mar 12:13 imgs
-rw-r--r--   1 jason  staff   3202 23 Mar 16:13 index.org
-rw-r--r--   1 jason  staff  32157 25 Mar 15:57 lesson1.org
-rw-r--r--   1 jason  staff   1519 25 Mar 11:18 publish.el
drwxr-xr-x@ 14 jason  staff    476 23 Mar 17:10 resources

So here I have listed all files and directories in my website development directory using the command ‘ls -al’. The options to a command always come before the arguments. So if I wanted to list in long form all files in my root directory I would use the ‘-al’ option and would specify the root directory by finishing the command with ‘/’. Just like below:

$ ls -al /
total 30485
drwxr-xr-x  34 root  wheel      1224 26 Feb 09:18 .
drwxr-xr-x  34 root  wheel      1224 26 Feb 09:18 ..
-rw-rw-r--   1 root  admin     15364 16 Sep  2011 .DS_Store
d--x--x--x   7 root  wheel       238 11 Dec 09:00 .DocumentRevisions-V100
drwx------   5 root  admin       170 20 Aug  2011 .Spotlight-V100
d-wx-wx-wt   2 root  wheel        68 20 Aug  2011 .Trashes
----------   1 root  admin         0 19 Jun  2011 .file
drwx------  81 root  wheel      2754 25 Mar 12:30 .fseventsd
drwxr-xr-x@  2 root  wheel        68 21 Jun  2011 .vol
drwxrwxr-x+ 83 root  admin      2822  6 Mar 19:36 Applications
drwxrwxr-x  15 root  admin       510 20 Sep  2011 Developer
drwxrwxr-x@ 16 root  admin       544 31 Jul  2011 Developer-3.2.5
drwxr-xr-x+ 67 root  wheel      2278 26 Feb 09:18 Library
drwxr-xr-x@  2 root  wheel        68 19 Jun  2011 Network
drwxr-xr-x+  4 root  wheel       136 26 Feb 09:20 System
lrwxr-xr-x   1 root  admin        60  4 Mar  2011 User Guides And Information -> /...
drwxr-xr-x   5 root  admin       170 20 Aug  2011 Users
drwxrwxrwt@  3 root  admin       102 25 Mar 10:41 Volumes
drwxr-xr-x@ 39 root  wheel      1326 26 Feb 09:18 bin
drwxrwxr-t@  2 root  admin        68 19 Jun  2011 cores
dr-xr-xr-x   3 root  wheel      4332 19 Mar 18:38 dev
lrwxr-xr-x@  1 root  wheel        11 20 Aug  2011 etc -> private/etc
dr-xr-xr-x   2 root  wheel         1 21 Mar 20:01 home
-rw-r--r--@  1 root  wheel  15566052 13 Jan 12:49 mach_kernel
dr-xr-xr-x   2 root  wheel         1 21 Mar 20:01 net
drwxr-xr-x@  3 root  admin       102 20 Sep  2011 opt
drwxr-xr-x@  6 root  wheel       204 20 Aug  2011 private
drwxr-xr-x@ 62 root  wheel      2108 26 Feb 09:18 sbin
drwxr-xr-x  11 root  wheel       374  8 Jan 12:04 sw
lrwxr-xr-x@  1 root  wheel        11 20 Aug  2011 tmp -> private/tmp
drwxr-xr-x@ 15 root  wheel       510 20 Sep  2011 usr
lrwxr-xr-x@  1 root  wheel        11 20 Aug  2011 var -> private/var

When listing in long form there is a tremendous amount of extra information supplied, and this information is of great use. We will not go through this information just yet but we will definitely come back to this when we are discussing file permissions — so keep it in the back of your mind. But, for the moment, the important things to take from this discussion are:

  1. that ‘pwd’ returns your current position
    in the file system;
  2. that ‘ls’ will list the files and subdirectories in the directory
    provided as an argument or, if no argument is given, in the
    current directory; and
  3. Unix command line commands are almost all constructed in the
    following way:
The unix command structure.

The unix command structure.

Man is your friend

Unix systems come with an enormous amount of documentation about the programs that can be run at the command line. The system is known as Manual Pages and they are accessed using the ‘man’ command. If you are not sure how a command works, or what options are available, then typing ‘man’ at the prompt with an argument corresponding to the command your interested in will bring up the manual page for that command. So if you want to look up the man page for the ‘echo’ command type ‘man echo’ at the prompt and push enter. The man pages can be navigated using the arrow keys or the space bar to move down a page at a time. You can search through the man page by pushing the ‘/’ key and typing a keyword of interest. For help, use ‘h’ and to quit use ‘q’. The man pages for various commands can be variable in quality and in clearness, many are quite technical but as a point of first call they are invaluable. If you are not sure of the name of a command you can search all the man pages using the program ‘apropos’, at the prompt simply type ‘apropos’ and a key word and it will return all the matches for the keyword (note if there is more than one page you will be put into a pager in which you move forward using the space bar and quit by pushing ‘q’). For example if you want to delete some directories but don’t know which command to use, ‘apropos “remove directories”‘ (including the double quotes) will return the command ‘rmdir’, ‘man’ can then be used to learn more about the command (ie ‘man rmdir’). Apropos seems to have a pretty rudimentary keyword matching algorithm and sometimes you need to play around a bit to avoid getting hundreds of results, or no results, but it is super useful once you have worked out its idiosyncrasies.

Creating directories and moving around

So now that we know how to find out where we are its time to find out how to move around. The only command you really need to know for moving around is ‘cd’ – or change directory. But there are some tricks that can make life easier. Like the other commands we’ve learned ‘cd’ works by taking an argument, consisting of the absolute or relative path of the place you want to move to. If you don’t provide an argument than ‘cd’ will take you to your home directory. To illustrate cd, and explain the difference between relative and absolute paths, we will create some subdirectories. To do this we will use the command ‘mkdir’ which, as you would expect, creates a directory. We are going to create a directory in our home directory, so we need to make sure we are in our home directory. To do this we can use ‘cd’ with no arguments, once we have issued this command we can use ‘pwd’ to prove to ourselves that we have moved (if you have your direcory displayed in your prompt then this will change as well):

$ cd
$ pwd
/Users/jason

Now that we are in our home directory lets make a directory that we can use for all the exercises in this guide and lets call it ‘programming-4-biologists’. The command for creating new directories, ‘mkdir’, like all other Unix commands takes an argument, in this case the path and name of the directory that you want to create. This command does not have a default setting, if you do not give an argument you will get an error — try it — on my system nothing happens and some information about how to use ‘mkdir’ is printed to the terminal to remind me how to use the command. When you think about it this is sensible behaviour, you can’t create a directory without knowing what it is going to be called. So lets create the directory and then list the directory to see how :

$ mkdir programming-4-biologists
$ ls
Applications             VirtualBox VMs
Calibre Library          bin
Desktop                  blast2go
Documents                default_repository
Downloads                elisp
Dropbox                  gsea_home
GenMAPP-CS-Data          molmol
Library                  programming-4-biologists
Movies                   quicklisp
Music                    sequences
Pictures                 src
Public                   tcoffee
QtSDK                    test.txt
Sites
$

Well done, your first directory! Before we move into this new directory it is a good time to discuss naming conventions in Unix. Like any other OS you can call your directories and files whatever you want to call them, but … A number of conventions, I suppose, have grown up in Unix, based on efficiency and ease of use. On the command line spaces need to be escaped, that is they need to be proceeded by a ‘\’ character. If you name a file or a directory ‘hi there’ it will work perfectly well, but every time you refer to that directory on the command line you will need to write it as ‘hi\ there’. This means more work for you and, as your knowledge of Unix increases and you start writing scripts, the space can lead to some difficult situations when processing files in scripts. It is best to not have spaces if you are dealing with files on the command line, as we did above instead of spaces we substituted a dash, ‘-‘, or some use the underscore. Either works just as well as the other, although the underscore requires the shift key which is a little bit of a pain. Likewise, I, and other Unix users, tend to not use capitals in file or directory names, basically because I’m to lazy to reach for the shift key. Whether you follow this convention or not is up to you – Apple doesn’t.

Now we can move into our freshly minted directory. So we want to use ‘cd’ with an argument corresponding to the directory we want to move into. An important concept to grasp here is the difference between and absolute and relative path and we can use either as the argument to ‘cd’. As discussed the path is just a forward-slash separated list of directories that lead to a specific point within the file system, for example the path of my home directory is ‘/Users/jason’. The difference between a relative and absolute path is simply the starting point of the path. A relative path begins your location in the file system at the time that the path is constructed. An absolute path name begins at the root directory, ‘/’, and lists all the directories between the root directory and the target. In the context of the example we are working on now the relative path of our new directory, ‘programming-4-biologists’, is just that ‘programming-4-biologists’. This is because we are sitting in the same directory, our home directory, as the new directory. The absolute file path of the same directory is, beginning from the root directory, ‘/’, ‘/Users/jason/programming-4-biologists’. As you can tell from the names the absolute path is always the same, a file or directory can only have one absolute position. The relative path is context dependent, it depends on where you are, if you move then the relative path of a file or directory will change. Both of these paths have their uses, for example if you are distributing a web site then you would use relative file names to refer to all files and directories in the web site directory tree as you can then copy it to any system and the paths will stay the same. Absolute pathnames, on the other hand, are useful whenever you want to specifically refer to the absolute position of a file or directory in the file system.

That is a lot of words for a prelude to a simple command, one you will perform a million times, so lets just go ahead and move into the ‘programming-4-biologists’ directory:

$ cd programming-4-biologists
$ pwd
/Users/jason/programming-4-biologists
$

The ‘cd’ command gives no output so to make sure lets also do a quick ‘pwd’ to print out the absolute path of our current position, which, as expected, is the ‘programming-4-biologists’ directory. Once we are in the directory what happens if we want to move out again? We could ‘cd /Users/jason’, that is use the absolute path of our home directory as an argument to ‘cd’. Alternatively, as I mentioned some time ago if whenever you list hidden files in a directory there will always be two odd looking files, ‘.’ and ‘..’. Try it — lets ‘ls -a’ (list all files including hidden files remember) in our otherwise empty directory:

$ ls -a
.  ..
$

These two entries a shorthand ‘files’ for the current directory (‘.’) and the parent directory (‘..’). Effectively the ‘..’ entry is a reference to the directory immediately above the current directory, in this case our home directory, it is thus a relative path referring to the parent directory. This can also be passed to ‘cd’ as an argument. So if we want to move back up out of a directory we can issue the command ‘cd ..’:

$ cd ..
$ pwd
/Users/jason
$

We have moved back into our home directory. We can therefore use this to issue relative path names to ‘cd’ whenever we are moving around the file system. For example if we are in the ‘programming-4-biologists’ directory and we wanted to move to another directory in our home directory we could just issue the command ‘cd ../some-other-directory-in-our-home-directory’. Although it doesn’t really happen you can think of it as moving back up into the home directory (the ‘..’ bit) and then moving into the other directory. Any command that accepts a path as an argument can use this relative path name syntax. If you are in your home directory (type ‘cd’ and press enter at the prompt to make sure you are in your home directory) you can type ‘ls ..’ to see the other home directories that are on the system, that is the contents of ‘/Users’ on a Mac or ‘/home’ on a linux box. The listing for that command is below, but as I’m on a laptop I am the only account on the system apart from a Shared directory:

$ cd
$ ls ..
Shared jason
$

Wrapping up

Now might be a good time to stop this lesson. We have covered a lot of stuff, we can now start a terminal, list files, create directories and move around the file system. We still cannot do anything that useful but the stuff we have learnt here is the basics of what you need to know to effectively use the command line. In the next lesson we will learn some commands that will let us do some real bioinformatics tasks and after that we will start programming in Python. Try the exercises below and get on the wiki if your having problems.

Exercises

  1. Starting off:
    • Start a terminal window;
    • Exit from the terminal (hint ‘exit’ and use ‘man exit’ first to find
      out what you are going to do);
    • Restart the terminal;
    • Enter the following commands in turn, use the ‘man’ command to
      find out what they do and what options exist to modify their
      output:

      • date
      • whooami (read the man page for this utility carefully and then
        use ‘man’ to learn about the alternative program if one is suggested.)
      • hostname
      • uname
      • uptime
  2. Navigation and files
    • Navigate to your home directory;
    • Confirm that you are in your home directory;
    • Make a new directory called ‘tmp’;
    • Move into the new directory;
    • Make a new empty file called ‘test’ (we haven’t covered this yet
      but the command ‘touch’ might be what you need, as always use
      ‘man’ to find out what it does.);
    • List the directory and confirm your file is there;
    • Extra credit:
      • see if you can delete the file ‘test’
      • see if you can delete the directory ‘tmp’
    • Extra, extra credit:
      • see if you can get text into a file using ‘echo’ and the
        redirection operators;
      • see if the text got into the file by printing the file contents
        to the screen (hint: a feline command)

Comments

comments

Powered by Facebook Comments

Comments are closed.