How to teach the value of the command line in high school?

Question

Part of what I love about the particular adaptation I use for AP CS Principles — CS50 AP — is that my curriculum teaches students basic Linux shell commands in the Cloud9 IDE. Students learn things like cp, mv, mkdir, cd, ls, and zip (just to name a few).

However, at the beginning of the year, it is challenging to motivate why the command line is a powerful tool to learn. They just take my word for it even though it is a big struggle. It is much more frustrating for beginners than a GUI and has no forgiveness for a mistyped character.

How do you communicate the value of the command line to your students? Are there specific examples you use that effectively illustrate the power of a CLI?

Note: This question is not a duplicate of Command-line Java in AP CS A (although it is tangentially related) as that question asked whether or not a CLI should be taught in AP CS A. This one is focusing on how it can be motivated when it has to be taught regardless of course.

Answer 1

You can't teach the value of the command line. You can, however, sell it.

Students have at least one of two primary goals in any class:

• Get good grades (pass the class)
• Learn something they like

These are not mutually exclusive, and may change as the class progresses in their relative positions. For the students who's motivating goal for the class is primarily passing the class, the command line is not likely to have value. For the students that are interested in learning the subject, the command line can become valuable.

People make value judgments "on the margin," students just as much as adults. The "power" of the CLI as opposed to a GUI, is not a selling point for students yet. The things they can do, even in a GUI, is so far beyond what they've done before that even a couple magnitudes of extra power is immaterial.

Your students have a limited amount of time and effort they are willing to devote to learning material from all their classes. They will always do a cost benefit analysis to parcel their time between courses. For your students, the CLI won't have any value until they reach their own conclusion that their substantial effort to learn it, as something extra to their normal studies, is justified by what they think they will gain from it. (For the students that have not used the CLI very much it will be like learning an additional programming language, so, yes, it will involve substantial effort to learn. We know the utility of it, they don't. Yet.)

What might make a difference to them is seeing how much easier it is to accomplish "simple" and common tasks in the CLI than in a GUI. Don't "race" them with you doing a task in the CLI and them in the GUI; that's not fair, and they'll know that. (You can probably do it in a GUI faster than they could in the CLI anyway.) Don't "teach" them the CLI, show them. Lead by example. Use the CLI anytime you can, even when you'd rather use a GUI personally. Organizing your files, creating directories, doing configurations, etc. If the CLI is your goto tool for everyday tasks that they would normally use a GUI for, especially once they realize that it really is easier and faster that way, they will begin to think about it, and eventually consider it as a possibility.

In your lesson plan for the term, leave some slack time which you can utilise to teach the CLI. Keep it "on tap," rather than listing it somewhere in the plan, so that you can divert into those lessons whenever the class seems ready. Each class is likely to reach the decision point at different times, and teaching it before that point is likely to be lost on them, and wasted time for you.

Once the "sale" has been made you can use many of the ideas given here, which I'm not going to collect as I expect that more will arrive anyway. Placing them in some kind of order for increasing complexity, leading to batch/bash scripting could be a good plan.

Answer 2

I can't speak to cloud9 but I've always taught on Linux and am a CLI wonk.

One thing I do is differentiate between user friendly and learner friendly. GUI interfaces are learner friendly - they're easy to learn but they're not user friendly because they're not that powerful. They're basically program loaders. You load your program, work in it, exit, next.

The Shell is a little less learner friendly (although the fish shell is amazing from the learning point of view) but it is amazingly user friendly because it allows the user to do all sorts of things.

I try to model this over the course of my classes and I try to provide examples.

For instance, if I wanted to resize a bunch of gifs in a directory, I might show the class something like:

ls *gif | while read i 
do
  f=`basename $i .gif`
  convert $i -resize 200x200 smaller-$f.gif
done

If you make it useful to them, they'll appreciate it more and use it more.

I wrote a few blog posts over the years with examples including:

