Lab 1: Getting Started with Linux The Extremely Illustrated Version
Graham Northup
Objectives
● Be familiar with the use of the terminal on Linux systems. ● Know what Linux resources on campus are available for your use.
● Understand how to submit assignments for this course.
Getting a Terminal
Getting a Terminal
Getting a Terminal
Getting a Terminal
Seeing Stuff
Making Files
Moving Around
Moving Back
Editing Files
● Linux systems are usually replete with a number of text editors. ● Various users tend to have their own preferences (Google “editor war”)
● I will be teaching Vim, the vi-improved editor, but you are free to edit your assignments with whatever you feel comfortable with, including, e.g., CodeBlocks, Notepad++, etc.
Starting Vim
Vim
Entering “Insert Mode”
Typing Text
Exiting “Insert Mode”
Exiting Vim
Back to the Terminal
Displaying File Contents
Copying Files
Moving Files
Removing Files
Where you are
● For now, you have been working on the local host, which is probably one of the ITL machines. ● Work saved on these machines is accessible by anyone else who might sit there!
● For assignments, the University has dedicated servers which also provide a Linux environment, one of which is Odin.
Accessing Servers
Your Clarkson Full name of the server username
Accessing Servers
Accessing Servers
Accessing Servers
Where you are
Servers
Local host (e.g., ITL machine) Network / Internet
Accessing Servers
Done on server
Exiting Servers
Exiting Servers
Done on server
Done on local host
Copying Files to Servers
Your Server’s full name Location to Clarkson copy to username
Copying Files to Servers
Copying Files to Servers
Copying Files to Servers
Accessing Servers in Windows
putty www.putty.org
Copying Files to Servers in Windows
WinSCP winscp.net
Task 1
Create three files in your home directory (~) on Odin (odin.cslabs.clarkson.edu): ● touch one file; ● Create one file by editing it (e.g., with vim); ● Copy one file with scp. (Filenames nor contents are important.) Existence of these files will be checked and graded by the morning of Tuesday, September 6.
Lab 1: Getting Started with Linux The Extremely Illustrated Version
Graham Northup
In today’s lab, we’ll be getting started with Linux and, perhaps more importantly, it’s terminal. As we will be using systems running Linux for many of our assignments in this class, it’s important to get a fair grasp of this early.
Objectives
● Be familiar with the use of the terminal on Linux systems. ● Know what Linux resources on campus are available for your use. ● Understand how to submit assignments for this course.
I hope that you’ll be able to leave with three things today: an understanding of how to use the terminal and issue commands within it, knowledge about the resources you have on campus for both use and help with the Linux systems you will be dealing with, and, of course, an understanding of how to submit assignments for this course.
Getting a Terminal
Without further ado, then, let’s get started! You’re probably sitting in front of a Linux machine (in the ITL), so long as no one booted into Windows. (If someone did, just restart it.) These machines have a nice, fancy graphical user interface that you’re probably quite familiar with; however, that’s mostly because they have the benefit of monitors. When we’re dealing with servers later, which don’t, dealing with a terminal will be far more useful. To start, let’s find a terminal on the machine in front of you; what I’ve found to be the most robust way to start one is with this terminal emulator entry in the application launcher menu down in the bottom left of your display—where the “Start Menu” would be on Windows...
Getting a Terminal
...for the impatient, there’s a quick-launch for the terminal emulator next to the launcher, too, but it’s been known to disappear...
Getting a Terminal
...as has the desktop icon, which tends to get moved around by bored students :)
Getting a Terminal
If all went well, you should be looking at a window that appears like this; this is your terminal! Many of them will have green on black (though some hapless students also like to change the colorscheme, font size, etc.), but the important part is the text that you should see in the top-left; this is your prompt, the system’s way of asking you what you would like to do. It contains three parts, separated by an at-sign (@) and a colon (:), and ended with a dollar sign ($), whose meaning we will go over later. Be familiar with entering text into this line; it works just like a “normal” text editor; you can insert characters, backspace, move left and right with the arrow keys, and so forth. You’ll note that the cursor is a block; if you’re more familiar with the cursor that goes between characters, just pretend it’s on the left edge of that block.
Seeing Stuff
It’s time to run our first command! Type “ls” and press enter. (ls is short for “list”; programmers like to abbreviate everything :) If all went well, you should see something like this, at least in the ITL. The text represents objects—files and directories (or “folders”)--that are in your working directory. In general, all of the commands I’m going to give you that work with files do so in your working directory, which is indicated by the last part of the prompt—after the colon (:). Right now, it reads “tilde” (~), which means your home directory. Whenever you start a session, you usually start there. Not all terminals have color, and not all commands support it, but in this case, both do—and ls has colored the directories blue for you. All of these are directories, so what does a file look like?
Making Files
The easiest way to create a file is probably the touch command. This is the first one we’ll be using which takes an argument—something that tells touch about what it should do. In this case, it takes one argument: the name of the file it should create. Separate the command and argument with one or more spaces; the argument (a file name) should not contain spaces. Press Enter when you’ve satisfactorily named your new file; I called it “filename” in these examples, but you can use your imagination. Now we can see what color a regular file is on this terminal: plain! It shows up as green because that is the default text color.
Moving Around
When working (creating files, editing files, etc.), it is convenient to change your working directory so that you can separate your work into different places. Conceptually, this is like creating many folders to group your files into, and your terminal (really, shell) is in only one of these folders at a time. To change working directories, use the command cd (“change directory”); it takes just one argument, the name of an existing directory to change into. I chose the “itl_chorus” directory in these examples because I knew it contained a lot of files. Here, you can see the output of “ls” in that directory; many Unix veterans will almost compulsively “ls” whenever they change directories, make directories, make files, etc.; just to see what happened.
Moving Back
We know that we can move into a subdirectory by naming it, but suppose that we want to move back out—Linux provides for us a very special directory name for this purpose, called “..” (two dots). Wherever you are, it always means “the parent directory” or “one directory up”. By cd’ing “into” that directory, you can move back up again. You can do this indefinitely, and even explore the whole filesystem this way; if you ever get lost, just run cd without arguments, and it will return you back home (“~”).
Editing Files
● Linux systems are usually replete with a number of text editors. ● Various users tend to have their own preferences (Google “editor war”) ● I will be teaching Vim, the vi-improved editor, but you are free to edit your assignments with whatever you feel comfortable with, including, e.g., CodeBlocks, Notepad++, etc.
We learned how to create files in the terminal, but it’s also arguably important to know how to edit them. For this course, I don’t expect you to create files in exactly this way—you are free to use whatever editor(s) you are comfortable with—but, in keeping with the theme of learning how to use the terminal, I will be teaching how to use an old, venerable text editor: Vim. There are a few other text editors that are easily used from the terminal, too (including Emacs, Jeanna’s favorite :), but I’m covering this one just because I think it is more streamlined and I’m much more familiar with it.
Starting Vim
Vim’s proper name is in Title Case, but, like most Linux commands, the command is given in all lowercase. Vim takes one argument—the name of the file you would like to edit (it need not exist, and, indeed, Vim will create it for you if it doesn’t).
Vim
Once you’re in Vim, you’ll notice your prompt is gone! Vim has essentially taken over your terminal in order to display the file to you and let you edit it. Right now, of course, this file is empty, so there’s nothing to display. Nonetheless, you will see some information along the bottom, and some tildes (~) along the side (blank lines past the end of the file), and the number 1 before your cursor—that’s the line number of the file you’re in, the very first. A big caveat about Vim is that it is modal; what your keypresses do vary between what mode it is in. We’re in normal mode right now, which, unlike many other text editors, is not for typing (it is used for very powerful editing, though). To actually type in this file, we want to get into insert mode...
Entering “Insert Mode”
...which can be done by tapping “I” or “i” on your keyboard (without shift—I will always indicate whether or not you need to hold shift!). If you did this right, Vim will tell you, in the bottom right part of your terminal, that you are in insert mode (with the word “INSERT”).
Typing Text
Now that you’re in insert mode, you can type text mostly normally; the arrow keys will move your cursor around, enter creates a new line, etc. . This should feel at least passingly familiar.
Exiting “Insert Mode”
Now, once we’re done typing text, we’d like to exit Vim and save our file. Naturally, since this has nothing to do with inserting text, we don’t do this from insert mode. Instead, tap “Esc” on your keyboard to “escape” insert mode and enter normal mode again. (Tapping “Esc” at least a couple times will guarantee that you always end up back in normal mode.) You will note that the word “INSERT” disappears from the bottom left.
Exiting Vim
From normal mode, we can now exit Vim! Press both “Shift” and “;” (in other words, type a colon “:”), and you should see a colon appear in the bottom right, along with your cursor. This is command mode, where we can issue a number of other powerful commands to Vim. The one we want right now is “wq”, short for “write (save) and quit”. There is also “q!” (quit without saving changes) and just “w” (save now, but keep editing). When you’ve entered the command you want, press Enter, and Vim should exit...
Back to the Terminal
...which should bring you back to the terminal (shell) you’re used to, complete with a prompt asking you what to do next.
Displaying File Contents
In this case, we want to make sure we actually wrote something to the file; we’ll be using the command cat (“concatenate”, because it can actually display multiple files) for that. Give it as an argument the name of a file, and it will write its contents out to your terminal. If all went well during your Vim session, you should see exactly what you typed into it (without, e.g., line numbers).
Copying Files
Finally, we’ll cover operations that are not unlike using the “clipboard” in other file managers. This command is cp, or “copy”, and is the first we’ve covered so far that takes two arguments; the first is an existing file, and the second is a name to copy it to (or directory to copy it into; more on that later). After the copy performed in this example, you can see that the second name now exists, is a regular file, and (via cat) has the same contents as the original file. You can copy a file as many times as you want (up to how much disk space you have :).
Moving Files
The equivalent to the “cut and paste” is a command called mv (“move”), which also takes two arguments. Unlike cp, mv will not retain the original file, but otherwise behaves exactly the same. (Due to implementation details, it’s also much faster than cp for moving large files within the same disk.) When given a new filename, mv acts just like the “rename” function of some other file managers; in this example, though, I take advantage of specifying a target directory for the second argument, and you can see afterward that the file is moved (with the same base name) into the directory that I specified, and is no longer in home (~).
Removing Files
I urge you to exercise great caution before using this next command, but it is nonetheless sometimes useful; this is rm (“remove”), which takes just one argument—the file or directory you would like to remove. Unlike some other file managers that have a “Trash” or “Recycle Bin”, there is no option to change your mind and “unremove” a file later, so please make sure that you actually want to destroy the file before you do it! Chances are, if you’re not absolutely certain you don’t need a file anymore, you’re better off just moving it somewhere else instead.
Where you are
● For now, you have been working on the local host, which is probably one of the ITL machines.
● Work saved on these machines is accessible by anyone else who might sit there!
● For assignments, the University has dedicated servers which also provide a Linux environment, one of which is Odin.
For now, we’ve been working on the local host, the ITL machine in front of us (which may be re-imaged or taken down for maintenance at any time—you have been warned), but one of the beautiful things about the terminal is that it was made for connecting to other machines. In the good-ol’ days, this was frequently done by manually plugging serial cables into things, but now that we have the Internet...
Accessing Servers
Your Clarkson Full name of the server username
...we tend to use it to connect to remote hosts instead. This will be the second to last command, and I apologize that it’s a little more complex than the previous ones, but you do need to make sure you get all the details right. ssh takes just one argument, but it consists of both a username and a host name or IP address (for those of you familiar with networking), separated by an at-sign (@). For this example, I use Odin (actually, Odin’s full name, which is valid everywhere on the Internet). You should replace everything to the left of the at-sign (@), which reads “__student” in this example, with your Clarkson username. In the lab itself, we set passwords during this day. If you didn’t get the opportunity to do that yet, please contact Jeanna!
Accessing Servers
The very first time you connect to something, the two hosts exchange cryptographic secrets (ssh is the “secure shell”), and you have to indicate whether or not you’ll trust this host. If you do trust it (the entire ITL does right now), ssh will later warn you if its identity changes later, so you know whether or not you are being attacked (which is unlikely to boot :).
Accessing Servers
Either after asking you to trust the server, or if it didn’t ask you, it will now ask you for a password. The characters you type won’t appear, this is a security feature.
Accessing Servers
If you managed to get your password correct (again, ask Jeanna if this doesn’t work!), you should be greeted with a rather colorful prompt! You’ll see that some of the parts of this prompt have changed; indeed, the first part before the at-sign (@) is the username, and the part between the at-sign and colon (:) is the (abbreviated) host name. These parts of the prompt are there to explicitly tell you who you’re working as and what machine you’re on. As expected, since we just started a session, you’re in your home directory (~).
Where you are
Servers
Local host (e.g., ITL machine) Network / Internet
It’s important to note that your terminal emulator is still running on the local host, but ssh is now running in it, and—like Vim—it is intercepting your keystrokes and sending them to the remote host for processing. Essentially, you are working on the server by sending the keystrokes to it, and the server sends you back what it would like your terminal to display—and ssh is mediating the connection. Neat, right? You can nest these sessions as deep as you’d like, and even tunnel data through them—I won’t cover that in class, but ssh is a very, very powerful tool to know how to use well—much like Vim.
Accessing Servers
Done on server
Driving home the point, when we work on Odin (in this case), you’ll note that the contents of your home (~) are completely different from the ITL machine you were on. The nice thing about this is that Odin is going to remain Odin, so wherever you connect to it from, all the files on it will remain there. For this reason alone, some students like to just do their work on Odin by ssh’ing in and using, say, Vim. Others, however, like to do their work on their own machines, and copy it in, which I’ll cover in just a moment. First, we should learn how to exit our session...
Exiting Servers
...which is actually just a command called exit, no arguments! Type that, and press Enter...
Exiting Servers
Done on server
Done on local host
...and we’re back to where we started. Note that nothing on the ITL machine changed while we were working on Odin—all it was doing was forwarding keystrokes and displaying text. Aside from the ssh command in the history, there’s practically no record that our communication even happened.
Copying Files to Servers
Your Server’s full name Location to Clarkson copy to username
...now, to copy a file to Odin, we’ll need to learn about our last command: scp (“secure copy”). Like cp, it takes two arguments; unlike cp, one or both of the arguments can be a username@host combination— like what you’d pass to ssh—followed by a colon (:) and where you’d like to copy it to, relative to your home directory (~). Putting just one colon at the end of the hostname will copy to your home directory, but I like putting the tilde-slash (~/) there just to be pedantic. (Recall that specifying a directory—like home—will copy the file into that directory.)
Copying Files to Servers
If all goes well (and there is a host to connect to), it will ask you for your password, just like ssh. (It actually uses ssh internally, so it will do all sorts of other things, including bothering you about host identity :)
Copying Files to Servers
If all went well, you’ll see little file copy progress—one file per line. Now, in this example, I copied a 46 byte file, which happened almost instantly, but larger files will take correspondingly longer. Once scp is done, it will return you to a prompt on the local host—it does not start a session for you...
Copying Files to Servers
...but you can do that, as usual, by using ssh right afterward. As you can see, the file I asked to be copied in the example was indeed copied, and its contents are the same.
Accessing Servers in Windows
putty www.putty.org
I would be remiss if I didn’t note that many of you are Windows users; for the Mac users out there, note that all of the commands I covered today should work without modification in your Terminal app. Windows remains to be the only popular operating system that I know of (even amongst obscure operating systems) that doesn’t have support for this kind of terminal emulator or environment. Luckily some determined volunteers got together and wrote software that will let you do ssh from a Windows machine; the most popular by far is this imposing but powerful application called PuTTY, which shows you all the bells and whistles that ssh has. Nonetheless, the only thing you usually need to fill in is the “Host Name (or IP address)” bar on the top; the rest of the fields have sensible defaults. It will then ask for a username and password, and hopefully will just work after that :)
Copying Files to Servers in Windows
WinSCP winscp.net
Now, for the textually-challenged, there’s also a Windows application for copying files, called WinSCP, that presents a nice little dialog with local and remote filesystems displayed, allowing you to upload and download at your discretion. Again, all of this can be done with scp and sftp as well, but not without some command-line massaging :) Applications exist for this kind of graphical file management for other platforms, too; check your usual software sources to get them.
Task 1
Create three files in your home directory (~) on Odin (odin.cslabs.clarkson.edu):
● touch one file; ● Create one file by editing it (e.g., with vim);
● Copy one file with scp. (Filenames nor contents are important.) Existence of these files will be checked and graded by the morning of Tuesday, September 6.
And now we have gotten to our first task of the year! Spend some time getting familiar with using the command line and manipulating files, because at the very least, you will probably at least be copying files to Odin and moving them around, if not editing them directly there. Another benefit to using Odin for developing is that we will ultimately be using it to grade things, too, so you have access to the same tools we will use to grade your assignments (this will be a good thing shortly—when we talk about compilers). I will just be basing a grade in this course on whether or not there are three (or more :) regular files (ignore the “cs141”) in your home directory when one does “ls”. When I get a website up, that will have more details. Thanks for coming, and good luck!