<p>Here in 2023, I'd be asking &quot;does the command line <em>even have</em> value?&quot;</p>
<p>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.</p>
<p>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.</p>
<p>It seems there would be no justification for routinely teaching any of the details of command-line environments nowadays.</p>
<p>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.</p>

CC BY-SA 4.0
2023-03-18T13:13:44.130Z
2023-03-18T13:13:44.130Z
Steve
<p>You can't <em>teach</em> the value of the command line. You can, however, <em>sell</em> it.</p>

<p>Students have at least one of two primary goals in any class:</p>

<ul>
<li>Get good grades (pass the class)</li>
<li>Learn something they like</li>
</ul>

<p>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 <em>value</em>. For the students that are interested in learning the subject, the command line <em>can</em> become valuable.</p>

<p>People make <em>value</em> judgments "<a href="http://www.econlib.org/library/Topics/College/margins.html" rel="noreferrer">on the margin</a>," 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.</p>

<p>Your students have a limited amount of time and effort they are willing to devote to learning material from <em>all</em> their classes. They will always do a <a href="https://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis" rel="noreferrer">cost benefit analysis</a> 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 <em>think</em> 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, <em>yes</em>, it will involve substantial effort to learn. We know the utility of it, they don't. Yet.)</p>

<p>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 <em>anytime</em> you can, even when you'd rather use a GUI personally. Organizing your files, creating directories, doing configurations, etc. If the CLI is your <em>goto</em> 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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-08-16T17:23:40.593Z
It won't be _like_ learning an additional programming language, it _is_ a programming language.
Solomon Slow
CC BY-SA 3.0
2017-06-21T00:23:39.450Z
2017-06-21T00:23:39.450Z
Gypsy Spellweaver
<p>The <strong>value</strong> of the command line can clearly be demonstrated by looking at a simple gui configuration task, which might take 5 or 10 screenshots, <em>and still be ambiguous</em> in comparison to 'open a shell and paste these 2 lines of text'.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-06-21T05:57:59.290Z
But we always teach to *never* paste text from a browser onto the command prompt directly.
JDługosz
CC BY-SA 3.0
2017-06-19T08:28:42.190Z
2017-06-19T08:36:45.740Z
2017-06-19T08:36:45.740Z
Sean Houlihane
<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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</p>

<p><strong>PS:</strong></p>

<p>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</p>

CC BY-SA 3.0
2017-06-19T20:52:38.480Z
Nice, detailed, thoughtful answer. You will do well here. ;-) Welcome to CSE!
Ben I.
CC BY-SA 3.0
2017-06-19T21:56:15.867Z
Big + for mentioning the coolness factor.
vacip
CC BY-SA 3.0
2017-06-19T20:33:08.003Z
2017-06-19T20:45:59.547Z
2017-06-19T20:45:59.547Z
Maxim
<p>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.  </p>

<p>Off the top of my head, the reasons to use a CLI over a GUI are </p>

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

<p>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 <a href="https://github.com/vhpoet/facebook-cli" rel="noreferrer">one of several fb cli on github</a>.</p>

<p>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.</p>

CC BY-SA 4.0
2019-06-09T18:41:49.413Z
CLI programs, can also be embedded in a GUI program.
ctrl-alt-delor
CC BY-SA 3.0
2017-06-20T04:20:29.933Z
2017-06-20T04:20:29.933Z
AlwaysLearning
<p>I can't speak to cloud9 but I've always taught on Linux and am a CLI wonk. </p>

<p>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.</p>

<p>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.</p>

<p>I try to model this over the course of my classes and I try to provide examples.</p>

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

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

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

<p>I wrote a few blog posts over the years with examples including:</p>

<ul>
<li>pre-processing and cleaning up dirty downloaded data</li>
<li>processing info from google forms (downloaded as csv)</li>
<li>operating on many files across directories</li>
</ul>

<p>The posts can be found here: <a href="https://cestlaz.github.io/categories/cli/" rel="noreferrer">https://cestlaz.github.io/categories/cli/</a></p>

CC BY-SA 3.0
2017-06-19T08:42:28.367Z
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](https://unix.stackexchange.com/q/131766/22222). *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](http://mywiki.wooledge.org/ParsingLs) iii) very fragile (if you *must* parse `ls`, at least use `while -r` and  [quote your variables](https://unix.stackexchange.com/q/171346/22222).
terdon
CC BY-SA 3.0
2017-06-19T08:51:01.963Z
Aso the `f=\`basename $i .gif\`` would be better expressed as `f=$(basename "$i" .gif)` or, even better, without calling an external command at all: `f=${var%%.gif}`.
terdon
CC BY-SA 3.0
2017-06-19T10:01:27.167Z
@terdon I agree with you, but if my years in academia taught me something is that almost every snippet provided by a teacher includes: i) no error check/recovery, ii) at least two minor/one major bad practices, iii) failure in every slightly edge(ish) case, iv) (optional) it doesn't work at all as written. So... the example is pretty much perfect. Very "academy".
xDaizu
CC BY-SA 3.0
2017-06-19T10:12:34.890Z
@terdon - yes, but sometimes, honestly not in the real world and the distinction is worth talking about in class. This is an interactive throwaway and it wouldn't be typed in with just an enter.The line that actually does stuff - convert - would first be done with "echo" to check the command before running. Beyond that I'd leave it as is since it would have been tested on it's specific use and would work and it got the job done.