• pre-processing and cleaning up dirty downloaded data
• processing info from google forms (downloaded as csv)
• operating on many files across directories

The posts can be found here: https://cestlaz.github.io/categories/cli/

Answer 3

One way to show them the value of the command line would be to juxtapose doing a task with a GUI and with the command line. You could do something like the following:

Create a directory with mixed content (eg. text files, audio files and images).

Ask your students to perform these actions via a GUI, then via the command line:

1. Move any text file that contains the word "business" or "work" to a directory called "work"
2. Select all the audio files and move them to their own "music" directory.
3. Select all the images and move them to their own "images" directory.
4. Compress all audio files that are larger than 2MB into a zip or gzip.
5. Make a sub-directory within images and move all files that contain the words "family", "trip", "mom", "dad" in the file name to a "personal" directory.

They will soon come to appreciate the fact that this can be easily scripted with a few lines of BASH:

mkdir -p work music images ./images/personal
mv `grep -Ril 'business\|work' .` ./work
mv *.mp3 ./music
for type in png gif jpg; do mv *.$type images; done
find ./music -size +2000 -print0 | xargs -0 tar -zcf large_music_files.tgz
find -E . -regex '.*(family|trip|mom|dad).*' -not -path "./images/personal" -exec mv {} images/personal \;

Answer 4

Not a demonstration, but maybe a nice thought to tell your students. I read a nice analogy a few months ago, linked from a question somewhere on stackexchange:

Using a computer only with a GUI is like communication without using one of humanity's biggest accomplishments: language. It does have it bonuses; you can communicate to other people simply by pointing at things, without knowing their language. But your communication will be very limited; you will only be able to communicate about things that you see. If you want to mention something that is not there at that moment, you are lost. It is also very difficult to express complex ideas or relationships without language and pointing alone. Try giving someone shopping instructions by pointing alone. Then try the same with a pen, paper, and a language you both know.

The analogy is not that bad (but maybe my example of the shopping list is?). It gives you an idea of the advantages you can gain by using the console. It also gives you an idea of work you have to put into it: you have to learn a completely new language. As is with natural languages, you will be able to do simple things on the console pretty quickly; but understanding a philosophical discussion between to studied people in their field of expertise will take you years of practise, and you might still need to look up quite a few things to get all details.

Edit: I found the answer I was mentioning on UX, so credit to @ShreevatsaR there: https://ux.stackexchange.com/a/102018/102548 – also there is a longer article from 1996 linked and quoted there, which might be worth reading: The Anti-Mac Interface by Jakob Nielsen

Answer 5

The value of the command line can clearly be demonstrated by looking at a simple gui configuration task, which might take 5 or 10 screenshots, and still be ambiguous in comparison to 'open a shell and paste these 2 lines of text'.

This doesn't encourage students to use the command line themselves, but starts to explain to them why it is valuable. You can draw parallels with using keyboard macro shortcuts in comparison to using a mouse - it's faster when it doesn't involve moving your hands as far (even if it requires learning the right set of shortcuts). Beginners won't want to start off by learning the short-cuts, but might become familiar with Ctrl-F for 'find' if they need to search for a few things.

Of course, with a mobile device, the command line (or keyboard shortcuts) are not the most obvious step. However, there are plenty of things with a phone that can only be done using adb, or become easier to do (or script) once you have adb available.

Shell commands, and shell scripting is just another tool. Trying to force students to use it too early is probably counterproductive - you need a scenario where they have to use it before they will be able to start to accept it. This doesn't mean you shouldn't yourself drop into using the command line when they can see you, but you're not explicitly teaching with your actions.

Answer 6

I learned the value of CLI on the job, where we would test our code, installers, etc. on multiple machines with multiple OSs. Many server Linuxes do not have GUI to begin with, but even if dealing with a Mac it is much easier to use responsive text terminal, rather then slow-as-molasses VNC.

