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

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.

• Two words: scripting and communication. Knowing the command line is knowing how to write OS scripts to automate your drudgery. It's also an unambiguous way to tell someone what must be done. Even if you prefer GUIs for some other tasks, the command line is vastly superior for these tasks. – jpmc26 Jun 19 '17 at 7:45
• @Peter "hacking" routes to redirect facebook to some stupid page, shell as calculator, starting old game with DosBox, confusing hard/symbolic links, command porn, toys like cowsay. Avoid things that can be done easily, and sometimes with better results, in gui (tracert, basic file operation, compiling) or you will get labeled as "stuck in the past geek" or worse. Its like math, don't teach them trigonometry, show them how to do taxes :) – PTwr Jun 19 '17 at 16:16
• Here's an idea: why would I want to watch Star Wars: A New Hope in a video player when I can do it in ascii? (Video version here if you can't run telnet) – Cody Jun 19 '17 at 22:48
• Possibly relevant link: Why are terminal consoles still used? (Disclaimer: One of the answers there is mine.) – ShreevatsaR Jun 20 '17 at 22:06
• Not directly on point but closely related, I highly recommend In the Beginning was the Command Line by Neal Stephenson, as well as The Art of Unix Programming by Eric S. Raymond. Both provide both background information and design principles that make understanding the structure of modern computers much easier. – chrylis -cautiouslyoptimistic- Jun 21 '17 at 3:15

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.

• It won't be like learning an additional programming language, it is a programming language. – Solomon Slow Aug 16 '17 at 17:23

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/ • I'm sorry for being pedantic but this is important if you are teaching people. Your simple little script is full of bad practices. It will fail on any slightly non-standard file name. Please don't show things like that to your class. You are parsing ls in a way that is i) unnecessary (for i in *gif; do ...), ii) unsafe (see here iii) very fragile (if you must parse ls, at least use while -r and quote your variables. – terdon Jun 19 '17 at 8:42 • No, it won't work. That's the problem. Try it on a file called foo bar.gif, let alone foo\nbar.gif. Your throwaway only works for very simple cases and is actually far more complex and daunting than it needs to be: for f in *gif; do convert "$f" -resize 200x200 smaller-"$f"; done. The basename is pointless since you're not recursing so it only removes the .gif which you then add back again. And this simpler version can deal with arbitrary file names. In any case, teaching people the robust, portable and correct way is always better than throwaway hacks that will fail easily. – terdon Jun 19 '17 at 10:21 • There are no cases (like this) where the while works better than for. You might be thinking of for i in$(ls *gif) which is indeed even worse that what you suggest here. But I do get your point about the easiest being whatever you come up with. And that would be absolutely fine if you were doing it for yourself. If, however, you use this to teach people, then it is not fine and is actively harmful. Do whatever you like at home, but please don't teach bad practices to your students. It's bad for them and bad for whichever poor schmuck hires them and they screw up their server. – terdon Jun 19 '17 at 11:11
• @terdon remember this is about teaching someone very new to programming. If you throw in too much in an example, even if it's good practice, you risk scaring or driving away your audience who feel it's too much to process. This is a good start to show the power of a shell and basic commands. Once the students have understood that later better practices will be taught. By my experience tutoring has shown me you can't teach it all at once or you overwhelm those your teaching. This is a good example of the power of a shell, though I'd like to see even simpler one liners also shown. – dsollen Jun 19 '17 at 13:10
• @dsollen - I think the reason he is being nitpicked is that this is an educator's board and he is describing giving bad code to his students. If I was just learning command line, the worst thing that I could imagine is getting a command from a teacher that didn't work for me. Let's say I was a student, and I wanted to try this example on my own. I go home and try it, but I have spaces in my file names. Now, the code doesn't work. I may not have a good source to find out why. Now I just think CLI is finicky junk and will avoid it more in favor of GUI, the exact opposite of the OP's question. – EvSunWoodard Jun 19 '17 at 17:57

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 \;  • Welcome to CSE! There are some great ideas in this post, but I must disagree with "easily". Have you tried explaining something like your mv grep -Ril 'business\|work' . ./work to kids who have never used a POSIX prompt to so much as ls? Having done it, I promise it ain't so easy to explain ;) – Ben I. Jun 19 '17 at 4:54 • I think these are good examples, iff the students already know the CLI, OTOH, if they don't, it'll be convincing the other way. In the GUI they can search and sort with fair ease, and accomplish all the given tasks faster than they can create the given commands. – Gypsy Spellweaver Jun 19 '17 at 6:36 • To be fair, that script doesn't look "easy" to come up with. – jpmc26 Jun 19 '17 at 7:48 • Other idea of tasks : Remove all the temporary file with a "~" inside a directory with thousands of files (rm *~ vs clicking). Change the owner of files recursively in a very big directory tree... Doing makefile in order to generate C code, latex code, plantuml diagram... – Pierre.Sassoulas Jun 19 '17 at 8:40 • s/easily/efficiently – Baldrickk Jun 19 '17 at 9:59 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. • But we always teach to never paste text from a browser onto the command prompt directly. – JDługosz Jun 21 '17 at 5:57 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 • Nice, detailed, thoughtful answer. You will do well here. ;-) Welcome to CSE! – Ben I. Jun 19 '17 at 20:52 • Big + for mentioning the coolness factor. – vacip Jun 19 '17 at 21:56 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 • This is brilliant. This really gets to precisely why CLIs are worthwhile. And the only visual alternative right now, then would be block-based coding? Welcome to CSE. I hope we hear more from you! – Ben I. Jun 20 '17 at 10:38 • @BenI. I found an linked the source - has a longer article linked, you might be interested. – kratenko Jun 20 '17 at 11:01 • +1 from me :-) Glad to have successfully spread this nice analogy to at least one person. – ShreevatsaR Jun 20 '17 at 22:27 • From the perspective of a student: the advantage of GUI is precisely that I can see what I am doing, that I have context about what I am doing. Which makes it seem safer to use the GUI than command line. – Katinka Hesselink Jun 21 '17 at 5:31 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. • CLI programs, can also be embedded in a GUI program. – ctrl-alt-delor Jun 9 '19 at 18:41 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. • This is a good point. Welcome to CSE! I hope we hear more from you in the future. – Ben I. Jun 19 '17 at 12:23 • If you use the command-line because to are forced to, because the can not use the GUI, then you do not know the value of the command line. This is only one of the smaller advantages. – ctrl-alt-delor Jul 29 '17 at 21:47 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. • Nice answer. Welcome to CSE! I hope we hear more from you :) – Ben I. Jun 19 '17 at 16:37 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. • Welcome to CSE, gabe3886! This is a great point. I hope we hear more from you in the future. – Ben I. Jun 19 '17 at 13:24 • Actually in the GUI the cd /var/www/html amounts to 1. Click the file manager 2. Click into address line 3. type /var/www/html 4. press Enter/Return. Wait for loading only once. – Ruslan Jun 20 '17 at 16:03 • ssh -X will let you run GUI programs, to display locally. (You still need to know the command-line to do it.) – ctrl-alt-delor Jun 9 '19 at 18:31 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.

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 ;)

