How to Use Linux in 351

This is a quick little tutorial on how to get yourself up and running on Linux. A lot of the material before “Finding your way around the shell” is geared toward using CSE department machines (in the basement labs or via accessing a server), both of which require a CSE account (typically only for CSE majors). If you are using the CSE virtual machine, available to everyone in CSE 351, then read just “Shell on Linux” and then from “Finding your way around the shell” onward.

Getting a Shell

The shell is the bread and butter of linux. I know, graphical things are nice, but the linux shell brings you a lot of power with not very many key presses. As most companies in the industry will require you to use the linux shell at some point, it's better to just get used to it. You may be asked about it in an interview.

Shell on Windows

Windows' default command line interface is Command Prompt, which we won't be using in 351. Instead, we will use an SSH client to connect to attu, which has a linux shell.

An SSH client lets you interact with another computer over the Internet. SSH clients usually look old school, like something they would have used in the 80s. Why do we still use them? They allow you to interact with a program on another computer called a shell. You can also run graphical programs on those computers through your SSH client, but that's for another time.

Shell on Mac OS X

The Mac OS X Terminal behaves very similarly to most linux shells. As a result, most of the commands on Terminal will be the same as those from a linux shell. However, to use the linux shell commands for 351, we will connect to attu.

Shell on Linux

The linux machines in the department come pre-installed with all of the tools you'll need to work on the 351 projects. In addition, things are set up so that your files are in the exact same places as on attu. You won't need to do any special setup on Linux. This will also work for your home Linux machine/VM, but you can also connect to attu to make sure you have all the tools needed.

Just click Applications at the top, mouse to Accessories, and click Terminal.

Using attu

Attu is a powerful computer sitting in the CSE building that is ready to run your work, except that it has no screen. It runs linux, and can only be accessed over the network. Anybody with a CSE account can use attu. Attu has all the commands that you will need in the 351 labs, and is built to be fast, so more often than not it's most convenient to run lab programs on attu.

Accessing attu from Windows

The best Windows option to connect to attu is the lightweight SSH client PuTTY. Directly downloading putty.exe will suffice for our purposes. Here's how to get PuTTY up and running.

Accessing attu from OS X or Linux (not a lab machine)

Occasionally, you will need to access attu from your personal linux machine. Accessing attu remotely is the same as accessing attu on your Mac OS X computer or home linux computer. First, open a Terminal:

Now that you have a terminal up, type:

ssh <your-csenetid>

Press enter. If prompted about a server key, type yes and press Enter. When prompted, enter your Kerberos password and push Enter. Like PuTTY, it won't look like you're typing. This is done on purpose :)

Finding your way around the shell

How files and folders work on Linux

First off, folders are a fancy word that Microsoft invented to make comptuers seem more human. While folders are great, they're called directories on linux.

The first thing that most new users shifting from Windows will find confusing is navigating the Linux filesystem. The Linux filesystem does things a lot more differently than the Windows filesystem.

The Root Directory (/)

For starters, there is only a single hierarchal directory structure. Everything starts from the root directory, represented by '/', and then expands into sub-directories. Where DOS/Windows had various drives (C:, D:, etc) and then directories under those partitions, Linux places all the drives under the root directory by 'mounting' them under specific directories. The closest parallel to the root directory in Windows would probably be C:.

Another point likely to confuse newbies is the use of the frontslash '/' instead of the backslash '\' as in DOS/Windows. So c:\windows\system would be /c/windows/system. Well, Linux is not going against convention here. Unix has been around a lot longer than Windows and was the standard a lot before Windows was. Rather, DOS took the different path, using '/' for command-line options and '\' as the directory separator.

Your Home Directory (~)

To keep people from stepping on everybody's toes, everybody has one folder or directory that they can write and make changes to. This is called your "home directory". On any unix system, you can refer to the home directory with a tilde, so a folder called frogs inside of your home directory would have a path like:


When you run a command, your shell will replace ~ with the path to your home directory. If you want to know what that is or how to manipulate the shell, read the next section on basic unix commands.

Other Important Directories (. and ..)

The shell also allows you to directly reference directories relative to your current working directory. '.' represents the current working directory. '..' refers to the direct parent of the current working directory. Every additional '.' refers to the directory one level higher.

This can be pretty handy in working your way around your directory structure. For example, if you are in the folder lab1, a sibling directory lab2 would be referred to as:


Basic Unix commands

To move around through the directory structure in your terminal window, you'll need to know a few basic Unix commands. Note that you always start in your home directory when you open a terminal.To get help on some command, say you want to know how to use ls, type "man ls" and you will get the manual pages for that command. (Alternatively, you can use "info" in the same way.)