It also helps that while GUIs are pretty different between different OSs (and even different version of the same OS can have some stuff moved around), CLIs for the most part are very similar (at least between Linuxes and Macs) so if you know, say, Git commands (as one should if there are going to be a programmer) you can start using anywhere without learning a new GUI each time.

Same thing for editing and compiling your stuff, if all you know is VS or XCode and suddenly you need to compile your program on Linux, what do you do? But if you take the trouble to make a make file yourself, you know exactly what's going on, what libs you're linking against and such, and in a lot of cases you don't even need to modify it.

Bottom line is knowing CLI gives one the ability to work with multiple systems pretty comfortably, which maybe is not something that happens a lot in school, but at work is pretty common, many companies like their products to be multiplatform

PS:

The biggest advantage of CLI, though is that you can set the terminal background to black and letters to green, so that even when you're doing some pretty mundane stuff like extracting an archive or copying files or whatever, you'll look like a badass movie hacker, so there is that

Answer 7

My reasons for using a CLI might be different from yours. As an educator you'll be most convincing when you can point out the advantages of the CLI that are most meaningful to you.

Off the top of my head, the reasons to use a CLI over a GUI are

• unambiguousness. There's no "click that option. No, THAT one."
• repeatability.
• scriptability. This is a cousin of repeatability - you can collect tasks into script files.
• embeddability. CLI tasks can be called from other CLI tasks.

It's easy to invent scenarios that show these facets that work for you. If you have a class of facebook nuts, for example, one case I like is to have one kid up at a computer+projected screen login to Facebook and navigate to a friend's FB page. That friend (also in class) then describes out loud to the class how they would use the GUI to download all their profile pics, artwork etc. Then you show them something like the FB CLI and how it can do it all in one hit (see one of several fb cli on github.

Another example I like is to show a folder with a few hundred Word files and ask our they would convert each one to PDF. Then demonstrate LibreOffice in headless mode converting them all.

Answer 8

Here, take this pen. Now sell it to me.

As with the above well-known interview question, the value of a given tool can be most appreciated when one has no other alternatives than to use it.

Show your students that in productive systems and real-life environments such as server farms and data centers there is no such thing as a GUI (or very rarely). The value of using the command line in these cases is therefore very high indeed.

Answer 9

These are some experiences I've had, highlighting the power of the command line:

• Some programs print status messages as they run, if they were called from the command line, that otherwise would never be seen. This particular advantage of the CLI helped the developer of the logic analyzer I use to determine that the file it captured was corrupted.
• Sometimes GUIs are just too confusing. There are many times when I'm looking for setting in a GUI app that I can't find, so I go back to the CLI version of the app.
• It's easier to see output or feedback from programs on the CLI, especially if you're writing your own tool. Shell scripts are especially handy for file manipulation or output redirection.
• Also, you can set or change any configuration settings on a command line.
• There have been times when I forgot all the passwords on old computers I had, so I was forced to hack into them at boot-time to change their root passwords.
• Another thing I encountered in the past is when I had to reconfigure certain settings on a computer without being able to view any display or output of any kind. By going to a console on that computer, I was able to type the correct commands to get it to do what I wanted it to. Then it was ok.

These are just situations I've encountered in which a command line was absolutely required to get the job done. There are so many more. Also, if you're a keyboard commando, it's just easier and quicker to get certain things done by using the command line.

I guess my whole point here is: if all else fails, there's always the command line.

Answer 10

The are a couple of things that make the command line superior to GUI interfaces:

Command history

The one killer feature (in my opinion). If you remember that you have performed a command before, and remember anything about that command you can quickly find it by typing ^R and do a backward incremental search through the command history. Or you can press up/down arrow until you find the command you're looking for.

If the shell only had this single feature going for it, I would still use it above a GUI, any day. (But there is sooo much more...)

Pipes

Piping the output of one command into the next makes for powerful combinations.

Say that I have a large directory of files, of which I suspect some are identical, but with different names?

The following commands will can be used to (line 1): compute a list of checksums; then (in line 2) create a list of all the checksums that are repeated more than once; and (in line 3) display all files (and their checksum) that are occur multiple times. That line 2 there is a killer line! :)

