In the Beginning Was the Command Line (1999)

The command line is still king.

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.

This is such generic advice about computing, it’s like saying:

“To make a building, you need to have a foundation, something to keep the roof up, and a way for people to move inside.”

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.

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.

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.

If you're experienced with the command line, it's easy to use GUIs and get good results.

If one starts with GUIs and doesn't really understand what is behind, then all kinds of trouble happen.

So I guess, as with any tool, understanding is key.

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

Why Western Designs Fail in Developing Countries https://youtu.be/CGRtyxEpoGg

https://scholarslab.lib.virginia.edu/blog/novice-struggles-a...

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.

More succinctly, "the only intuitive interface is the nipple."

>On the command line, the context is obvious.

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:

  - Linux:  ln srcfile targetlink

  - Windows :  mklink targetlink srcfile

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.

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.

Context isn't the same as syntax?

Yes, command line suffers from discoverability of which different applications (such as ln/mklink) may not be consistent.

It is one of the bigger problems (imho) of the cli but it doesn't go against GPs point.

The command line does have a learning curve (partly because of the above), but it is also quite rewarding.

> On the command line, the context is obvious.

You sound like someone who never tried to write a cronjob script…

"Don't know about the concept of input and output"

Wow, that seems quite fundamental. Computing 101.

I'm not a "coder" and I spend "99%" of time on the command line. Because I prefer it. Ever since the 80s when I first used a VAX.

Some babies actually do not have that intuition and rather bite and need time to learn.

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.

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.

Not all GUIs are just a graphical wrapper for a CLI. But in general sure, understanding the tech behind helps.

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

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

This is definitively not true for macOS.

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.

Yes they have a suckling reflex, but they might not latch on correctly and then breastfeeding is extremely painful.

Are there any good tools to be able to ssh into a machine and preview images or render markdown directly in line with the cli?

>Why Western Designs Fail in Developing Countries

Why add this?

Whats the solution then?

We have already given so much in the western world.

These days it’s easier to ask ChatGPT for the ffmpeg command line to do the thing you want, imo.

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.

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

http://GitHub.com/fragmede/python-wool

Reductio ad absurdum: we should all just use an interactive assembler. Then you really are "in the context".

There is a level of abstraction that makes sense. What level that is is dependent on your objectives.

sixel support lets you display images to the command line, for terminal emulators that support it.

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.

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.

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.

Agreed. When writing the comment I returned seconds later and added the word "interactive".

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.

Talk confidently when you have experience.

> the syntax is shit

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,…).

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.

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

DDT, the shell for the ITS operating system, was also an assembly-level debugger.

The command line is not a "foundational layer" in macOS, that was my point. It exists on the same layer as the GUI does.

Can you give some examples? Which GUIs are you using?

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.

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.

No doubt, if you're working in AutoCAD, there's no command line that you need to understand first.

But then again, if you're working in AutoCAD, you'd never say "I used to work in CLI only, now I use GUIs more and more".

Clearly they meant GUIs that have CLIs behind, or at least CLI alternatives.

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

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.

Sucking it's a reflex; the rest it's pseudoscience. Your personal anecdothes don't count.

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!

Tab completion can get you much of the way there.

The foundation of MacOS is a fully-compliant Unix:

https://www.opengroup.org/openbrand/register/apple.htm

The GUI is built on top of the Unix foundation and does not stand alone or work without it.

The 'FoxTrot' comic made a big deal about this not long after Mac OS X was released:

https://www.gocomics.com/foxtrot/2002/02/25

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.

[1] https://stackoverflow.com/questions/948008/linux-command-to-...

That doesn't negate the fact that newborns have a suckling reflex.

> the multistep process of C compilation

it can be a single make command

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

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.

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.

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

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

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.

The rest will be prompty fired in the spot.

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.

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.

For rending markdown, I use https://github.com/charmbracelet/glow

  On the command line, the context is obvious

Hardly.

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

we had the same conversation when Gmail came out.

a true test for a progammer is to see what they can do on a computer without the Internet.

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

CorelDraw? Word? Audacity?

Or maybe it will turn out that all GUI software has command line somewhere inside. I think my original point stands even better in that case.

Yay for hair-splitting, I guess.

"Or maybe it will turn out that all GUI software has command line somewhere inside"

Not at all. Most maybe, but since I wrote GUIs without a CLI I can say for sure that not all have them.

I mean, every web GUI, which are now probably the majority of GUIs do not have a CLI anymore..