I did have a couple of mistakes above (which the echo line would have caught had I done this in  a shell) - I fixed those now for "post correctness."\
Mike Zamansky
CC BY-SA 3.0
2017-06-19T10:21:48.220Z
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
CC BY-SA 3.0
2017-06-19T11:00:09.963Z
@terdon - yes, for my purposes it will. I don't put spaces in my filenames - if If that were possibly the case when I used it, I would have quoted.

On the other hand, I've had cases where the for doesn't work as well as the while. 

More complex and daunting is also a subjective measure.

I gain tremendously from my use of the command line hence it's worth doing for me. If some other way of going about working is easier for you, that's fine for you but the easiest solution is the one that you come up with.
Mike Zamansky
CC BY-SA 3.0
2017-06-19T11:11:14.593Z
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
CC BY-SA 3.0
2017-06-19T11:39:56.497Z
There are contexts where they behave differently - that's  how, many years (decades) ago I learned about the while when my first exposure was a for. 

The original question was about command line --throw away by definition - not writing script.

Don't worry about my students, they do fine - actually much more than fine.
Mike Zamansky
CC BY-SA 3.0
2017-06-19T13:10:11.970Z
@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
CC BY-SA 3.0
2017-06-19T16:09:31.110Z
@Peilonrayz well, as I said I would prefer a simpler example to get the point across, so I sort of agree there.  To keep with the intent of his answer I probably would start with something like "delete all css files that have FIZZBAR at the start of the file name and have -tmp in the name, so that something as simple as "rm FIZZBAR*-tmp*.css" could be used as a trivially easy example that would still be hard to do a GUI if enough files were present and a simple sorting on name would still mix in different files.  Still the *point* of the answer is good, no need to nit pick his exact example
dsollen
CC BY-SA 3.0
2017-06-19T16:53:36.797Z
You also can't know the context of a lesson just from my answer and  what any teacher does w/r to "best practices" - There are plenty of "best practices" in teaching which are ignored by many of the best teachers I know and there are plenty of "best practices" in teaching which due to the reality a teacher lives in aren't always indeed best or do-able. Same for programming / CS.
Mike Zamansky
CC BY-SA 3.0
2017-06-19T17:06:17.773Z
Also to add a bit more context -- when I wrote the answer, I didn't want to repeat any of the material in the blog posts I linked to and that was the first thing that came to mind :-)
Mike Zamansky
CC BY-SA 3.0
2017-06-19T17:44:46.347Z
*gets slightly confused as to why this comment thread has turned into Code Review*
CalculatorFeline
CC BY-SA 3.0
2017-06-19T17:57:18.430Z
@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
CC BY-SA 3.0
2017-06-20T18:16:05.847Z
You can accomplish your image-resizing example in macOS Automator using just drag-and-drop.
200_success
CC BY-SA 3.0
2017-06-21T15:15:55.397Z
@terdon I'm not much of a Bash expert, but from the experience I do have I'd say it's much better to teach piping to `while` than starting with `for` loops. For one thing, it's actually _easier_ to remember (just one keyword, together with commands that one often uses on their own right from the command-line, whereas `for` with its many pseudo-syntax bracket variants is a rather weird beast). But more importantly, it's a better introduction to the general Unix spirit of using pipes for data flow, whereas for-loops are more of an imperative-programming staple.
leftaroundabout
CC BY-SA 3.0
2017-06-21T15:19:33.017Z
@leftaroundabout it depends on what you are doing. Piping to while is a great way to process things line by line, yes. It is not, however, a good way to iterate over files. I don't know what you mean by "pseudo-syntax bracket variants", I think you might be confusing `for` with the `test` keyword (which is an alias for `[` in POSIX shells and which, in turn, has been extended by the bash-specific `[[` keyword). In any case, you should always use the right tool for the job and that isn't always `while`. By the way, [unix.se] is a great place for this sort of question >:)
terdon
CC BY-SA 3.0
2017-06-21T15:28:28.643Z
@terdon well, the best tool may, technically, always be a custom C program that does exactly the task you need in fastest time. But clearly that's not _practical_ for most applications where shell utilities work just fine. And the combination of pipes, simple fundamental commands, and combinators like `while` can get you pretty far without needing to learn a lot of syntax. `for` by itself does _not_ get you very far; together with `test` in its confusing disguise it does get you much further, but this isn't really something you _need_ to know to get good stuff done on the CLI.
leftaroundabout
CC BY-SA 3.0
2017-06-21T15:32:29.910Z
@leftaroundabout I am afraid you are paying `for` a disservice. It is fully as useful as `while` and has no odd syntax whatsoever. No more than `while`. You have probably seen it combined with `$(())` arithmetical stuff and *that* is absolutely weird syntax but has nothing to do with `for`. For example, I spent years using the shell before ever learning that `while` existed and was perfectly happy with `for`. If anything, it is more versatile, not less. In any case, let's take this to [/dev/chat](http://chat.stackexchange.com/rooms/26/dev-chat) so we don't spam this answer.
terdon
CC BY-SA 3.0
2017-06-18T21:48:17.247Z
2017-06-19T10:08:29.173Z
2017-06-19T10:08:29.173Z
Mike Zamansky
<p>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:</p>

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

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