md5sum * >checksums
sort checksums | cut -f1 | uniq -c | grep -v '^ *1 ' | sed 's/^.* //' >doubled
grep -fdoubled checksums

(BTW, teaching this to your student you should caution them that lines with newlines and spaces may fare badly in the above process.)

Scriptability

I guess I sorta touched on this in the above heading, but there is so much more than just pipes.

Stuff like while read LINE; do ...; done <FILE and for *.txt; do ...; done, and functions are really all nifty stuff.

Combining functions and pipes to produce filters of various kinds is also neat and nifty. For example, you could type:

trim() { sed 's/^ *//; s/ *$//' }

and thereafter you can use cat FILE | trim to output a file with all its leading and trailing whitespace removed.

Language-Like Fluency

The scriptability and pipes points above combine to something new and powerful, which I usually compare to language fluency.

In a GUI your reacting to elements presented to you, if there isn't a button or menu option for something onscreen then that functionality does not exist for you. You're sorta piggybacking on your sense of direction, or ability to navigate through space to find your way. "Oh, I'm here, that means I can click that menu, to get that window to pop up, so I can select that tab, which does what I want." – You're forever navigating around, using recognition to see where you are and what your options are right here.

A CLI, on the other hand, gives you a language. A whole vocabulary which you can use creatively to express stuff, and which you can expand with your own scripts and functions (such as, for example the trim function above).

Some of this language you use often, and so it becomes part of your active vocabulary (ls and cd and most of the other basic file and directory commands come to mind). Other stuff you recognize by sight, but might not come to mind as you're looking for a solution (or come to mind only partially – which is where the command history comes into play) so its more of a passive vocabulary to you.

Answer 11

The most obvious reason why CLI is important is because it is a pre-requisite for future concepts taught in Universities and for work. CLI itself is a very powerful tool as it gives you access to the file system and perform a variety of useful tasks.

From the top of my head, one key feature of CLI is that you can perform SSH in order to send, copy, and explore files from a remote to local. You can also check system log files for issues and configurations. This is different than sharing screens and remote connect because we are talking about access to file systems and opening a pipe to your own computer for filestreams.

Extending further, CLI is the basis of multiple mainstream applications such as Git, Node, and NPM. As developers, we move away from running executable to setup our development environment and applications, therefore it is imperative what we know and understand CLI. For example, setting up AngularJS or React (two of the hottest front-end technologies) is as simple as npm install ... as posed to unzipping from Git and running a whole bunch of scripts. Now moving on to Git, any seasoned developer will tell you that nothing is better than CLI for Git. Sure there are a lot of UIs for Git, but they are not as feature rich as the CLI and often times buggy. You can't get away with being a developer and not use some form of source control, so it is good to get familiar with CLI early in your life.

Lastly, the biggest non-reason would be how cool you look in-front of non-programmers programming in that black and white terminal ;)

Answer 12

From an administrative perspective, a lot of Linux servers don't have a GUI in order to reduce the resource usage. Doing anything on them will require knowledge of the command line, or knowledge of an automation tool like Ansible so they can be configured correctly. The value of knowing CLI is being able to administer servers without a GUI, or be able to administrate them faster.

A one I use when bringing junior developers on board is get them to navigate to a specific directory. Usually the webroot (I use Debian servers, so /var/www/html). because you know where you're going, cd /var/www/html is a lot faster than:

• click the file manager
• navigate up to /
• click var (wait for loading)
• click www (wait for loading)
• click html (wait for loading)

That's a basic example I use. If they can get on board with that, it's generally a lot easier to get them to appreciate that whilst they may find the GUI easier to start, when you know the commands you'll end up using 80-90% of the time, the cli is so much faster.

Answer 13