Command Function Example Explanation Notes
mkdir Creates a new directory with the given name in the current working directory. mkdir lab1 This will create a new directory called "lab1".
ls Lists all directories and files in the current directory. ls -A This will list all sub-directories and files. The -A flag means that hidden directories and files will also be printed to the console. Check the manual page for ls to find out various flags to show directories and files in different forms.
cd Navigates to the specified directory, given its relative path. cd lab1 This will navigate to the lab1 directory inside the current directory. This is a common place where . and .. are used. Also, to use a directory's absolute path, start the directory name with either / or ~. For example:
cd ~/cse351/lab2
pwd Prints the current working directory path. pwd This will print the current working directory's absolute path to the console.
exit Exits the console, or logs out of the current SSH session. exit This will terminate the current terminal window. If you are SSH'd into attu, this will terminate your session.

Here is a sample execution of some Unix commands. The attu% is just the prompt telling you that you're logged into attu.

attu% mkdir mydir
attu% ls
mail  mydir
attu% cd mydir
attu% pwd
attu4% exit

These are just the very minimum basics, of course. CSE 391 covers the Linux system in further depth.

Changing your shell

The shell is the program where you type in commands. There are different shell programs, which are all similar but have different rules and features. For sake of uniformity, we will use a shell called "bash" but it's likely that your account is set-up such that when you create an terminal the shell it uses is "csh". You can change this for the time being or once and for all. We strongly recommend the latter, but we'll explain the former first to help you understand what is going on.

For the time being: Type

attu4% bash
Now you may have a different looking prompt (such as bash-3.00$). Otherwise at this point you will not notice any differences, but that's only because you don't know any differences between bash and csh. When you type
bash-3.00$ exit
you'll be back to the shell you were running when you typed bash. That is, you started running a different shell and when you exited, you just went back to the outer one.

Once and for all: You could type bash every time you create an terminal, but that's a pain and you could get confused if you forget. So you can tell the operating system once and for all that for your account, the "first shell" for every terminal should be bash. From any prompt, type:

chsh -s /bin/bash
You are running the "change shell" program and specifying that your new shell can be found at /bin/bash. It's almost that simple: As a final note, if your shell already is bash, chsh will just say "Shell not changed."

Editing Files

First thing's first: What I say here is not final. There is a ton of debate about this.

CSE 351 Text Editing

For this course, you can use something as simple as Notepad. However, we strongly recommend something better. Here is a list of things, by OS, that we recommend:

A word about working at home

If you are working at home and not using the CSE Virtual Machine, then you'll notice that you need to have your files on another machine such as attu in order to compile and test your work. You can edit with nano, pico, emacs, or vi on attu, just by typing those commands and pressing Enter. However, depending on the latency between your computer and attu (i.e., the time that goes by before you press a key, attu receive the key, and tells your computer what to print on the screen in response), this might not be practical.

A better way is to download the lab to your hard drive, then use a Windows text editor to make changes. After that, you'll need a program called WinSCP to copy your changes to attu and compile them.

An even better way is to use the CSE Virtual Machine instead.


Viewing all of the output when you run commands

When you run a command like btest on attu, you may see something like the following:

  Gives 1942614435[0x73c9f1a3].  Should be 204869213[0xc360e5d]
... 9 total errors for function abs
Test abs score: 0.00/4.00
Test addOK(-2147483648[0x80000000],-2147483648[0x80000000]) failed.
  Gives -2147483648[0x80000000].  Should be 0[0x0]
Test addOK(-2147483648[0x80000000],2147483647[0x7fffffff]) failed.
  Gives -2147483648[0x80000000].  Should be 1[0x1]
Test addOK(-2147483648[0x80000000],-3[0xfffffffd]) failed.
  Gives -2147483648[0x80000000].  Should be 0[0x0]
Test addOK(-2147483648[0x80000000],811666840[0x30610d98]) failed.
  Gives -2147483648[0x80000000].  Should be 1[0x1]
Test addOK(-2147483648[0x80000000],-2147483647[0x80000001]) failed.
  Gives -2147483648[0x80000000].  Should be 0[0x0]
... 321 total errors for function addOK
Test addOK score: 0.00/3.00
Overall correctness score: 14.00/36.00
1541 errors encountered.

What happened to the first part of it? Answer: it scrolled up past the top of your terminal. You'll have to tell attu you want to save all of that output somewhere, like this:

./btest >feedback_filename

If you run btest (or any command) like this, linux will save its output in the file called "feedback_filename" for you to view later in your favorite text editor (see above section).

Alternatively, if you just want to see the output once, try it this way:

./btest | less

You can then use the up/down arrow keys to move around your output in a quick n dirty fashion. Use the 'q' key to quit. Be aware: Once you quit, the output is gone for good! But, luckily for you, you can just re-run btest to get it back. You can also use less to view the output from your saved file, like less feedback_filename.

Make clean and corrupt builds

Not everything is perfect, sadly :(. One of those is our build system. Though it is unlikely, the rule of thumb when running the make command is:
If something really doesn't look like it's running right, do a make clean, then a make and try it again.

To save time, make and gcc will save some of the computation required to build your software. However, at times, this can become corrupt and interfere with changes you're making.

Written by Andrew Reusch
and edited by Sarang Joshi
With help from the 303 documentation and the web.