<ol>
<li>Move any text file that contains the word "business" or "work" to a directory called "work"</li>
<li>Select all the audio files and move them to their own "music" directory.</li>
<li>Select all the images and move them to their own "images" directory.</li>
<li>Compress all audio files that are larger than 2MB into a zip or gzip.</li>
<li>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.</li>
</ol>

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

<pre><code>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 \;
</code></pre>

CC BY-SA 3.0
2017-06-19T04:54:37.950Z
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.
CC BY-SA 3.0
2017-06-19T06:36:49.640Z
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
CC BY-SA 3.0
2017-06-19T07:48:07.333Z
To be fair, that script doesn't look "easy" to come up with.
jpmc26
CC BY-SA 3.0
2017-06-19T08:40:23.983Z
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
CC BY-SA 3.0
2017-06-19T09:59:10.027Z
`s/easily/efficiently`
Baldrickk
CC BY-SA 3.0
2017-06-19T10:00:13.713Z
@GypsySpellweaver that's why you (as someone who knows the CLI) would 'race' them to do the same task concurrently (on different machines)
Baldrickk
CC BY-SA 3.0
2017-06-19T10:03:03.780Z
Addition to the workload - make it nested directories with mixed content, and different rules for each. (e.g. pics in 'business' folder go to the 'work' directory, others go to the images/photo album directory).  Command line only needs a glob, the gui user will have to navigate between them
Baldrickk
CC BY-SA 3.0
2017-06-22T06:22:09.417Z
_(reposting)_ Some more examples of "fun" tasks: Copy files from a directory to another from a list (see my script [here](https://stackoverflow.com/a/41122601/3258851)), concatenate two mp4 files without re-encoding (see [here](https://stackoverflow.com/q/7333232/3258851)), causing the watchdog timer to reboot the system (see [here](https://unix.stackexchange.com/q/372376/154671)), watching Star Wars IV: A New Hope from Telnet (address: towel.blinkenlights.nl), etc.
Marc.2377
CC BY-SA 4.0
2023-03-11T10:54:48.873Z
There are two definitions of "easy to use": Meaning 1 (not the one used in this post), is easy to learn. Meaning 2 is 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.
ctrl-alt-delor
CC BY-SA 3.0
2017-06-19T04:49:40.243Z
2017-06-19T04:49:40.243Z
DaniG2k
<p>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:</p>

<p>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.</p>

<p>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.</p>

<p>Edit: I found the answer I was mentioning on UX, so credit to @ShreevatsaR there: <a href="https://ux.stackexchange.com/a/102018/102548">https://ux.stackexchange.com/a/102018/102548</a> &ndash; also there is a longer article from 1996 linked and quoted there, which might be worth reading: <a href="https://www.nngroup.com/articles/anti-mac-interface/" rel="noreferrer" title="The Anti-Mac Interface by Jakob Nielsen">The Anti-Mac Interface by Jakob Nielsen</a></p>

CC BY-SA 3.0
2017-06-20T10:38:31.630Z
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](https://cseducators.stackexchange.com/questions/860/how-do-i-convince-my-students-that-visual-programming-is-real-programming)? Welcome to CSE. I hope we hear more from you!
Ben I.
CC BY-SA 3.0
2017-06-20T11:01:06.057Z
@BenI. I found an linked the source - has a longer article linked, you might be interested.
kratenko
CC BY-SA 3.0
2017-06-20T22:27:16.260Z
+1 from me :-) Glad to have successfully spread this nice analogy to at least one person.
ShreevatsaR
CC BY-SA 3.0
2017-06-21T05:31:20.520Z
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
CC BY-SA 3.0
2017-06-20T10:01:07.267Z
2017-06-20T11:00:13.850Z
2017-06-20T11:00:13.850Z
kratenko
<p>The are a couple of things that make the command line superior to GUI interfaces:</p>

<h1>Command history</h1>

<p>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 <code>^R</code> 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.</p>

<p>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...)</p>

<h1>Pipes</h1>

<p>Piping the output of one command into the next makes for powerful combinations.</p>

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

<p>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! :)</p>

<pre><code>md5sum * &gt;checksums
sort checksums | cut -f1 | uniq -c | grep -v '^ *1 ' | sed 's/^.* //' &gt;doubled
grep -fdoubled checksums
</code></pre>

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

<h1>Scriptability</h1>

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

<p>Stuff like <code>while read LINE; do ...; done &lt;FILE</code> and <code>for *.txt; do ...; done</code>, and functions are really all nifty stuff.</p>

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

<pre><code>trim() { sed 's/^ *//; s/ *$//' }
</code></pre>

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

<h1>Language-Like Fluency</h1>

<p>The <em>scriptability</em> and <em>pipes</em> points above combine to something new and powerful, which I usually compare to language fluency.</p>

<p>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 <em>that</em> menu, to get <em>that</em> window to pop up, so I can select <em>that</em> tab, which does what I want." – You're forever <em>navigating</em> around, using recognition to see where you are and what your options are right here.</p>

<p>A CLI, on the other hand, gives you a <em>language</em>. 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 <code>trim</code> function above).</p>