• Black and white? Real programmers have green text. – Scimonster Jun 20 '17 at 14:00
• Haha for some reason this made me laugh more than it should. My friends tell me the same thing ;) I suppose it is I that do not like green. – Kaneki Jun 20 '17 at 14:06
• Did someone say green? (I make these jokes all the time, but this is the first time I do it on SE :P) – ItamarG3 Jun 20 '17 at 15:53
• @Scimonster I think I'm an unreal programmer... – Ruslan Jun 21 '17 at 16:35
• I love the command-line. I love ssh. I love to type in a command that opens a window on the local machine, but is running on the remote. – ctrl-alt-delor Jul 29 '17 at 21:50

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.

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 ;)

• I believe it is possible to merge accounts - try contacting the stack exchange team. Either way, welcome (back?) to CSE =) Thanks for your answer! – heather Jun 19 '17 at 23:19
• Very related point: ssh. If I want to do something on some other computer, I just ssh machinename command and done. GUIs? Err, let me see if I can get VPN to work... And after that is done, if it can be done, you still have to navigate a very slow GUI. – Stig Hemmer Jun 20 '17 at 9:36
• A friend of mine, accidentally took down a bundle cables, from the remote end. The only way to get it back up was to tell the remote end to come back up. He was just putting on his motor-bake leathers (luckily it was to to far), when he saw the apprentice “Did you decommission that 56k modem?”, “No. Sorry, too busy, I will do it next time I am there”. A squeek squalk, and a few key strokes latter, and the connection was back up. As far as I know that modem is still in service. – ctrl-alt-delor Jun 9 '19 at 18:10

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.

• They can always use CLI to create a GUI :) – Gypsy Spellweaver Jun 19 '17 at 6:16
• @GypsySpellweaver redundant... But true. No GUI tool can create other GUI tools in such a way... – ItamarG3 Jun 19 '17 at 6:18
• Never specify the error message? Failed to copy file XY...Z.png: filename too long. You can easily get this one (paraphrased) in Windows Explorer. – Ruslan Jun 20 '17 at 16:07
• @Ruslan thanks for the feedback. You're right. I have edited my answer accordingly (I'll probably add more edits to address that soon ;)) – ItamarG3 Jun 20 '17 at 16:09
• The word "apply” in the first sentence, seems redundant, and makes no sense to me. – ctrl-alt-delor Jun 9 '19 at 18:02

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.

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.

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.

• While this does demonstrate that command line is better than punching cards, it doesn't demonstrate that it's better than GUI. – Ruslan Jun 20 '17 at 16:08

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.

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.
• ... I like being able to scroll through the history of previously executed commands. – Dave Russell Aug 5 '17 at 10:34