Mike’s Ultimate Unix Scavenger Hunt

So working here at GHP, one of the things I get to do is teach seminars. Seminars happen outside of the usual classtime…they tend to be fun special-interest type things. I’m planning on doing a couple but I decided to do the first one on the Unix Command Line. Many of my students have installed Linux. Many even have feelings about which distro is better. But yet most of them have never used the command line. This is very nostalgic for me: ah for the halcyon days of my youth! I made it my business to install every distro yet basically had no clue what one would actually do with a distro once installed. Of course in those days just getting X to work was considered a major achievement.

So anyways I figured they should at least have exposure to some of the cool things you can do with the command line.

I organized it as a “scavenger hunt”. Basically I divided my students into 4 teams and then gave them a list of 30 things to figure out how to do on the command line. The rule was that everyone on the team had to be able to do everything for the team to get credit…when teams called me over I would quiz random team members. This was necessary because we had extremely varied levels of experience…I didn’t want the experienced people just going off and leaving new members to get frustrated.

Basically the whole thing worked like a charm once everybody started working (getting everybody started and on the same page was a bit of a pain). I never cease to be amazed by how much more intense student focus is when they’re working on concrete activities rather than listening to me lecture.

By the end, even students who basically had never worked with Unix before thought the whole thing was pretty cool. The teams basically only got through item 10, but when I asked them who wanted to continue the scavenger hunt next week everybody raised their hands. When I asked them if they wanted to just come back and continue from where we left off or research stuff outside on their own, two of my no-linux-experience girls argued that they just couldn’t wait till the next seminar without playing with it some more.

Funniest thing: a couple of students told me confidentially that they completely understood playing around with the command line for fun, but they weren’t completely convinced that it could actually do anything useful. I found this neat because it seems like normally people feel like command line stuff could be useful, but don’t want to actually go through the bother of learning. That said, I want to provide some persuasive examples next time about how command line stuff can be useful for real.

So unixy friends, here would be two helpful hints I could use from you:

  1. What are some simple and concrete things you can do with the command line that even high school students could understand is awesome
  2. I could use a few more items for my list of 30 command line things. I compromised with the girls: I asked everybody not to research stuff before the seminar so that all the teams could start on the same footing. But I said that I would make an auxiliary list of challenges for people who just couldn’t wait to play with in the meantime.

5 Comments

  1. Ben says:

    Oh man, this is totally awesome, and it sounds like your class had a good time!

    Where is my experience unix guy scavenger hunt?

    As far as simple and concrete things to do on the command line… hmm… how about sort | uniq -c ? like take a phone bill and see what the most called numbers are? (maybe one of the cell phone providers provides a csv or something…

    or how about download all the links 1 level deep from a web page (wget -r -l 1 http://www.google.com) and then grep the resulting files for something…

    or you could use sed to change someone’s name (like if they got married) across a bunch of files. (though this might be harder than you want)

    how about send a mail to a bunch of friends whose address you have in a file? foreach i (`cat addresses`) { mail -s “Party Invite” $i < email_text }… I really wanted to use xargs on that one, but I can't find a mail program that will take a file to mail (mutt will, though, I think)…

  2. Kenny says:

    Very cool, in my day you only had the command line and you liked it!

  3. Dave says:

    Very cool indeed. Command-line competence is sorely lacking among many people who use unix/linux every day.

    Regarding your bash/zsh requirement: this is sensible, since these are the two main feature-packed shells. However your note calls out ksh, which for programming looks fairly bash-ish, when csh/tcsh are the real problem. They act so totally different from normal Bourne-ish shells that you can’t even write portable code for a common minimal set of features. Since assuming a plain Bourne shell (“/bin/sh”) is the safest route to shell script portability, there is no good reason to learn or use csh.

    Something that teaches them about “sort -n” would be good; this seems to stump people with numeric data. You could also couple it to Ben’s suggestion of “sort | uniq -c” in order to put the histogram in order of prevalence.

    Pulling a column out of a text file or pipe also is a useful skill. Depending on whether you want to push “cut”, “awk”, or something else, you can (weakly) build on the previous example: “… | sort | uniq -c | sort -n | awk ‘{print $2}’.

    Teaching the basics of “find” also would be valuable. It’s not the most intuitive command, IMO, especially if you are coming from a non-unix background. A good concrete example could be that you want to delete all “.o” files in a recursive build: “find . -name ‘*.o’ | xargs -n 1 rm”.

  4. buffalo says:

    Thanks Dave and Ben! I shamelessly used your examples in my followup talk, which I did think helped solidify what could be done in student minds!

    Overall I think the reprise unix session turned out not quite as good as the original. Problems:

    a. Much lower turnout. Talking with the students it seemed not everyone was monitoring the seminar board so no everyone saw my “2nd unix seminar” on there. I already disappointed a few students who approached me and asked about a seminar after it was already done.

    What I should have done was asked in seminar “Hey, how about we do this *Tuesday*. Is everybody cool with that?” But I wasn’t sure I could say that…dumb…

    Anywhoo this lead to less energy in the room.

    b. With so few students I put them on the same team: mistake…that was a team of 6 which was too large given that they were placed along the wall (by the computers). In a corner…but still communication between 6 and 1 was really not possible. I think this made the team seem less close so there was less sharing of ideas.

    c. I also maybe didn’t pay as close attention some of the quieter students who just would look stuff up but not talk and share. These folks lost out because they didn’t the benefit of what others had found and they didn’t share either. When I was working with the group this wasn’t as obvious (I had many loud students clamoring for my attention) but I think the problem was still there. Need to keep a closer eye, basically, not let people fall by the wayside.

    That said the whole process was very good. I’m quite happy with how this turned out and with the enthusiasm of the students.

  5. Brian Maher says:

    I know this is a little late, but here are some concrete examples:

    * Tailing the newest log file.

    * Comparing traffic patterns in log files to find unusual behavior.

    * Select a set of files that have a name that matches a regular expression and/or have content that matches a regular expression, potentially unzipping that file if it is compressed.

    * Once you have a set of files to operate on, you can mark them as “needing to be edited” if you have a source code control system that requires that :-(.

    * You can do a search and replace across that sub-set of files.

    * Rename/move a set of files based on content of that file or the name of the file (like if you want to go to a “flat” directory structure).

    * Automate all sorts of things. For example:

    ** When I checkout my source code with `git` I also want to set-up a symlink so my repository is viable via gitweb.

    ** Easily switch between directories using pushd and a macro that I call `sd` for “switch directory”.

    Ultimately, I think the most powerful paradigm is a GUI that can be controlled via a macro language, and a status bar that shows you what you commands the GUI is sending so that you can easily automate stuff.

    Another reason I like the command line is that no matter what computer I login to, I can have all my personal preferences set-up via `eval “$(curl -L http://brimworks.com/h)”` (WARNING: that command may overwrite your preferences!). Also, the command line allows you to manipulate remote machines without requiring a console nor does it require a “big pipe” (although latency certain makes the CLI experience less than fun).

    I should also mention that `screen` is one of the best things in the world :-). I’ve had screen sessions last through several laptop crashes.

    Cheers,
    -Brian

Leave a Reply