This is the pre-lab preparation for the Command-line-introduction lab. This lab and pre-lab cover:
bash shellbash scriptsgit and Github as tools for managing changes to codeOne of the consistent messages we get from alums and employers is that people really need to know how to interact effectively with the command line. It's nice to use nifty GUI tools when they're available, but there are times when the only access you have to a box is via the command line. You might have to ssh to a server in the cloud, for example, edit a configuration file with a command line editor, commit and push those changes, and then restart a service. It might be that none of those steps is very hard, but if the command line freaks you out it can be a nightmare. Also both emacs and vim cope fairly gracefully with editing very large files, where many GUI editors don't; we've edited multi-gigabyte text files with both emacs and vim when
those files would crash many other editors.
So one of the key goals of this lab is to begin to gain familiarity with the command line and command line editors. One lab won't make you an expert, but hopefully it will be a useful step in helping you feel more competent. There's nothing to "turn in" for this pre-lab, but you'll need this material to do well in the course, so the more effort you put in now the better for later on.
bash and command line toolsgit/Github
git, Github, and shell scripting with bashIt's enormously useful to know how to use a command line editor for those times when you don't have access to all the nifty windowing stuff that we've grown so happily used to using. Your best options are probably emacs and vim (or its less sophisticated ancestor vi ). There are many other options, but these two are some of the more popular powerful options.
Some people prefer more user-friendly options like nano or pico, but if you are starting from scratch it is not a bad idea to pick one with a tougher learning curve like vim or emacs. They are harder to learn at first, but offer much more powerful options later. Both emacs and vim, for example, provide powerful macro facilities that let you "record" and "play back" a sequence of keystrokes so you can quickly repeat a complex modification (something you couldn't do with search and replace) numerous times in a large file.
Both Nic and Peter know both emacs and vim; Nic is likely to (still) use emacs, while Peter typically uses vim. There are long and drawn out religious wars between fans of the two editors which we will not enter into. We will point out a few differences, however:
vi "out of the box". Because of this, vim is set to be the default editor in a lot of systems. This alone is reason to know at least the bare basics of vim since you're almost guaranteed to find yourself in it at some point, and it would be nice if you could at least save and exit without hurting yourself.elisp scripting language to do crazy complex customizations and extensions, but we don't know anyone who knows and uses more than a fraction of emacs's power.vim is modal and emacs isn't. In vim you have different modes; in "normal" mode you can navigate manipulate text, for example, where you need to switch to "insert" mode to just type text. Different people respond to in very different ways to this kind of modality; lots of people (including Peter) don't mind it at all, where it drives Nic crazy.vim tries to improve efficiency by having the most commonly used navigation keys on the "home row" (the position at which a touch-typist's hands rest). The arrow-keys still work as expected in vim (not necessarily in vi however). Again, some people love this, and some people hate it.The Internet is awash in materials (and arguments pro and con) on both editors:
vi vs church of emacsbash and Unix command-line toolsUnix and Unix-like systems provide an incredibly powerful collection of command line tools for processing and manipulating files and their contents. Over the course of these labs we'll cover what may seem like a ton of command line material, but which will in fact only be a fraction of what's possible.
Many of you will come into this with almost no experience with the Unix command line, while others may already have a fair amount of practice with these tools. Luckily there are a lot of good resources on the Internet to help get us all up to speed. A few tutorials that we think should be helpful:
These are in roughly decreasing order of "chattiness". The Ubuntu tutorial is nicely structured, and the LinuxCommand.org tutorials will cover most of what we need in a well organized sequence of steps. The "Learn Enough" tutorial is complete with sidebars and XKCD (relevant) comics, where the "BASH Programming" introduction is from 2000 and much more terse and "business-like"; the Chadwick tutorial is somewhere in between. They also don't cover exactly the same material in the same order; if you find one's coverage of a concept (e.g., pipes) doesn't make a lot of sense, have a look at how it's covered in one of the other tutorials.
There are also quite a few "cheat sheets" online and you might see if you find something of that variety that works for you. They inevitably have to leave a lot out so they all have some kind of bias. Some are aimed more at beginners, for example, where others are really intended as references for more experienced sysadmins. The Linux Commands Cheat Sheet from PhoenixNAP is fairly comprehensive and organized well.
Alternatively, if you prefer videos/screencasts, "Linux Tutorial – Basic Command Line" video is just over 20 minutes and really does start from the absolute beginning.
If you want more detail, these two series:
cover essentially the same material, but again in a quite different order and with a different style. (You'll notice that the narrator is using nano as their editor – you should be using the editor you choose earlier.) These videos do a pretty good job about starting from the bare minimum, but:
In order to prepare yourself for this lab, and others that will follow, you should go through one or more of these (or something similar you find on-line that's more to your taste). We don't really care which one you do, but we will expect you to have gone through something like this and made some effort to explore and practice with some of the basic tools. This is likely to take a few hours (especially if you "play along" at home, which you'll really want to do if you want to learn these concepts and tools), so don't assume you can just bang through one of these in 15 minutes.
We would strongly advise that you go through your tutorial(s) of choice in the lab or at least at a machine that has a terminal program with the bash shell installed so you can try some of these things out as you go along.
Terminal program in your
Applications/Utilities folder. :warning: Starting with MacOS 10
(Catalina) MacOS began defaulting to zsh instead of bash, so
you might be using zsh instead of bash. You'll still have
bash on your system, though, and will be able to write bash
scripts without any difficulty.If you're ever concerned about compatibility issues, you can always
use your favorite terminal to ssh into a lab box and do your
work there remotely.
As you are going through a tutorial, go through it once in a quick pass and don't worry too much if things don't make perfect sense the first time. If something is not making sense on your second reading, or does not seem to be working correctly please ask about it.
The final thing we'll mention here is the man command. If during your reading or the lab you run across a command that you aren't familiar with then the man command can be your friend. To find out more about a certain shell function simply type
man function_name_hereThis will bring up a page that (supposedly) describes what that function does. Navigate the man page with the arrow keys and press q to quit back to the command line. Keep in mind that man pages are written by the person or persons who created the function. This means that the man pages throughout the shell vary from extremely technical and detailed to non-existent. If the man page isn't helpful, some simple searching on-line should bring up tons of sites to supplement a confusing man page. :exclamation: Be careful, though, as there can be important if subtle differences between different versions of commands, and you're best off using the man pages on the system you're using whenever possible.
git and GithubWe'll use git and GitHub.com throughout the course as a way for groups to manage shared project resources (like code) and as the primary means for you to turn in your finished work. Some of you will be familiar with git from previous courses, while others will have never used it before. If you've never used git before you want to spend some time on any of a number of git tutorials such as:
git and how they relate to
GitHub. The workflow outlined here may be the closest of any of the tutorials to what we
use in most of the CSci courses here at UMM).git commands for those using
it on the command line.git commands. The rub is that it's
not always clear why/when you would use a lot of these features, so you can
"solve the puzzles" without necessarily really learning anything useful. You
might continue through this as long as you think you see why you might
want to do the thing you're learning about, and stop when the motivation starts to
fade. Then you can come back to it later after you have some more git
experience and some of the more advanced concepts are better motivated.rebase vs. merge when bringing together a bunch of changes.Most of the time you will be pulling from a GitHub Classroom site which automagically makes a repository for you – but for many labs you'll still need to get a copy of the repository on your local machine for editing, and upload your changes for grading.
To pull all these concepts together with a pretty direct connection to the first lab, we've created a series of screencasts that illustrate the use of git, Github, and shell scripting with bash. You should watch those before the first lab if possible. There are a total of six videos:
git cloning) (18:32)bats) (9:49)shellcheck) (13:25)
The full set runs just over 1.75 hours, and it will likely take longer if you "play along at home", stopping occasionally to try things out, rewinding to make sure you understand a step, etc. So allocate a reasonable amount of time to go through this. Also, feel free to increase the speed of the videos if you don't find the rather hyper effect too off-putting; I tend to watch things like this about 1.5x.
If you do want to play along, then you'll need to fork the demo project so you'll have your own copy to work on.
By the start of upcoming lab you should have:
vim or emacs) and have put some time into learning how to use itgit tutorialsgit, Github, and shell programming in bash