Simply put: the command line can do things which the GUI apply cannot. In Windows this is easily seen. CMD can perform operations that no other GUI based tool can.

In Linux there aren't many graphical tools anyway, but the terminal is by far the simplest way to get things done.

To show them the strength of the command line, explain that GUI tools don't always specify the error message (depends on the error), should one occur. Command line does (regardless of which error occurred).

Another way to motivate the students would be to say that the terminal can do anything that any graphical tool can, and the reverse is not true. This would show them just how useful it is.

Additionally, the terminal can override anything.

Answer 14

Infrastructure as Code.

If the configuration of your infrastructure (presumably via CLI) cannot be reduced to code and checked into source control, then you are setting yourself (and your employer) up for failure.

Answer 15

In addition to the experiences I (Nate W above) had of requiring the CLI, there was one more important one that I forgot to mention, although it isn't as relevant today as it was in the past: using a serial interface to communicate with a computer when the monitor or video system was not working. This is similar to the last point on my list above.

There was a situation once in which I had to connect a null-modem cable between two computers in order to fix xorg.conf on one of them. CLIs are such wonderful and powerful tools.

CLIs are just there. As long as your computer (and/or operating system) runs, it's always there. It won't let you down. Probably the best way to teach the power of the command line is to have someone fix their GUI using their CLI ;)

Answer 16

I have had students work in summer internships; feedback I get from companies tells me that familiarity with the command-line interface is extremely valuable. The command-line interface is very much a part of "real world" programming practice.

We run a student computing server at NCSSM using Red Hat Enterprise Linux; all of our beginning students learn to work on this server. My introductory class does an early unit on UNIX commands. I have a project in which students place code in a simple shell script that does various types of sorting and searching on a scrabble dictionary text file. This demonstrates that the shell is programmable, extensable, and that it can automate all sorts of tasks.

Many of our students become very conversant with Linux and wind up running it on their PCs. Quite a few find that once they learn it, the vi editor is fast and very efficient.

Answer 17

There have been some great answers so far; here is an approach I haven't seen described yet.

I show my students how they can use the CLI to access our workstations from remote locations. My students have accounts in our lab of Linux workstations, but suppose they want to work on their project from their dorm room or off-campus apartment or home, or when the building housing our lab is closed? (Does anyone else have students who want to work on their homework over the holidays?) Using an ssh client and the CLI, they can login to a lab machine from their laptop (or even a tablet) and work on their project. Mastery of the CLI (combined with ssh) lets them work whenever and from wherever they want, regardless of when our lab is officially open.

I happen to have an account on a Linux machine that's physically located in Asia. From my classroom in the US, I use this same approach to demonstrate to the students how I can login to that machine and edit/run a program there. That helps the students see that this generalizes beyond our campus to let a person access any machine on the Internet (on which you have an account) from across the world.

In theory, this could be done using a GUI, but the amount of network bandwidth required to transmit a GUI's graphical information across the Internet makes this problematic. By contrast, the CLI just requires a modest number of characters to be transmitted back and forth, making this approach practical from just about anywhere.

Answer 18

Teach the command line as part of a brief history of computing. Let them know how good they have it, not having to punch cards and wait overnight, or use a command line on a clanking teletype over a remote 110 baud link.

Answer 19

Are there specific examples you use that effectively illustrate the power of a CLI

Even if you prefer the GUI, as an administrator you never know when you might need to know the CLI. Most importantly in emergencies.

A few practical situations and benefits of having a CLI:

• In a mixed platform environment you can access all other servers from a single desktop or other terminal. Even from your phone.
• Using SSH connections to access multiple servers, maybe for administration purposes, e.g. building or testing an environment, issuing commands from a single machine is cleaner; rather than lots of gui desktops in different windows.
• Where a server might become corrupt (partially booted, infected or under a DoS attack) you may be able to access the shell to issue a restart or shutdown. For example, you may be in a position where you can only access the server remotely, the office is situated geographically apart, you're at home on call or maybe meeting a client. You may only have you phone with you.