<p>Some of this language you use often, and so it becomes part of your active vocabulary (<code>ls</code> and <code>cd</code> 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.</p>

CC BY-SA 3.0
2017-06-20T21:37:55.223Z
2017-06-20T21:37:55.223Z
zrajm
<p>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.</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2017-06-20T14:00:25.193Z
Black and white? *Real* programmers have green text.
Scimonster
CC BY-SA 3.0
2017-06-20T14:06:12.333Z
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
CC BY-SA 3.0
2017-06-20T15:53:26.480Z
Did someone say *green*? (I make these jokes all the time, but this is the first time I do it on SE :P)
ItamarG3
CC BY-SA 3.0
2017-06-21T16:35:18.740Z
@Scimonster I think I'm an _unreal_ programmer...
Ruslan
CC BY-SA 3.0
2017-07-29T21:50:21.173Z
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
CC BY-SA 3.0
2017-07-30T17:33:24.540Z
I have had several 6th grade Python students who have been drawn to the command-line because of the coolness factor.
Greg Graham
CC BY-SA 4.0
2017-06-20T13:40:58.933Z
2019-06-09T18:23:33.253Z
2019-06-09T18:23:33.253Z
Kaneki
<p>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. </p>

<p>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, <code>cd /var/www/html</code> is a lot faster than:  </p>

<ul>
<li>click the file manager</li>
<li>navigate up to <code>/</code></li>
<li>click <code>var</code> (wait for loading)</li>
<li>click <code>www</code> (wait for loading)</li>
<li>click <code>html</code> (wait for loading)</li>
</ul>

<p>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.</p>

CC BY-SA 4.0
2019-06-09T18:31:32.017Z
`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
CC BY-SA 3.0
2017-06-19T13:24:14.777Z
Welcome to CSE, gabe3886! This is a great point. I hope we hear more from you in the future.
Ben I.
CC BY-SA 3.0
2017-06-20T16:03:14.870Z
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
CC BY-SA 3.0
2017-06-19T08:26:01.103Z
2017-06-19T08:26:01.103Z
gabe3886
<p>Simply put: the command line can do things which the GUI apply <strong>cannot</strong>. In Windows this is easily seen. CMD can perform operations that no other <em>GUI based</em> tool can. </p>

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

<p>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). </p>

<p>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. </p>

<p>Additionally, the terminal can override anything.</p>

CC BY-SA 4.0
2019-06-09T18:04:13.280Z
Show example of error messages from Windows RG, it is an exaggeration (but only a little), https://www.youtube.com/watch?v=YbEYOaO9kp4
ctrl-alt-delor
CC BY-SA 3.0
2017-06-19T06:16:23.907Z
They can always use CLI to create a GUI :)
Gypsy Spellweaver
CC BY-SA 3.0
2017-06-19T06:18:38.467Z
@GypsySpellweaver redundant... But true. No GUI tool can create other GUI tools in such a way...
ItamarG3
CC BY-SA 3.0
2017-06-20T16:07:31.723Z
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
CC BY-SA 3.0
2017-06-20T16:09:41.880Z
@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
CC BY-SA 3.0
2017-06-19T06:13:03.463Z
2017-06-20T16:09:03.970Z
2017-06-20T16:09:03.970Z
ItamarG3
<p><strong>Here, take this pen. Now sell it to me.</strong></p>

<p>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.</p>

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

CC BY-SA 3.0
2017-06-19T12:23:29.933Z
This is a good point. Welcome to CSE! I hope we hear more from you in the future.
Ben I.
CC BY-SA 3.0
2017-07-29T21:47:30.877Z
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
CC BY-SA 3.0
2017-06-19T12:17:48.890Z
2017-06-19T12:17:48.890Z
Klangen
<p>These are some experiences I've had, highlighting the power of the command line:</p>

<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>Also, you can set or change any configuration settings on a command line.</li>
<li>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.</li>
<li>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.</li>
</ul>

<p>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.</p>

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

CC BY-SA 3.0
2017-06-19T16:37:28.723Z
Nice answer. Welcome to CSE!  I hope we hear more from you :)
Ben I.
CC BY-SA 3.0
2017-06-19T16:23:57.680Z
2017-06-19T16:23:57.680Z
s0s
<p>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.  </p>

<p>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.   </p>

<p>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.  </p>

CC BY-SA 3.0
2017-06-20T21:10:00.363Z
2017-06-20T21:10:00.363Z
ncmathsadist
<p>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.</p>

<p>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.</p>

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

CC BY-SA 4.0
2019-06-09T18:10:14.313Z
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
CC BY-SA 3.0
2017-06-19T23:19:43.020Z
I believe it is possible to merge accounts - [try contacting the stack exchange team](https://cseducators.stackexchange.com/contact). Either way, welcome (back?) to CSE =) Thanks for your answer!
auden
CC BY-SA 3.0
2017-06-20T09:36:14.947Z
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
CC BY-SA 3.0
2017-06-19T18:31:16.390Z
2017-06-20T10:40:12.620Z
2017-06-20T10:40:12.620Z
s0s
<p>There have been some great answers so far; here is an approach I haven't seen described yet.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-08-04T18:58:36.513Z
2017-08-04T18:58:36.513Z
Joel Adams
<p>Infrastructure as Code.</p>

<p>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.</p>

CC BY-SA 3.0
2017-06-19T14:49:12.913Z
2017-06-19T14:49:12.913Z
sherenator
<p>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.</p>

CC BY-SA 3.0
2017-06-20T16:08:37.907Z
While this does demonstrate that command line is better than punching cards, it doesn't demonstrate that it's better than GUI.
Ruslan
CC BY-SA 3.0
2017-06-19T00:29:19.167Z
2017-06-19T00:29:19.167Z
hotpaw2
<h1>CLI vs GUI</h1>
<h2>CLI</h2>
<ul>
<li>Easier to use</li>
<li>Easier to learn</li>
<li>Better for instructing computer what to do.</li>
</ul>
<h2>GUI</h2>
<ul>
<li>Easier to use</li>
<li>Easier to learn</li>
<li>Better for visualising: looking at images, charts, graphs, etc.</li>
</ul>
<h2>Easy to use</h2>
<p>There are two definitions of &quot;easy to use&quot;</p>
<ul>
<li><p>Meaning 1: easy to learn.</p>
</li>
<li><p>Meaning 2: easy to do for someone with experience.</p>
</li>
</ul>
<p>We often get stuck in the local minima of meaning 1, and don't put in the effort to achieve meaning 2.</p>
<h2>Easy to learn</h2>
<p>There are two definitions of &quot;easy to learn&quot;</p>
<ul>
<li><p>Meaning 1: Without reference to manuals or examples, a learner can figure it out by playing with the tool.</p>
</li>
<li><p>Meaning 2: easy to figure out by examples.</p>
</li>
</ul>
<h3>Easy to learn — meaning 2</h3>
<p>E.G.</p>
<p>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.</p>
<p>Therefore, I can give students examples (heading, bullet lists, etc). Students can study these, and try them out for themselves.</p>

CC BY-SA 4.0
2023-03-11T11:22:42.897Z
2023-03-11T11:22:42.897Z
ctrl-alt-delor
<p>Have some reasons why they should use the command line. Here are some of mine.</p>

<h1>Why I like the command line</h1>

<h2>Less typing</h2>

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

<p>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.</p>

<p>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.)</p>

<p>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.)</p>

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

<h2>Unambiguous and clear</h2>

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

<h2>Easier for dyslexics (sometimes)</h2>

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

<h2>More powerful</h2>

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

<h2>Faster over remote connections</h2>

<p>Opening a window over ssh can be slow.</p>

<h2>Automation</h2>

<p>If you can do it once, then you can do it again, with scripting.</p>

<h2>GUI-able</h2>

<p>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.</p>

<h1>Why I like the GUI</h1>

<ul>
<li>Better visualisation.</li>
<li>Easier for beginners, and infrequent users.</li>
</ul>

<h1>A Compromise</h1>

<p>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.</p>

CC BY-SA 4.0
2017-07-30T09:30:45.240Z
2019-06-09T18:15:01.970Z
2019-06-09T18:15:01.970Z
ctrl-alt-delor
<blockquote>
  <p>Are there specific examples you use that effectively illustrate the
  power of a CLI</p>
</blockquote>

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

<p>A few practical situations and benefits of having a CLI:</p>

<ul>
<li>In a mixed platform environment you can access all other servers  from a single desktop or other terminal. Even from your phone.</li>
<li>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.</li>
<li>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.</li>
</ul>

CC BY-SA 3.0
2017-08-05T10:34:42.467Z
... I like being able to scroll through the history of previously executed commands.
Dave Russell
CC BY-SA 3.0
2017-08-05T10:22:40.460Z
2017-08-05T10:22:40.460Z
Dave Russell
<p>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 <code>cp</code>, <code>mv</code>, <code>mkdir</code>, <code>cd</code>, <code>ls</code>, and <code>zip</code> (just to name a few).</p>

<p>However, at the beginning of the year, it is challenging to motivate <em>why</em> 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.</p>

<p>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?</p>

<p><strong>Note:</strong> This question is not a duplicate of <a href="https://cseducators.stackexchange.com/questions/153/command-line-java-in-ap-cs-a">Command-line Java in AP CS A</a> (although it is tangentially related) as that question asked whether or not a CLI <em>should</em> be taught in AP CS A. This one is focusing on how it can be motivated when it <em>has</em> to be taught regardless of course.</p>

CC BY-SA 3.0
2017-06-19T07:45:10.073Z
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
CC BY-SA 3.0
2017-06-19T13:21:58.703Z
Show "useful", "cool", "fun" things. Student attention span is not very different from goldfish if topic is deemed boring and/or useless. For example: typical file manipulation from command line have little value if you can do it faster with mouse - that's how normal people think. To be honest, all examples given so far in answers would bore me ;)
PTwr
CC BY-SA 3.0
2017-06-19T14:50:25.860Z
@jpmc26 Is there a good example of said drudgery that might speak to students just getting familiar with a CLI?
Peter
CC BY-SA 3.0
2017-06-19T14:51:13.273Z
@PTwr Is there something "cool" or "fun" that would be a good demo for students in your opinion? That's the needle in a haystack I'm looking for.
Peter
CC BY-SA 3.0
2017-06-19T16:16:05.460Z
@Peter "hacking" routes to redirect facebook to some stupid page, shell as calculator, starting old game with DosBox, [confusing hard/symbolic links](https://xkcd.com/981/), [command porn](https://gist.github.com/syranez/3981941), 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](https://xkcd.com/1050/), don't teach them trigonometry, show them how to do taxes :)
PTwr
CC BY-SA 3.0
2017-06-19T22:48:17.683Z
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?](http://lifehacker.com/373571/watch-star-wars-in-text-via-telnet)  ([Video version here if you can't run telnet](http://www.asciimation.co.nz/))
Cody
CC BY-SA 3.0
2017-06-20T22:06:50.310Z
Possibly relevant link: [Why are terminal consoles still used?](https://ux.stackexchange.com/questions/101990/why-are-terminal-consoles-still-used) (Disclaimer: One of the answers there is mine.)
ShreevatsaR
CC BY-SA 3.0
2017-06-21T03:15:50.827Z
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-
CC BY-SA 3.0
2017-06-21T14:19:11.200Z
You could give them a small task that they would have to complete every day. Something like creating a file with their name and current date and then upload it to a FTP server. I think that will motivate them to create a script that does it for them and even setup a cron job to automate the process.
pikand
CC BY-SA 3.0
2017-07-21T23:14:05.793Z
Less typing, easier to answer questions, on stack exchange, more powerful. See also https://askubuntu.com/questions/106039/so-what-is-the-advantage-of-using-the-terminal
ctrl-alt-delor
CC BY-SA 3.0
2017-12-26T15:01:22.490Z
Blocking access to the command line is one of the "security" methods that our district implements. Kids, and most teachers, accounts can't access it.
Ryan Nutt
CC BY-SA 3.0
2018-04-11T12:05:46.930Z
in high school ? For people that aren't sure to be working professionally in IT later on I do fail to see any advantage. As a dev, I obvisouly value this tools, but outside of my job, I never use a command line tool as I have no specific usage for it (except for ping when my internet doesn't seem answering ...).
Walfrat
CC BY-SA 4.0
2023-03-16T06:00:36.043Z
@Peter I am facing the same problem and I asked a similar question https://cseducators.stackexchange.com/questions/7081/resource-recommendation-for-teaching-the-command-line-file-system-for-high-scho . From my experience if they never use a linux machines they can hardly appreciate the value of CLI. So I was wondering do you have new insight into this question 5 years later ?
Qiulang 邱朗
<lesson-ideas><command-line>
How to teach the value of the command line in high school?
# How to teach the value of the command line in high school?

(Asked by: username_0 on 2017-06-18)

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](https://cseducators.stackexchange.com/questions/153/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.

**Tags:** lesson-ideas, command-line

> **Comments:**
> **username_1**: 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.  
> **username_2**: Show "useful", "cool", "fun" things. Student attention span is not very different from goldfish if topic is deemed boring and/or useless. For example: typical file manipulation from command line have little value if you can do it faster with mouse - that's how normal people think. To be honest, all examples given so far in answers would bore me ;)  
> **username_0**: @username_1 Is there a good example of said drudgery that might speak to students just getting familiar with a CLI?  
> **username_0**: @username_2 Is there something "cool" or "fun" that would be a good demo for students in your opinion? That's the needle in a haystack I'm looking for.  
> **username_2**: @username_0 "hacking" routes to redirect facebook to some stupid page, shell as calculator, starting old game with DosBox, [confusing hard/symbolic links](https://xkcd.com/981/), [command porn](https://gist.github.com/syranez/3981941), 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](https://xkcd.com/1050/), don't teach them trigonometry, show them how to do taxes :)  
> **username_3**: 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?](http://lifehacker.com/373571/watch-star-wars-in-text-via-telnet)  ([Video version here if you can't run telnet](http://www.asciimation.co.nz/))  
> **username_4**: Possibly relevant link: [Why are terminal consoles still used?](https://ux.stackexchange.com/questions/101990/why-are-terminal-consoles-still-used) (Disclaimer: One of the answers there is mine.)  
> **username_5**: 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.  
> **username_6**: You could give them a small task that they would have to complete every day. Something like creating a file with their name and current date and then upload it to a FTP server. I think that will motivate them to create a script that does it for them and even setup a cron job to automate the process.  
> **username_7**: Less typing, easier to answer questions, on stack exchange, more powerful. See also https://askubuntu.com/questions/106039/so-what-is-the-advantage-of-using-the-terminal  
> **username_8**: Blocking access to the command line is one of the "security" methods that our district implements. Kids, and most teachers, accounts can't access it.  
> **username_9**: in high school ? For people that aren't sure to be working professionally in IT later on I do fail to see any advantage. As a dev, I obvisouly value this tools, but outside of my job, I never use a command line tool as I have no specific usage for it (except for ping when my internet doesn't seem answering ...).  
> **username_10**: @username_0 I am facing the same problem and I asked a similar question https://cseducators.stackexchange.com/questions/7081/resource-recommendation-for-teaching-the-command-line-file-system-for-high-scho . From my experience if they never use a linux machines they can hardly appreciate the value of CLI. So I was wondering do you have new insight into this question 5 years later ?  

---

## 22 answers

### Answer by username_12 on 2017-06-21. Score: 15 | Accepted answer

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](http://www.econlib.org/library/Topics/College/margins.html)," 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](https://en.wikipedia.org/wiki/Cost%E2%80%93benefit_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.

> **Comments:**
> **username_13**: It won't be _like_ learning an additional programming language, it _is_ a programming language.  

---

### Answer by username_20 on 2017-06-18. Score: 22

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/

> **Comments:**
> **username_21**: 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](https://unix.stackexchange.com/q/131766/22222). *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](http://mywiki.wooledge.org/ParsingLs) iii) very fragile (if you *must* parse `ls`, at least use `while -r` and  [quote your variables](https://unix.stackexchange.com/q/171346/22222).  
> **username_21**: Aso the `f=\`basename $i .gif\`` would be better expressed as `f=$(basename "$i" .gif)` or, even better, without calling an external command at all: `f=${var%%.gif}`.  
> **username_22**: @username_21 I agree with you, but if my years in academia taught me something is that almost every snippet provided by a teacher includes: i) no error check/recovery, ii) at least two minor/one major bad practices, iii) failure in every slightly edge(ish) case, iv) (optional) it doesn't work at all as written. So... the example is pretty much perfect. Very "academy".  
> **username_20**: @username_21 - yes, but sometimes, honestly not in the real world and the distinction is worth talking about in class. This is an interactive throwaway and it wouldn't be typed in with just an enter.The line that actually does stuff - convert - would first be done with "echo" to check the command before running. Beyond that I'd leave it as is since it would have been tested on it's specific use and would work and it got the job done.  I did have a couple of mistakes above (which the echo line would have caught had I done this in  a shell) - I fixed those now for "post correctness."\  
> **username_21**: 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.  
> **username_20**: @username_21 - yes, for my purposes it will. I don't put spaces in my filenames - if If that were possibly the case when I used it, I would have quoted.  On the other hand, I've had cases where the for doesn't work as well as the while.   More complex and daunting is also a subjective measure.  I gain tremendously from my use of the command line hence it's worth doing for me. If some other way of going about working is easier for you, that's fine for you but the easiest solution is the one that you come up with.  
> **username_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.  
> **username_20**: There are contexts where they behave differently - that's  how, many years (decades) ago I learned about the while when my first exposure was a for.   The original question was about command line --throw away by definition - not writing script.  Don't worry about my students, they do fine - actually much more than fine.  
> **username_23**: @username_21 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.  
> **username_23**: @Peilonrayz well, as I said I would prefer a simpler example to get the point across, so I sort of agree there.  To keep with the intent of his answer I probably would start with something like "delete all css files that have FIZZBAR at the start of the file name and have -tmp in the name, so that something as simple as "rm FIZZBAR*-tmp*.css" could be used as a trivially easy example that would still be hard to do a GUI if enough files were present and a simple sorting on name would still mix in different files.  Still the *point* of the answer is good, no need to nit pick his exact example  
> **username_20**: You also can't know the context of a lesson just from my answer and  what any teacher does w/r to "best practices" - There are plenty of "best practices" in teaching which are ignored by many of the best teachers I know and there are plenty of "best practices" in teaching which due to the reality a teacher lives in aren't always indeed best or do-able. Same for programming / CS.  
> **username_20**: Also to add a bit more context -- when I wrote the answer, I didn't want to repeat any of the material in the blog posts I linked to and that was the first thing that came to mind :-)  
> **username_24**: *gets slightly confused as to why this comment thread has turned into Code Review*  
> **username_25**: @username_23 - 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.  
> **username_26**: You can accomplish your image-resizing example in macOS Automator using just drag-and-drop.  
> **username_27**: @username_21 I'm not much of a Bash expert, but from the experience I do have I'd say it's much better to teach piping to `while` than starting with `for` loops. For one thing, it's actually _easier_ to remember (just one keyword, together with commands that one often uses on their own right from the command-line, whereas `for` with its many pseudo-syntax bracket variants is a rather weird beast). But more importantly, it's a better introduction to the general Unix spirit of using pipes for data flow, whereas for-loops are more of an imperative-programming staple.  
> **username_21**: @username_27 it depends on what you are doing. Piping to while is a great way to process things line by line, yes. It is not, however, a good way to iterate over files. I don't know what you mean by "pseudo-syntax bracket variants", I think you might be confusing `for` with the `test` keyword (which is an alias for `[` in POSIX shells and which, in turn, has been extended by the bash-specific `[[` keyword). In any case, you should always use the right tool for the job and that isn't always `while`. By the way, [unix.se] is a great place for this sort of question >:)  
> **username_27**: @username_21 well, the best tool may, technically, always be a custom C program that does exactly the task you need in fastest time. But clearly that's not _practical_ for most applications where shell utilities work just fine. And the combination of pipes, simple fundamental commands, and combinators like `while` can get you pretty far without needing to learn a lot of syntax. `for` by itself does _not_ get you very far; together with `test` in its confusing disguise it does get you much further, but this isn't really something you _need_ to know to get good stuff done on the CLI.  
> **username_21**: @username_27 I am afraid you are paying `for` a disservice. It is fully as useful as `while` and has no odd syntax whatsoever. No more than `while`. You have probably seen it combined with `$(())` arithmetical stuff and *that* is absolutely weird syntax but has nothing to do with `for`. For example, I spent years using the shell before ever learning that `while` existed and was perfectly happy with `for`. If anything, it is more versatile, not less. In any case, let's take this to [/dev/chat](http://chat.stackexchange.com/rooms/26/dev-chat) so we don't spam this answer.  

