There are a specific set of skills required to learn how to use the terminal - a combination of knowing when and how to read man pages, when to look up Stack Overflow, when to look up YouTube videos, and where to hang out to learn about more esoteric commands exist like `parallel`.
Without those skills - and there is no recommended path on how to get them - the terminal is unusable. It isn't a case of people thinking it is hard, it is actually logically impossible to learn how to learn terminal commands without getting lucky at the start.
Software has two phases - a learning phase and a using phase. A lot of great software ideas died quietly because there wasn't a sanctioned route to scale the learning curve.
[0] Or this classic: https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page:
>Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes.
>This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.”
In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all.
The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it.
Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.
I think that's because casual users did not learn how to look at a terminal. If you start `vim`, it shows you a few lines that say "type :help for help". The help starts with "how to move around" and "how to quit". But people ignore that.
One could say "people don't ignore it, it's just not intuitive". But I have seen many casual users struggle with GUIs, too. The difference, IMO, is just that they learned the basics of GUIs, and never had to learn the basics of CLI. I don't really believe in something fundamentally harder with CLIs.
A lot of great software is dismissed because people pretend there should be no such thing as a learning phase.
Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.
* There is no enforced standard for commands other than using a file name to invoke them.
* Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse.
* The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui.
* It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc...
That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).
They will only use composition if there isn’t a tool that solves the problem by itself.
Which is actually also a problem with GUIs. Many times, with a few CLI commands you can do a ton of stuff that you just cannot represent in UI without having tons of buttons...
I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.
I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
https://i.imgur.com/dxXwRzD.gifv
This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc.
I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else.
Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool.
Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead.
I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.
(if you can make an unfriendly but more consistent terminal, that'd also be a worthwhile improvement, just not for your target audience)
If you're willing to lead the horse to water, we'd be able to see if it drinks.
2. You can add cursor and mouse control to your .nanorc. I'm not sure if bash, etc have that. With that said, I have cursor enabled in my .nanorc along with a bunch of other stuff. The cursor thing.. I'm kind of confused on how you use it, but I rarely use it. It's (to me) weird. I think I just havent used it enough to really know its capabilites.
I think as a teacher it'd be super helpful to you to have a base set of dotfiles that your students just git clone when they start the class. Or even better, have them write their own and just provide them the settings you want them to enable. When I bring new SREs on board, without the base dotfiles for them to grab on day 1 it takes practically a week for someone to get setup and ready to work.
Have each of them commit their dotfiles to their own repos, probably forked from yours. That will get them familiar with github. Then try to get them to actually build out a github portfolio. I spent 6 months interviewing for a few positions last year and I was really surprised how few people had githubs with anything on them. It's not my main criteria but it's nice when someone has put effort into their gh/gitlab/etc profile and projects.
Also please teach them about filesystems. Most of the younger people (20s) I interviewed knew very little linux/containerization/filesystems.. I think the filesystem thing is from them growing up with MacOS and iPhones. They don't need to dig into anything beyond their "folders" if even that.
3. Absolutely one of my CLI annoyances here. I wrote another comment explaining why it frustrates me.
Related to your last sentence- I'd say 99% of the CLI/TUI apps I write are things that give you an easy front end (TUI and simple commands/flags) to perform backend systems tasks. So I have a ton of them as an SRE. The main reason I like to put things in a TUI and not just CLI flags is that ANYONE can hop in and use it because the options are all displayed to you front and center. You just use arrows or numbers to navigate.
I do TUI *AND* command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps.
This lets me democratize the various apps I've created and let anyone who isn't me use them. It's great.
Here's one example of my TUI+CLI apps. This is super old it's much prettier now.
YES, this is the way to go! I've written a couple of internal tools that work this way and it's the best of both worlds IMO.
More importantly, in a class of a couple hundred, somebody will find a way to get off the happy path. No matter how well you design it. Hopefully they’ll come to a teaching assistant or something, but there’s a good chance they’ll go to YouTube or something instead. In that case, it is best if their installation is as standard as possible.
Also the filesystem problem is such a thing and you have dredged up some feelings, hahaha. In particular, I think operating systems and VSCode have gotten way too good at hiding the fact that the file somebody is editing is, in fact, still in a zip archive. Until they go to save it or run it.
It is very difficult, at least initially, to even begin to discover what’s possible in a terminal environment.
There are so many important things that a new user simply needs to be taught, or they will likely never discover basic functionality - such as how to even open, read, and navigate the manual.
The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity.
GUI applications (generally) solve the initial discoverability barrier by simply showing you what’s possible.
I remember being a kid looking at DOS and wondering “what do I even do?” It was essentially a blank screen with very little indication of how to proceed. My dad had sticky notes on the monitor with the commands to enter to run games.
I never really looked at a command line again after I started using the Windows desktop until I started really learning programming after college, and it was just as daunting at first.
In the ancient times, we'd say "RTFM" to people who attempted to "discover" functionality instead of Ring the Fing M.
(to what extent have we made progress in software by standing on each others' shoulders instead of each others' toes, and to what extent have we been fortunate that the EEs have been standing on each others' shoulders this short century?)
Note that I'm not anti-discoverability in general — it's just the ticket for GUIs. I just happen to believe that attempting to make CLIs discoverable would nerf their greatest power: that single-character changes can have drastic effects on behaviour. We have high display bandwidths, even in our pockets, so why not have GUIs for infrequently used software and CLIs for power used software?
1. People have to learn the basics of the GUI. Take someone who lived 50 years without seeing a computer and show them Windows. They will have to learn that they can move the mouse, left/right click, and even move while clicking. They will have to learn that some parts of the UI are interactive (e.g. buttons) and others aren't. It is not as intuitive as people tend to imply. My father still double-clicks on elements that - to me - obviously don't require a double click (like a hyperlink). And many people are completely lost if you move them from their Windows to macOS or some Linux UI. Or even between two flavours of Android.
2. Once you know the basic of GUI ("there is a start menu", "I can click on buttons", ...), the UI does not show you that there exists apps like Photoshop to edit pictures, or like Slack to talk to people. You have to somehow learn about the app from somewhere, install it, and only then you get their UI that "shows you what's possible".
I would argue that the CLI is actually quite similar. Once you have learned the basics ("I can change directory", "I can `man cmd`"), then you have to discover apps somehow (e.g. a friend saying "install git with `apt install git`"), and then you can just open the manual with `man git`, and it will most definitely show you what's possible.
The difference, I think, is that people generally don't really want to learn the CLI (it "looks old", I guess?), and many apps don't provide proper manpages (pretty sure most developers don't know how to even create manpages, or package their app for their distro).
With a CLI you have absolutely nothing. There is nothing to see at all, nothing to even begin to interact with to discover the capabilities.
I kindly disagree :-): I would say that with the CLI you have the exact equivalent: man pages.
Just like for a GUI you have to know that by hovering the cursor about an icon you will get some text description, with a CLI you have to know that there are man pages. And just like a bad GUI may have cryptic icons without any description text, a bad CLI will have no manpage. But we should compare a good GUI to a good CLI, to be fair.
[0] admittedly a holdover from the typewriter, but even presented only a keyboard and a screen I've had a kid realize that one special key makes the words go vertically instead of horizontally.
In most GUI applications I can at least find the word “help” of I look around.
Unless the GUI uses some material style nonsense. Then you have to guess where buttons are. Menus are so uncool. Every modern emacs distro starts with disabling them. Mobile apps have replaced the menubar with the hamburger button by necessity. Modern desktop GUIs have copied that despite it clearly being worse on a desktop than a menubar.
The DOS we had came with a few-hundred page manual. The same for any major programs that ran on it. These must have been exhaustive, as I don't remember being stuck at any point, honestly.
Once you learn "man" and "man -k" the cli environment is emminently explorable, and it's not just "try poking at it and see what it does" it's all laid out in written documents that you can read in advance.
I dunno if it is all as high as it appears. I learned to navigate and use Unix type systems in the mid 90s, with only terminal access.
Internet was practically non existent and gopher was still (barely) in active use.
So, yeah, for a start, I don't know if extensive online resources are necessary. For example, I learned most of bash from the bash manages.
If I was to actually use this in a real system, I'd definitely build a restricted shell to execute in, and probably run it inside a Docker container with just the essential files mapped in, because I don't trust an LLM not to describe what it's doing as "updating timestamps" or whatever but actually the command is "rm -rf ~"
uxterm -xrm '*VT100.translations: #override !<Btn1Down>: vi-button() readline-button()'One of the interesting things Plan 9 did differently is that its terminal is rather more like a standard graphical text editor that happens to have the ability to execute a line. As someone used to unix terminals this was super jarring, but I can see where it would be nice.
The obvious solution here is that people who don't like precision can pay people who do to wrangle CLIs on their behalf.
1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that)
2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc.
3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy.
But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.