Answer 20

Have some reasons why they should use the command line. Here are some of mine.

Why I like the command line

Less typing

How can this be I hear you ask. Well I login, reverse search (ctrl-r) or up arrow (⬆) for a command I typed last week and hit carriage return. The alternative is far more mouse clicks (and trying to remember).

Show an example of you having to repeat the some actions on the GUI to do a repetitive task. Then show you doing it on the command line, using up arrow, and making a small change.

Also show an example of you getting to the end of a work flow and realising that you have to go back to the start, and then having to repeat the work flow. (note this reflects bad GUI design, but the CLI is a way to avoid it.)

So you were taking pictures of cats, but then you saw a dog at 11:10, and started taking pictures of dogs. So now you have a folder full of pictures, with names like “cat with a ball”, for an labrador puppy. So you need to rename 100 photos. (It was a long day. You took a lot of photos, and learnt that a dog is not a type of cat.)

• Solution 1 — Start clicking: Repeat 1000 times, Right click, rename …
• Solution 2 — type find . -newermt 2017-12-23T11:10 -print0 | xargs -0 rename -e "s/cat/dog/"

Unambiguous and clear

It makes it easier to answer questions on stack-overflow; No screen shots needed, just text.

Easier for dyslexics (sometimes)

I am dyslexic. I, sometimes, get confused when trying to find an item in a list. I find it easier to just type it.

More powerful

• find all files with the word dog in their name.
• find all files with the word dog in them.
• change the word dog to cat in the contents of these files.
• change the word dog to cat in the name of these files.
• wait for a file to change and then read it, if it is an image file and contains the tag dog then open it in an image viewer.
• …

Faster over remote connections

Opening a window over ssh can be slow.

Automation

If you can do it once, then you can do it again, with scripting.

GUI-able

One can easily wrap a command line script/program in a GUI, but it is much harder to wrap a GUI program in a script.

Why I like the GUI

• Better visualisation.
• Easier for beginners, and infrequent users.

A Compromise

The dolphin file-manager, has an integrated text terminal. Not just integrated in that it is in the same window, but in the sense that there is bidirectional synchronisation of present-working-directory between the CLI view and the GUI view.

Answer 21

CLI vs GUI

CLI

• Easier to use
• Easier to learn
• Better for instructing computer what to do.

GUI

• Easier to use
• Easier to learn
• Better for visualising: looking at images, charts, graphs, etc.

Easy to use

There are two definitions of "easy to use"

• Meaning 1: easy to learn.

• Meaning 2: easy to do for someone with experience.

We often get stuck in the local minima of meaning 1, and don't put in the effort to achieve meaning 2.

Easy to learn

There are two definitions of "easy to learn"

• Meaning 1: Without reference to manuals or examples, a learner can figure it out by playing with the tool.

• Meaning 2: easy to figure out by examples.

Easy to learn — meaning 2

E.G.

This answer, and everything on stack-overflow, is written in Markdown. If the reader wants to know how I did something, then they just need to look at the Markdown. If it was done in a WYSIWYG (what you see is what you get) editor, such as a word processor, then they are out of luck. There is just no way to find out.

Therefore, I can give students examples (heading, bullet lists, etc). Students can study these, and try them out for themselves.

Answer 22

Here in 2023, I'd be asking "does the command line even have value?"

In my view, the command line is completely superseded for interactive use. It might be useful as an aid to teaching scripting/programming principles, but not as a generally useful tool in itself.

I learnt computing in the era when you often had to use the DOS command line to get things done. But I can't remember the last time I had to do so, and I'm sure it didn't involve issuing more than one command.

It seems there would be no justification for routinely teaching any of the details of command-line environments nowadays.

The combination of GUI (for discoverability or infrequent use) and scripting language (for documenting or executing pre-planned sequences of commands) has been king in usability for at least 25 years.