---

### Answer by username_28 on 2017-06-19. Score: 19

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:

Move any text file that contains the word "business" or "work" to a directory called "work"
Select all the audio files and move them to their own "music" directory.
Select all the images and move them to their own "images" directory.
Compress all audio files that are larger than 2MB into a zip or gzip.
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 \;

> **Comments:**
> **username_17**: 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 ;)  
> **username_12**: 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.  
> **username_1**: To be fair, that script doesn't look "easy" to come up with.  
> **username_29**: 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...  
> **username_30**: `s/easily/efficiently`  
> **username_30**: @GypsySpellweaver that's why you (as someone who knows the CLI) would 'race' them to do the same task concurrently (on different machines)  
> **username_30**: Addition to the workload - make it nested directories with mixed content, and different rules for each. (e.g. pics in 'business' folder go to the 'work' directory, others go to the images/photo album directory).  Command line only needs a glob, the gui user will have to navigate between them  
> **username_31**: _(reposting)_ Some more examples of "fun" tasks: Copy files from a directory to another from a list (see my script [here](https://stackoverflow.com/a/41122601/3258851)), concatenate two mp4 files without re-encoding (see [here](https://stackoverflow.com/q/7333232/3258851)), causing the watchdog timer to reboot the system (see [here](https://unix.stackexchange.com/q/372376/154671)), watching Star Wars IV: A New Hope from Telnet (address: towel.blinkenlights.nl), etc.  
> **username_7**: There are two definitions of "easy to use": Meaning 1 (not the one used in this post), is easy to learn. Meaning 2 is 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.  

---

### Answer by username_32 on 2017-06-20. Score: 12

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 @username_4 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](https://www.nngroup.com/articles/anti-mac-interface/ "The Anti-Mac Interface by Jakob Nielsen")

> **Comments:**
> **username_17**: 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](https://cseducators.stackexchange.com/questions/860/how-do-i-convince-my-students-that-visual-programming-is-real-programming)? Welcome to CSE. I hope we hear more from you!  
> **username_32**: @BenI. I found an linked the source - has a longer article linked, you might be interested.  
> **username_4**: +1 from me :-) Glad to have successfully spread this nice analogy to at least one person.  
> **username_33**: 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.  

---

### Answer by username_14 on 2017-06-19. Score: 11

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.

> **Comments:**
> **username_15**: But we always teach to *never* paste text from a browser onto the command prompt directly.  

---

### Answer by username_16 on 2017-06-19. Score: 11

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

> **Comments:**
> **username_17**: Nice, detailed, thoughtful answer. You will do well here. ;-) Welcome to CSE!  
> **username_18**: Big + for mentioning the coolness factor.  

