Whenever I see new coders struggle, it usually is because they:
- Don't know the context of what they are executing
- Don't know about the concept of input and output
On the command line, the context is obvious. You are in the context. The working dir, the environment, everything is the same for you as it is for the thing you execute via ./mything.py.
Input and output are also obvious. Input is what you type, output is what you see. Using pipes to redirect it comes naturally.
Not being natively connected to context, input and output is often at the core of problems I see even senior programmers struggle with.
> On the command line, the context is obvious. You are in the context
While I share the opinion that the command line is _the one true way_ of computing, I don't think this is really all that true. Computers are alien. GUIs are alien. CLIs are alien. Everything is learned. Everything is experience. Everything is culture. Learning, experience, and culture blind us from the experience of the novice. This is "expert blindness".
Not even that. Newborns have to learn how to suckle, and their mother has to learn how to hold everything in the right positions so it can work. It’s a tricky skill and many aren’t successful even if they want to breastfeed.
Newborns don't have to learn how to suckle. It's a reflex, called a suckling reflex. Lacking a suckling reflex is an indicator of disease. Basically a newborn suckles everything that goes into the mouth, nipple or not.
Are you a woman? Have you had children? Have you partnered a woman as your child and her cried through the night, both trying to make this “breastfeeding” thing work; both failing. “How can something so intrinsic to basic survival, be so hard!”. And yet it is.
Having a reflex and breastfeeding are two different things. The baby can have the reflex, but the mother has no milk or the latching technique is poor (as mentioned elsewhere in these comments). So the child not breastfeeding doesn't mean there is no reflex. And yes, the process can be painful and stressful to many mothers most especially first timers (experience also counts).
True. All interfaces are abstractions and i think the command line interface is the best one we have. It gives you the maximum power.. It does have a steep but surmountable learning curve though and the effort is usually worth it given the ubiquitous nature and programmability.
I mean yeah, you are right, it is learned, but "CLI is the one true way" for me because it is much more powerful than most GUIs I have seen. I am much more productive using the CLI, etc.
But CLI contexts are only obvious if the computer user is already familiar with the CLI which biases the learned mind to perceive things as obvious when they really are not.
A lot of CLI commands syntax are based on position instead of explicit argument names.
E.g. creating file system links via CLI has opposite syntax positions in Linux vs Windows:
If one goes back & forth between the 2 operating systems, it's easy to mis-type the wrong syntax because the CLI doesn't make it obvious. On the other hand, using a GUI file browser like Ubuntu Nautlius or Windows Explorer lets a novice create links ("shortcuts") without memorizing CLI syntax.
This gap of knowledge is also why there is copy&paste cargo-culting of inscrutable ffmpeg, git, rsync, etc commands.
E.g. using ffmpeg to covert a DVD to mp4 by manually concatenating *.VOB files has very cumbersome and error-prone syntax. It's easier to use a visual GUI like Handbrake to click and choose the specific title/chapters to convert.
CLI vs GUI superiority depends on the task and the knowledge level of the user.
When I start typing a formula in LibreOffice Calc, there is a popup showing possible matching functions, then when I choose the function, the popup shows the required syntax for the function and where I currently am within that syntax. A bash plugin that would do that would be an absolute game changer imho.
The cli excels because it is extremely flexible, with far more options available than a set of buttons could ever display. But discoverability rounds down to 0, and there are footguns. It seems like spreadsheet software has found an almost drop in ui that would greatly enhance the cli.
it's not the same thing. Tab completion is useful and will complete something you know of. But it does not help you discover something you don't know, or provide you the syntax of the command after it is entered. The problem I would like to solve is discoverability.
It's a 3 part problem: available commands, their options, their syntax. Part one would need to capture prompt input before enter was hit using solutions similar to those found at [1] perhaps the most useful but least complete one there is the one that uses apropos so something like `apropos -s 1 '' | sort | grep calc | less`. Similar solutions would be required for two and three. The roughest and easiest prototype would probably be two tabs in a split screen view, which would allow for selection of displayed matches to then modify the prompt creating those matches in the other tab. But Calc style popups directly attached to your cursor would be more useful still.
Everything is "easy" when someone else is doing it for you. Results are best when you develop and apply your own expertise to a problem, but it's not feasible to do that for every problem domain -- relying on others is often important.
I'ts just that if I'm going to rely on someone else, I'd prefer for that someone else to be one of the people who has developed and applied their own expertise to that problem domain, rather than a statistical model that only actually knows how likely words are to appear in proximity to each other, and has no capacity to validate its probabilistic inferences against the outside world.
When some big shit hits the fan either with ChatGPT or internet connections, the only people able to fix systems without an internet connection will be us, the millenials.
I've found that as far as generational cohorts go, the most adept people are the late Gen-Xers and very early Millenials -- the people who grew up surrounded by C64s and Apple IIs and later had to fiddle with their config.sys and autoexec.bat files to get their game to fit into conventional memory.
People whose first exposure to computing was in the mid-'90s or later seem to have less depth of understanding of the fundamentals and less experiencing tinkering and using process of elimination to solve problems. I started encountering people who didn't understand certain fundamental concepts and had no exposure to the CLI, but still had CS degrees and were applying for developer positions, about 15 years ago.
Yeah, these too. But lots of millenials learnt with RedHat, Debian and they knew a bit of DOS for some issues with Windows 98 and potential recovering from disasters.
Still, far more able than the ChatGPT aided people blindly pasting commands into a shell being a recipe for a huge disaster.
- Debian/Devuan/Gnuinos users with offline DVD's ISOs mirrored under an USB drive: easy mode.
Most of the docs are already there, just mount the ISO's as a loopback device and run apt-cdrom add against the mount points.
- Windows user: hell.
Ubuntu/Arch/any distro without full ofline mirrors: hell too.
Yep, I ran a short "introduction to the command line" course for the devs in my team. Afterwards, I noticed that their usage of the vscode terminal was much higher, and folks were more comfortable exploring on their own.
Quick outline of the course, in case anyone wants a starting point:
* Introduction
Quick history of Unix
* When you log in
Difference between login and interactive shells
System shell files vs user shell files
.zshenv for environment variables like PATH, EDITOR, and PAGER
.zprofile for login shells, we don't use it
.zshrc for interactive shells
Your login files are scripts, and can have anything in them
* Moving Around
** Where am I?
pwd = "print working directory"
stored in variable $PWD
Confusingly, also called current working directory, so you may see CWD or cwd mentioned
** What is here?
ls
ls -al
ls -alt
. prefix to filenames makes them hidden
. is also the current directory!
.. means the parent directory
file tells you what something is
cat displays a file
code opens it in vscode
** Finding my way around
cd
cd -
dirs | sed -e $'s/ /\\\n/g'
** Getting Help From The Man
man 1 zshbuiltins
manpage sections
** PATH
echo $PATH | sed -e $'s/:/\\\n/g'
zshenv PATH setting
which tells you what will be run
** Environment Variables
env | sort
EDITOR variable
** History
ctrl-r vs up arrow
** Permissions
Making something executable
** Prompts
zsh promptinit
zsh prompt -l
** Pipes and Redirection
Iterate to show how pipes work
cat ~/.zshrc | grep PATH
ls -al > ~/.tmp/ls-output.txt
** Commands
*** BSD vs GNU commands
BSD are supplied by Apple, and Apple often uses old versions
GNU are installed via homebrew, and match those commands available in Linux
My first real programming experiences was done through the browser’s console (JavaScript) and IDLE’s REPL (Python). The short feedback cycle works wonder for understanding instead of struggling to the multistep process of C compilation or Java verbosity. I tried my hands at reverse engineering and using a dissassembler like IDA also gives the same immediacy feeling. Great DX for me is either a good debugger or a proper REPL whatever the abstraction level.
I agree with you, but I think there's a caveat. The command line is king in Linux, BSD, MacOS, AIX, and to a lesser extent Windows. These operating systems were crafted from the bottom up with the commandline as a foundational layer. The idea of the context, of the "working directory", the "environment", were concepts that were lifted from that commandline centric world, into what we run now.
I think Windows very much wanted to be something different with COM. Instead of starting a shell in the context of the program, you'd connect some external "shell" into the very object graph if your program to inspect it. It turns out to be very difficult, and Windows has largely retreated to commandline centric architecture, but I think there was some essential attempt at foundational innovation there.
I would argue that the commandline has very much proven to be the best trade-off between being useful and being simple, but there is no saying if there exists some alternative.
Not every version of MacOS. Classic MacOS, System 1-7 and MacOS 8-9, were definitely not crafted with the command line environment as a foundational layer. Using it was like being wrapped in several layers of bubble wrap. You were trapped in the GUI and if you wanted to do something the GUI didn't allow for, you were "using it wrong".
> The command line is king in Linux, BSD, MacOS, AIX, and to a lesser extent Windows. These operating systems were crafted from the bottom up with the commandline as a foundational layer.
MacOS is a very complete, very well funded desktop environment targeted towards the general user. You want anything extras and you land in applications using private apis and the command line.
The foundation of macOS contains elements of UNIX (or rather BSD) and the OS is UNIX certified, I‘m fully aware of that. But these are two different things.
For one thing, UNIX != command line.
In the same vein, Windows NT is not based on DOS anymore, even if it has a command line which resembles (parts of) DOS.
The more experience I accumulate, the more I rely on GUIs. Explanation: when I was younger I used exclusively the CLI and underestimated GUIs. Now I tend to appreciate GUIs and use them more.
AutoCAD is an unlucky choice of example here, because it's one of the few GUI drawing tools that actually does have a command line behind it that you have to understand sometimes! Look up a screenshot of AutoCAD and you can see the command prompt at the bottom of the window.
And if you were using AutoCAD in the 80's you can say exactly that you used to use the CLI only!
I have used git extensively in the terminal. But nowadays I see myself more and more relying on GUIs like the ones integrated in Intellij IDE, Source Tree, etc.
Another example could be qemu and the GUIs that we have nowadays. One final example would be simply drag and dropping files via Finder instead of using cp/mv
I used to sort of like the Azure GUI (yes I’m a total psychopath), but then they changed it 9 billion times and now I just use the CLI. It’s frankly often experiences like this which drives me back to the cli. I like Gitkraken, but the it does an update and forgets my SSO or it doesn’t support a specific thing I need to do and then I’m using their console.
I’m not really religious about anything, but I often end up going back to the CLI for a lot of things because it’s just less of an annoyance.
Oh believe me, I wish what you wrote was true, but it isn't.
I've seen people think they have a specific Python environment active just because they were in their project's directory on the command line.
I've seen people not understand that "python -m pip" is a command and even if they are in a directory which has "python" in its name, they still have to type "python" for that command.
PS: The command line might even be an emperor. And the emperor could be naked...
> I've seen people think they have a specific Python environment active just because they were in their project's directory on the command line.
I wrote python-wool as a simple wrapper to python to make that true because it's just easier that way. Direnv can also be configured to do that as well.
The command line is king, but sometimes the king is mad. Which is to say, it can be difficult to work with the monarchy when the syntax is shit. And there's a lot of bad syntax out there: overly cute, so terse as to be cryptographic, the straight-up baffling ...
Outside of the syntax (which seems to live forever), you have things like non-sane defaults, obscurantist man pages ... the list goes on.
the ability to hit up and edit and retry is such a redeeming feature. repeating the same actions in a GUI with no keyboard shortcuts is an exercise in frustration.
GUIs can have keyboard shortcuts. Have you honestly never pressed Alt+F, x to exit a GUI program or Ctrl+S to save a document in a GUI editor, or Ctrl+Tab to switch tabs in a GUI browser or Tab to move focus between fields, or the context-menu button next to Alt Gr and then a keyboard accelerator key for the menu, or Ctrl+C then Ctrl-P or anything?
Repeating the same actions in a CLI with no readline is an exercise in frustration, but ... that's not what happens most of the time.
When you’re typing a lot, you really don’t want to do a lot of typing for each step. And the shell scripts were for automating some process, not solving a particular problem (you use a programming language for that). The workflow is to have the references ready in case you forgot something.
That brings up the man pages, which can varies in quality, but, for most software I’ve used, tend to be comprehensive. But they assume that you’re knowledgeable. If you’re not, take some time to read a book about system administration (users, processes, files permissions,…).
I'm not sure if I have O'Reilly's System Administration book. I used to get pre-prints back in the early nineties when they were still quite new. In any case, yes, I have read and I have Been Around.
And I still think that we can improve. More over, we ought to improve.
This. And it does not even exclude having a (T)UI. Modern terminal tools like neovim, lazygit, zellij, btop++ or yazi can do many things as window management, image previews and colors as well as having mouse support.
The analogy I would make is that living in the command line is like using a CAD program while living in IDEs is like using CorelDraw to design houses.
CorelDraw feels more efficient because one quickly has what looks like a beautiful, colorful house on the screen. And then one does not understand why the doors don't work correctly.
> Input and output are also obvious. Input is what you type, output is what you see.
Input maybe, although realizing that instead of typing, you can pipe, is a major conceptual breakthrough when new users are learning to work the command line.
But output? The existence of stdout and stderr as two sources of text with no visible distinction is highly nonobvious and continues to trip me up in practical situations to this very day.
If you’re lucky, you might know what your current directory is.
More often than not, at any particular point, your command line is paused in the middle of some likely ad hoc multi-step process. A process with a bunch of state stored as opaque blobs of data scattered across the file system. More so exacerbated in my case as those files are likely cleverly named x, x1, x2.
Modern systems benefit from things like command history, scroll back buffers, and similar constructs that can be leveraged to help you, as the user, restore the current context. But for a very long time, many simply returned to a $ and a soulless, cold, blinking cursor callously expecting that you recall you know where you are and what you’re doing.
The tools are there to help you dig and perhaps restore the current context (current directory, latest files, etc.) but that’s a far cry from “obvious”. Lots of folks return, blow their internal call stack, and just start over when they come back from lunch (if practical).
its unsung strength is in having multiple terminal windows and a browser open, and the simplicity of being able to hit up and being able to edit and then retry a failed command. I can't do that in Photoshop.
Whenever I see new coders struggle, it usually is because they:
On the command line, the context is obvious. You are in the context. The working dir, the environment, everything is the same for you as it is for the thing you execute via ./mything.py.Input and output are also obvious. Input is what you type, output is what you see. Using pipes to redirect it comes naturally.
Not being natively connected to context, input and output is often at the core of problems I see even senior programmers struggle with.