---

### Answer by username_19 on 2017-06-20. Score: 10

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](https://github.com/vhpoet/facebook-cli).

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.

> **Comments:**
> **username_7**: CLI programs, can also be embedded in a GUI program.  

---

### Answer by username_41 on 2017-06-19. Score: 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.

> **Comments:**
> **username_17**: This is a good point. Welcome to CSE! I hope we hear more from you in the future.  
> **username_7**: 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.  

---

### Answer by username_42 on 2017-06-19. Score: 8

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.

> **Comments:**
> **username_17**: Nice answer. Welcome to CSE!  I hope we hear more from you :)  

---

### Answer by username_34 on 2017-06-20. Score: 7

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  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 by username_35 on 2017-06-20. Score: 7

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

> **Comments:**
> **username_36**: Black and white? *Real* programmers have green text.  
> **username_35**: 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.  
> **username_37**: Did someone say *green*? (I make these jokes all the time, but this is the first time I do it on SE :P)  
> **username_38**: @username_36 I think I'm an _unreal_ programmer...  
> **username_7**: 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.  
> **username_39**: I have had several 6th grade Python students who have been drawn to the command-line because of the coolness factor.  

---

### Answer by username_40 on 2017-06-19. Score: 6

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.

> **Comments:**
> **username_17**: Welcome to CSE, username_40! This is a great point. I hope we hear more from you in the future.  
> **username_38**: 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.  
> **username_7**: `ssh -X` will let you run GUI programs, to display locally. (You still need to know the command-line to do it.)  

---

### Answer by username_37 on 2017-06-19. Score: 5

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.

> **Comments:**
> **username_12**: They can always use CLI to create a GUI :)  
> **username_37**: @GypsySpellweaver redundant... But true. No GUI tool can create other GUI tools in such a way...  
> **username_38**: 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.  
> **username_37**: @username_38 thanks for the feedback. You're right. I have edited my answer accordingly (I'll probably add more edits to address that soon `;)`)  
> **username_7**: Show example of error messages from Windows RG, it is an exaggeration (but only a little), https://www.youtube.com/watch?v=YbEYOaO9kp4  

---

### Answer by username_47 on 2017-06-19. Score: 4

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 by username_43 on 2017-06-20. Score: 3

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 by username_42 on 2017-06-19. Score: 3

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

> **Comments:**
> **username_44**: I believe it is possible to merge accounts - [try contacting the stack exchange team](https://cseducators.stackexchange.com/contact). Either way, welcome (back?) to CSE =) Thanks for your answer!  
> **username_45**: 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.  
> **username_7**: 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.  

---

### Answer by username_46 on 2017-08-04. Score: 3

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 by username_48 on 2017-06-19. Score: 2

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.

> **Comments:**
> **username_38**: While this does demonstrate that command line is better than punching cards, it doesn't demonstrate that it's better than GUI.  

---

### Answer by username_7 on 2023-03-11. Score: 2

# 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 by username_7 on 2017-07-30. Score: 2

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 by username_49 on 2017-08-05. Score: 2

> 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.

> **Comments:**
> **username_49**: ... I like being able to scroll through the history of previously executed commands.  

---

### Answer by username_11 on 2023-03-18. Score: 0

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.


---

