CLIs are simply wizard at character building. Let’s not keep them to ourselves

The passage of time can harsh one's mellow in bittersweet ways. Tech anniversaries, while they do make you feel "That can't be true, it was just the other year," also offer the chance of a bit of fun in the form of emulated nostalgia. Far more dangerously, some of us even find ourselves on eBay, handing over hard earned cash …

[Alan1kiwi]

I'm no expert

But have spent many hours attempting to fix a problem from within a terminal screen. Both in Linux, and in Windoze.

I guess it's a function of age, and also dealing with early versions of both OS's and their limitations.

These days, I am happy to click an app, and see what happens !

Merry Xmas to El Reg, and it's readers.

May you all have a splendiferous time with your family and loved ones.

[mdubash]

Re: I'm no expert

Yup, done a fair bit of delving in my time, from the BBC Micro (which in my case fulfilled its brief of sucking me into compoting) onwards. Not so much any more though. Life's too short...

[akkeosflomdis]

Re: I'm no expert

Merry Christmas to you too! I hope you have a wonderful time with your family and loved ones during the holiday season. If you ever find yourself in need of tech advice or just want to reminisce about the good old days of terminal troubleshooting, feel free to reach out. Cheers to a splendiferous holiday!

[katrinab]

Re: I'm no expert

Yes, if you only need to fix the problem once.

If I need to fix the same problem on 5+ computers, it is quicker to work out the required sequence of commands, and either run a script on each computer, or copy/paste it onto the terminal.

[Snake]

Re: 5+ computers

I agree wholeheartedly.

But realistically, for exactly how many people in the world does this truism apply?

CLI for multi-user admins, absolutely. But there is absolutely no logical argument to make individual computer users remember arcane commands just because our own egos are stroked when we do so ourselves.

[An_Old_Dog]

GUI-Based Admin

Imagine you have 10 servers, and have to double-click on the server's icon to open up its admin GUI.

Imagine you have 100 servers, and have to double-click on the server's icon to open up its admin GUI.

Imagine you have 1,000 servers, and have to double-click on the server's icon to open up its admin GUI.

Imagine you have 10,000 servers, and have to double-click on the server's icon to open up its admin GUI. (Feel free to substitute "virtual machine" or "network switch", for "server".)

As for typing out, "bigcorp-atl-s1023-06-00-84-38" in the server-name field of a command string, that's what text-based menus are for.

[doublelayer]

Re: GUI-Based Admin

"Imagine you have 1,000 servers, and have to double-click on the server's icon to open up its admin GUI."

Not the right comparison here. Imagine you have 1,000 servers, and have to activate your SSH client, decrypt your public key, and enter the root password to elevate to run your script on each one. That would be painful too. That is why nobody who has to do something on a thousand servers does that. People who operate on that scale have a lot of tools to take an action on a large set of hosts. That can at times be a CLI program (take this script and run it on all hosts), but frequently is not. There are GUI-based tools that allow you to change the configuration of a set of servers too, and many of these are popular because they allow the admin to visualize the effects of a change: how many machines have completed it, how many errors have happened, are error rates changing, etc. However, there are even more interfaces for such things, including ones that deploy all those changes as code in version control, which often have multiple frontends with different capabilities, but those frontends are mostly for retrieving information, not setting it. You seem to be alleging that GUI administration involves handling one computer one by one and CLI administration is not, but neither generalization is correct.

[An_Old_Dog]

Re: GUI-Based Admin

@doublelayer: You are correct about available tools, but mis-interpreted the problem I see (I obviously did not state it sufficiently-clearly).

I wasn't thinking about solving a single problem on multiple devices. I was thinking about solving one problem on one device, but having to visually navigate, via a GUI, a swarm of devices in order to zero in on the one you wish to manipulate. I've encountered web-based admin programs which disable the [PageUp] and [PageDown] keys, or simply ignore them, and force you to use the finicky, sometimes-disappearing scroll bar.

If you haven't experienced mouse-pointer hell, try this: sit down at your computer, plug in a set of earbuds and don them, open a (GUI-based) web browser, go to YouTube, select any video, and click play, if it doesn't auto-play. Then, adjust the volume using only your mouse to move the volume slider in the YouTube window. What you will get, no matter how carefully and slowly you move your mouse, is either nothing ("Mute"), or painful, hearing-endangering sound-pressure levels.

[Filippo]

There's also the not insignificant problem that GUIs have been getting worse.

If I open a random "modern" Windows configuration page (as opposed to the ones that have remained blissfully unchanged since WinNT), here's what comes up on my screen:

* A mere subset of the relevant settings. The way to access the entire set of available settings is non-obvious, is different for each context, and it tends to be "start the old WinNT settings page, if you know how to get to it".

* Buttons with a color that's difficult to distinguish from the page background.

* Extremely wide margins that result in acres of unused screen space.

* Having to scroll in order to see all the settings that are available (even though I'm on an enormous screen, and they're not even all settings).

* A search function that only works if you have memorized exactly which keywords lead to which setting page. If you don't know what you're looking for, or how to explain it to the search box, good luck.

* Inconsistent design between contexts. Sometimes there are combo boxes, sometimes there are radio buttons; sometimes a boolean setting is rendered as a switch, sometimes as a checkbox. Sub-contexts might be side bars, might be separate windows, might be something else.

And it's not just Windows, either. Phone GUIs, web app settings, it's all over the place. We used to have a unified design for settings that everyone understood. It wasn't pretty, but so what? It's not supposed to be a work of art, it's supposed to get a job done.

[ChoHag]

Unsatisfied with glitzing the GUIs, have you seen what some people are doing to the command line now? It's like tripping in a skittles factory.

[Dan 55]

You mean you don't want a built-in terminal autocomplete which looks like Iron Man's HUD? Why ever not?

[nautica]

Speaking of HUDs--perhaps that DOES need to be re-thunk

Whatever happened to The Space Cadet's supposed "HUD", absolute blockbuster addition/modification to Ubuntu? It was supposed to be veritable dynamite, one which would change all traditional OS man-machine interfaces forever. But, then again, so were all his other dynamite, grandstanding, showboating ideas, such as the Edge Smartphone/PC-convergence device--with its laughable designed-to-fail (by him, no less) crowd-funding campaign.

Might be time for a HUD interface for computers. Cold Fusion is dead; 3-D PC displays weren't 3-D; Quantum Computers and green-energy Fusion Reactors are still "...just twenty years away..." (and still will be twenty years from now...); more people (MOST importantly: Financial Regulators), every day, are finally figuring out that con game, the CryptoCurrency Ponzi scheme, for what it is...

It's time for a latest-and-greatest buzzword, newest, greatest, non-starter technology for the smurfs to pour their cash into.

A Heads-Up-Display man-machine interface for PCs fills that demand perfectly.

[An_Old_Dog]

Iron Man HUD

If you want that sort of UI, check out "eDEX-UI" (see eDEX-UI downloads and eDEX-UI source and screenshots), for Linux and MS-Windows.

[andrewj]

You mean like the dark red or dark blue text on a black background that some terminals default to? Or for that matter the idiotic color scheme on Google assistant which similarly has dark grey on a black background at times.

[Pete Sdev]

Sensible programs have a colour off switch, or even better a colour on switch.

Many will default to using colour if they think your terminal supports it. Try altering the TERM environment for a program that has no --turn-the-damm-colours-off switch.

[RegGuy1]

Just pipe the output to cat (in other words add "|cat" to the end of your command). That will kill colour.

[mpi]

The difference is, the terminal doesn't come with this kind of tomfoolery built in. People who want that can install that, and people who don't don't have to do extra legwork to get rid of it.

Everyone starts out with a simple `/home/user $` and can take things where they want from there.

(barring some truly obnoxious distro maintainers of course, who insist of stuffing their crap into /etc/profile, but even that is usually dealt with in a few keystrokes.

[My other car WAS an IAV Stryker]

Options and settings

* Some require you to confirm/save/apply, and some don't (immediate action).

I prefer the former -- it lets you check for something stupid before committing.

Having options to NOT apply, either temporarily (cancel instead of confirm but keep showing the intended changes) and/or revert to previous settings are sometimes necessary and always appreciated.

[Grogan]

Re: Options and settings

I prefer having to confirm GUI configuration dialogs too. Go into a panel with dozens of complex settings (some of which you may not even understand immediately). With sensible dialogs, it's perfectly safe to go in there, look at things, see what's in drop lists. You can click buttons to go into sub-dialogs as long as you cancel your way out of everything. To me, this makes GUIs more discoverable.

Contrast with modern "smart phone" influenced stupidity where every box or slider makes a permanent change. Now, an accidental click or click and drag or keyboard fumble can have you chasing your tail.

[captain veg]

Re: every box or slider makes a permanent change

They're not permanent. You can easily undo them, provided you can remember the initial setting.

Best keep a pencil and paper to hand.

-A.

[parrot]

Re: every box or slider makes a permanent change

“Best keep a pencil and paper to hand.”

Tracing paper?

I assume this is a joke. Unless you actually carry a small portfolio of ‘manual screenshots’ everywhere? That sounds intriguing. Could imagine that sort of thing being popular in the right sort of gallery. You could manually tile them on the manual wall.

[Ben Tasker]

Re: every box or slider makes a permanent change

He's just a shill for big pencil. Watch for them, they're really sketchy

[I could be a dog really]

GUIs have been getting worse

Yes, yes, and thrice yes - I'm glad to see I'm not alone in thinking this (I'm afflicted with Windoze at work)

To add to your list of "why I hate the Windoze UI" items :

Different programs from the same vendor have totally different keyboard shortcuts. The number of times I've hit Ctrl-F only to find a new message window pops up for me to forward the message instead of searching for text.

Different programs, again from the same vendor do totally different things with scrolling and cursor keys. Example, open up multiple documents (such as a recent task where I've had to deep dive some design documents looking for errors) in multiple programs. With Word, the document your mouse pointer is over is the one that scrolls, with Excel the document that's currently active is the one that scrolls even when your mouse is at the other end of multiple screens. One program retains highlighting when it's not the active program (so you can see what you have selected), while Excel doesn't (so you lose your place). And highlight some text, press the left cursor key - different programs leave the cursor in different places.

This is the sort of stuff the Mac was excellent at - simply because it was pre-designed by Apple. When the Mac came out, you could buy (for a reassuringly high price) a set of three books which contained all the information you needed to program on a Mac. Of the 3, an entire volume covered the UI - all these things were covered in detail, what happens when you highlight some text then press a cursor key, what the first few menus must contain, how dialogs should work, yada, yada, yada. As a result, there was uniformity - mostly, but people who thought they could take shortcuts found "user resistance" to what was perceived as a poor and non-conformant UI and such programs either disappeared or got fixed to be "proper" Mac programs.

AFAIK, Windows never had that, and all that history of different people, even different teams within the same business (yes, you Microsoft), having their own ideas of what a UI should look like still shows. That's why Outlook still has illogical keyboard shortcuts - it was bought in and given a bit of lipstick rather than properly unifying it. There's no excuse the (e.g.) the Word vs Excel differences though.

And as hinted at, there's the policy of changing the UI all the time. No sooner have we got used to the last change (which was usually for the worse), than it changes again.

Sadly, Apple aren't immune form this. While some UI changes have been a benefit, many aren't. My current Mac will probably be the last Apple hardware I buy - mostly because I won't buy something that doesn't have the memory and storage I need, and can't be upgraded. But there have been changes in Mac OS that are getting annoying - little things I can't put my finger on, plus bigger things like it no longer being possible to easily clone your system disk onto a bigger drive when you want to expand. Thinking of switching to Linux in earnest and running a Mac as a VM for some of my legacy stuff) - but then, which window manager ? I think it's going to be a hard change, hence why I've put it off for a long time.

[Diogenes]

I am still fond of IBMs common user access (CUA). The manuals for which are still around

[An_Old_Dog]

CUA Manuals ... Where?

My Google-fu is lacking. Do you have a current reference to the CUA manuals? If so, please post it.

[captain veg]

Re: why I hate the Windoze UI

> The number of times I've hit Ctrl-F only to find a new message window pops up for me to forward the message instead of searching for text.

Yes. This is evil, and suffices all by itself as ample justification for finding some alternative -- any, really -- to Outlook.

> AFAIK, Windows never had that

Actually it did. For a while. And then all the different teams, especially those working on Office, decided to go freelance, and MS management let them. This was around 2003 IIRC.

-A.

[Del Varner]

" Sadly, Apple aren't immune form this."

Apple's software quality has been dropping. I attribute it to the marketing whizzes demand that they come out with a new OS version every year. Some stuff seems to come out half baked. Perhaps not enough time is spent on testing/

[Spanners]

you could buy (for a reassuringly high price)

I have never found anything remotely reassuring about a high price. I have been doing some mental gymnastics and the only example I can come up with is a spare part for a Rolls Royce is probably either expensive or fake.

I cannot think of many other examples and none in IT.

[martinusher]

A lot of the time these configuration dialog boxes just prepare command line options for a CLI program that is subsequently executed. This is why the option set tends to be limited and why there's often an option to view and/or edit the command line.

The design inconsistencies are, I'd guess, due to different programmers being tasked for each utility.

[I could be a dog really]

The design inconsistencies are, I'd guess, due to different programmers being tasked for each utility.

That should not be an issue - the programmers should be working to a defined UI standard. In fact, the UI should have been designed by the UI team, with the programmers only given any choice as to how they implement that. See my comment above about how the original Mac had a 3 volume set of programmer manuals - a whole volume of which covered nothing but how the UI should work in order to garner consistency between all programs regardless of who they were written by. And that manual was based on considerable research they did with test panels and mocked up UIs.

There's an anecdote that originally the standard yes/no dialog had buttons for "Cancel" and "Do It". In tests, it was observed that many users backed out of a task at this stage, and on querying them, it was found that people misread "Do It" as "Dolt" which many will recognise as something of an insult in US culture. So it got changed to "OK".

[captain veg]

Re: the standard yes/no dialog had buttons for "Cancel" and "Do It"

They should have read "Are you feeling lucky, punk?" and "Go ahead, make my day".

-A.

[Smartypantz]

Sabotage

If Microsoft didn't sabotage their own GUI how would they keep people from discovering that web based "Azure Portal" system Administration is grossly inferior to the old ways of doing things?

On CLI: I can configure, replicate distribute and change any number of sites or databases in CLI on any number *NIX hosts a hell of a lot faster than the clicking and probing bullshit in IIS!! Of course this requires a lot of experience, but there is a major difference between "user friendly" (what i just described) and "beginner friendly" (what Windows GUI's used to be).

[imanidiot]

Specifically Windows and Microsoft GUIs have been getting worse.

It seems with every new version of windows they feel they need to redo the GUI, then run out of time and budget (or managerial will power) to actually fix the GUI uniformly. So we end up with a slapdash, haphazard mess where some things follow the newest standard, some thing follow the last versions standard, some follow the NT standard, some don't seem to follow any standard. And so long as Windows keeps it's dominant position it is unlikely anyone at Microsoft will feel obligated to actually fix the mess.

[Terry 6]

Yes. There's a small irony embedded here too.

In Windows you can change the icons for the recycle bin to your own custom icons. It's been around for a long time. Through various versions- since 7 at least - maybe even Vista..

And they've never fixed the bug that stops it working properly.

The workaround has been known for years. You have to edit the registry and add a ,s to the icons' paths.

https://www.sevenforums.com/tutorials/24761-recycle-bin-fix-custom-icons-not-refreshing.html

Maybe it's fixed in 11. Maybe they supply flying pigs too.

[Binraider]

I'd cite bloat as a big plus of anything CLI. How many libraries do you need to draw on to create a useful application for CLI? iostream, fstream, maybe string or cmath?

Contrast that to the behemoth back end required to cobble together simple utilities. The Windows 10 Calculator takes up 39MB for instance.

Smaller applications have less bugs and are easier to maintain. This is a good thing.

[imanidiot]

The windows 10 calculator doesn't NEED to take up 39MB.. It's just that nobody found any need to program it in an efficient and space efficient manner because todays computers don't notice the bloat (compared to all the other bloat in Windows anyway.... How the frig does an OS need over 10 GB of disk space??)

[nautica]

Of course it doesn't.

"The windows 10 calculator doesn't NEED to take up 39MB..".

One of the very best, very small Spreadsheet Programs, called Gnumeric, .--takes about 30 MB !

From Jack Germain, "Gnumeric Crunches Numbers Like a Pro", https://www.linuxinsider.com/story/Gnumeric-Crunches-Numbers-Like-a-Pro-76605.html

..."The bottom line regarding match computations with Gnumeric is that this spreadsheet app gets the same answers as its competitors, but does so faster....

"...Gnumeric is more than a simple and limited calculation program. It is a fully-functional spreadsheet capable of manipulating and analyzing numeric data. Its uses include keeping track of information in lists and organizing numeric values in columns.

“While it is defined by developers as lightweight, Gnumeric is not short on features. For example, it offers 100 percent of the worksheet functions in Microsoft Excel, plus it has 154 functions not found in that commercial business spreadsheet.

"It also comes with basic support for financial derivatives (Black Scholes) and for telecommunication engineering. It is adept at handling analytics and advanced statistical analysis. If you need it, this app can implement complex optimization modeling or perform tasks involving numbers, dates, times, names or other data.

Gnumeric handles extensive random number generation and performs and updates complex calculations by defining each step of the calculation and modifying particular steps subsequently. Also, it can create and display or print graphical plots of data using bar plots, line graphs, pie charts or radar charts....(--J.G.}

One can read the entire article here.

One of the very many qualities of Gnumeric is its extremely rich ensemble of Statistical Functions. Included, for example, is Fourier Analysis !

[Peter Prof Fox]

Intuitive GUI? My arse.

The first time I used Windows I couldn't find how to close it down. That was because you had to click on the START button.

[OhForF']

Re: Intuitive GUI? My arse.

I agree that the Windows GUI is not intuitive but neither are the various CLIs and editors in the terminal. I still remember having to suspend and kill the process to get out of vi the first time i started it.

Let's see if anyone hardcode vi fan manages to come up with an explanation why <ESC>:q! is intuitive and straight forward ;)

[nautica]

Re: Intuitive GUI? My arse.

Simply a thought:

it's more than a little possible that "...making something intuitive...", while being a very laudable undertaking, requires adding code which is out of proportion to the rest of the entire program, and / or is just too damned time-consuming. BUT,,,

I totally agree with you.

[hoola]

Re: Intuitive GUI? My arse.

What, you mean like all the React shite that funky websites are built in all sorts of pointless dynamic widgets that appear and disappear for no good reason, They add ABSOLUTELY NO VALUE. I have to spend all day working with a product developed using this sort of shite and hours can be lost trying to explain to people you have to hover of something you cannot see to make a change.

[Munchausen's proxy]

Re: Intuitive GUI? My arse.

Let's see if anyone hardcode vi fan manages to come up with an explanation why <ESC>:q! is intuitive and straight forward ;)

I was going to make a TECO joke, comparing that to 'ex$$' but I suddenly realized to my horror that TECO really is more intuitive. (at least to exit)

Edit: ( I guess I should add that the '$' is what TECO displays for '<ESC>' )

[Ozzard]

Re: Intuitive GUI? My arse.

*chuckle* I've been a hardcore vi user since my apprentice days (the file server had 2 Mbytes of RAM, ten diskless clients hanging off it, plus my VT200 - and emacs was a 2 Mbyte binary). Until you know its modes, it's utterly unintuitive. Actually, even when you *do* know its modes, it's still pretty surprising.

For myself, I still wouldn't use anything else for hardcore interactive text-report munging. But I wouldn't teach it to anyone else, either. Did enough of that training UNIX in the '90s, to the point that I produced a "surVIval guide" for the editor.

[hoopsa]

Re: Intuitive GUI? My arse.

For many years I exclusively used emacs; then for one reason or another I shifted to using vi and have used that for probably the last 15 years. I always recommend vi to new techs because it's (nearly) always there on the server if you need it. Come to think of it, that's probably the reason I stopped using emacs in the first place.

This article (and this post in particular) got me to try emacs again just now though. Can't work it at all. Trying to remember how to is quite fun though and actually it's weird how that muscle-memory is still lurking back there with just a little bit of prompting...

[bill 27]

Re: Intuitive GUI? My arse.

I recall back in the bad old days when sometimes the UNIX box wouldn't run X...boot into single user mode and I'd end up root. vi was the tool to fix whatever was wrong, and the sh would change too since things were generally statically linked, couldn't count on libraries being available.

[rcxb]

Re: Intuitive GUI? My arse.

vi and emacs are obviously the power-tool editors. Beginners should start with pico / nano / joe / etc.

It is possible to have one that can suit both, with a little effort. "lynx" is a good example, with its two lines at the bottom of help by default... something you can quickly go shut off in the settings. Helpful for beginners, and only slightly annoying to the advanced user.

[Zolko]

Re: Intuitive GUI? My arse.

yes, well, nano ... <CTRL>-s doesn't SAVE the file but launches SEARCH. You need <CTRL>-o to "write-out". <CTRL>-r doesn't REPLACE but READ a new file. <CTRL>-c doesn't COPY but shows the current location of the cursor.

But at least it's explained in the bottom of the window. Did somebody code a version of nano with standard keyboard shortcuts ?

[Ben Tasker]

Re: Intuitive GUI? My arse.

I use nano quite a lot - I got used to firing it up on a system where a predecessor had (I assume, in a fit of rage) ripped Vi out.

The real problem with it, though, comes when you use it too much and then try to do something in a GUI editor. The number of times I've closed things by hitting Ctrl+W to search...

[Anonymous Coward]

Re: Intuitive GUI? My arse.

I would go as far as to say that Nano is probably more than enough for most use cases...especially if you enable syntax highlighting. It's not perfect, but it is just enough.

I don't mind Vi if I'm forced to use it...but emacs...I've just never got on with it...it is the antithesis of what working with a CLI should be in my subjective opinion. I typically live in the CLI and I do so because it removes a lot of bottlenecks in my workflow...emacs to me is a bottleneck...I can be rip snorting through the CLI performing all kinds of black belt CLI-jitsu parkour then fire up emacs and the pace just disappears. This is not to say that emacs is a bad tool...it's not...I just don't associate it with a typical CLI based workflow...it's just another IDE that happens to run on the CLI.

[Old Used Programmer]

Re: Intuitive GUI? My arse.

I can give it a shot...

vi is dual mode. You're either in command mode or append mode. In append mode, what you type goes into the file. So...<esc> gets you out of--or makes sure you're out of--append mode. Then, because vi is built on top of a line editor (which is why it can do global commands), you use ':' to tell it you're going to issue a line command. Followed by 'q' (quit) and '!' don't save, just do it. Unless I've screwed things up, I'm much more likely to use '<esc>:wq'.

[Anonymous Coward]

Re: Intuitive GUI? My arse.

Cool...or I can...if I'm looking to fix a bug and I know the line number.

nano file.php

Ctrl+Shift+_ <line number>

make an edit

CTRL+O & CTRL + X

then run the file to test it.

I never have to worry about what mode I'm in.

There is nothing wrong with Vi. It's a perfectly reasonable text editor, but there is no argument, where convenience is a bone of contention, that Vi can win.

I will happily use either, but given a choice, I'm picking nano...especially if I'm using a multiplexer...I also use Nano if I'm demonstrating something or teaching someone how to do stuff...because I don't want the inevitable "how do I quit out again?" call.

Nano is completely unambiguous and exactly the same every time you load it and has no pace breaking steps to break your flow.

Most importantly, nano feels like an extension to the command line whereas Vi feels like a tool built to run on the command line. With nano I feel like I'm continuing with whatever it is I was trying to do...whereas with Vi, I feel like I'm changing gears because I mentally have to switch to a different shortcut map in my head...it is necessarily flow breaking, but it's a definite shift rather than a fluid continuation.

I suppose your choice of text editor comes down some key aspects...

1. Your typical intention when you open a file. My intention is almost always to edit the file in some way, not append to it. Nano also assumes this.

2. Your personal taste for keyboard shortcuts. CTRL+<key> style setups make the most sense to me and fit in with the myriad other tools I use on the CLI...so Nano fits in perfectly there.

3. The amount of time you typically spend editing a text file. I'm usually in and out pretty quickly. Nano is used when I can't just write a quick sed command to make a change or I'm not entirely sure what the formatting of something is or I need to look at the code around a specific line or something. If something requires more than just a quick tweak or I need to see more of the file etc...I'm usually in an IDE like VSCode...not the CLI...Vi is somewhere in the middle I feel.

4. You've always used Vi or Nano and that is what you're used to...and that's fine.

I don't think that in isolation one is necessarily better than the other in terms of features...they're just fucking text editors after all...some people will prefer Turkey at Christmas and other people will prefer Gammon...it's personal preference and highly situational.

[I could be a dog really]

Re: Intuitive GUI? My arse.

I don't think that in isolation one is necessarily better than the other in terms of features...they're just fucking text editors after all...some people will prefer Turkey at Christmas and other people will prefer Gammon...it's personal preference and highly situational.

Indeed.

I'm not a vi guru, but I know enough to get some good results out of it. Of course, part of it's quirkiness (or charm, depending on your PoV) is that it was written by people who needed to do a job, and they wanted something that would do that job well. Hence, if your needs and thought processes are vaguely similar then it will feel logical. These days, the cursor movement commands seem arcane, but there were done so as to be quick to use on the keyboards of the day, which didn't always have fripperies like cursor keys - and in any case, such keys are a long way from your typing keys. As someone who's done a bit of programming over the years, it's mindset suits me - I can understand though that someone used to a GUI will find it "alien territory".

As to quitting vi, if we drop the ESC: as that's common across commands, then we have "q" for quit. If you've made changes, IIRC it'll warn you that you have unsaved changes and not quit. So you'll want to write your file, which is "w" for write, so we can do a command to write, then a command to quit, or just combine them as "wq". Or there's a command to write and quit, "x" for exit. Of course, sometimes you really do want to do something such as quit without saving your edits - then there is "!" to override the safeties - the "just do it, I'll take the consequences" switch. So "q!" to quit and "yes I do want to lose my edits".

So perhaps "Esc:q!" is not such a strange command to quit - once you understand what the components of it mean, and why they are there. "Esc" to get out of the freeform text edit mode, ":" to start a line command, "q" to quit, and "!" to override the safeties so it doesn't comer back and say "Sorry Dave, I can't do that".

And like others, I learned vi simply because it's there, on every box. And back when I first got involved with Unix, there simply would not have been room on the boot/root floppies to have anything else so you needed to know vi in order to fix a broken system. It was bad enough the amount I needed to remove from the root floppy to make room for CPIO - useful to be able to restore from your backups !

[Anonymous Coward]

Re: Intuitive GUI? My arse.

Yeah the commands are easy enough to remember, but jarring if you're working in a multi pane multiplexed terminal, because 90% of the time you'll be using common control schemes that involve modifiers and every now and then you might need to enter some commands into Vi. It's quite jarring. I prefer to think in layers than groups.

I think most of us here have had that "oh shit, yeah, it's vi" moment many, many times and the obligatory "oh fuck they set the default editor to vi" moment.

I'll use it if it pops up and there is no other option available to me at the time...but it's never my first choice simply for reasons of convenience and flow.

There is also that "hand reset" moment you get as you type nano...it's like you hands get recentred before you hit enter and it launches. It's quite pleasing. Vi is perfectly functional and it's fine...but it's the common fried mozzarella stick to nanos truffle arancini with a pecorino and grana padano centre. Both are basically deep fried crunchy cheese, both are very nice, but only one of them puts a genuine smile on your face when you pick it up. I get that some people prefer the brutal minimalism of the mozzarella stick, but it's always nice to have the lavish luxuriant option for sheer consumptive pleasure.

[LybsterRoy]

Re: Intuitive GUI? My arse.

Its the same for any piece of software - intuitive & user friendly should be replaced by "we've been using it for ages and know which buttons to press / which command to type"

[hoola]

Re: Intuitive GUI? My arse.

Intuitive appears to be something that is sadly lacking on most things now. Essentially anything that is driven by some sort of computer interface now has a horrendoma of touchy-feely crap all over the place that makes things impossible to use.

It is not just computing, it is everything. Why the heck does my car have to have a ridiculous touch button with no feedback to change the heat on the AC or turn the lights on.

I just want a sodding physical button that works.

Then we have all the dynamic crap in software with scroll bars jumping in and out, stuff disappearing depending on where the mouse is. All adding absolutely sod all to the usability.

Maybe I am just old but looking at the people I am working with who are half my age I don't believe that is the problem. Is it just shite arty-farty bollocks for the sake or it.

[Handy Plough]

Re: Intuitive GUI? My arse.

I think you're confusing 'intuitive' with 'simple' old chap. Let's be honest, the computer thingys can do considerably more that they used to be able too. Add the incessant pressure from customers and the tech press (looking at you El Reg) for iNnOvasHun!!1!, and things get messy, quickly.

[mpi]

Re: Intuitive GUI? My arse.

> Let's see if anyone hardcode vi fan manages to come up with an explanation why <ESC>:q! is intuitive and straight forward ;)

Speaking as one of the "hardcode" vi fans, I won't claim anything of the sort.

t's not intutive, it's not obvious, it's not easily discoverable, and the Joke on how to get random strings by giving a freshman a vim and asking him to exit it, exists for a reason :-)

Thing is, it doesn't have to be any of these things. It has to be fast, useful and logical provided that one is willing to invest the effort to familiarize himself with it.

And that it does oh so damn well.

This is true for basically the entire CLI environment. It is completely unintuitive and doesn't lend itself to being discoverable. It demands learning. But once past that barrier, that's where it outshines everything from GUI-Land.

[Vometia has insomnia. Again.]

Re: Intuitive GUI? My arse.

I eventually migrated to vi from ed, which I'd been using for years as I couldn't figure out how to do global search & replace in emacs. I dare say it can certainly be done, but finding out how was daunting when I was still grappling the oddities of Unix and C at the time, whereas ed's documentation was concise and simple enough for me to figure it out instantly. I eventually migrated to ex and then vi as ed can be just a bit too minimalist, sometimes; but vi initially caused that wtf moment where the only way out was CTRL/Z and kill. Actually now I use vim, which is considerate enough to write INSERT on the status line so at least I know what mode I'm in...

[Binraider]

Re: Intuitive GUI? My arse.

Vi I'll admit has always beaten my attempts to use it in favour of just about any other editor. Possibly with the exception of Edlin or Debug.

As I am a by product of being taught computers by the C64 & Amiga, picking up the command line required only minimal reading to do interesting stuff. Nothing beyond any 8 year old to pick up with some relatively minimal reading. I'm sure most el reg readers were editing their Startup-sequence or autoexec.bat at similar ages.

WB1.3 came with that official looking command reference, and DOS 6.22 had the help command (can't speak for earlier versions). Trying all the commands out was a thing.

Finding ones way around Windows 9X and it's successors, with the rabbit warrens of registry, incomprehensible and multiple settings menus. Nightmarish UI redesigns (7-to-8, anyone?), or the endless hazards of install.exe? How to recognise and clean up malware that you will inevitably catch? The mass of "inherent" knowledge from using the damn thing for 28 years that is something of a requirement to make good use of Windows? Yes, I can safely say those older systems were far more intuitive to learn provided you had enough of a reference book to get started.

Linux/BSD are on whole other levels. The documentation is generally available, but finding what you need is a skill set in of itself. My initial experience of linux was with an early release of Mandrake, just using the package managers. Pretty painless but lacked exposure to the interesting stuff. It's a similar story with something like Mint. I've jumped to Manjaro of late; and while it's great for me, the learning curve demands the user figure quite a bit out quite rapidly.

As an "experiment", this Christmas a certain 8-year old will be getting a Raspi 400 delivered from Santa. He likes his consoles, but has no experience whatsoever of real computers. We'll see how that initial learning curve looks for someone that hasn't spent 35+ years of their life learning this stuff.

[Stephendeg]

Re: Intuitive GUI? My arse.

You only ever make the mistake of not knowing how to quit once. The exist sequence is nothing if not at least as memorable as the Konami Code.

[Arthur the cat]

Re: Intuitive GUI? My arse.

The first time I used Windows I couldn't find how to close it down. That was because you had to click on the START button.

Maybe computer manufacturers should stand this on its head, and use big red emergency stop buttons to start computers.

[Anonymous Coward]

Re: Intuitive GUI? My arse.

Yes, and years down the line it is still a problem albeit in a different way.

Me: Ok, now restart Outlook.

Them: Ok the machine is rebooting.

Dumb UI decisions can lead to confusing semantics further down the line, if there are a lot of steps to retain...because for a none technical user remembering where the restart button is takes up quite a lot of skull bandwidth, there is considerable effort put into retaining that knowledge and if you introduce a second "restart mechanism" like for a service, application etc etc...they simply won't remember it and failback to the last known restart method...which is rebooting the machine...from the perspective of the user, it's the same result and isn't any less convenient for them...but us as techies, it's teeth grindingly maddening...because a few of these in a day, especially if updates are triggered, can cost a lot of time...you can lose hours.

You can adjust the language and say "now close Outlook"..."Ok, now open it again" instead of "restart outlook"...but that isn't natural language to a busy techie with loads of tickets on his plate. I'd go one step further than a big red button on the PC itself and go as far as to suggest a dedicated key on a keyboard to "restart current app" would be great...perhaps in place of that right hand side Windows key that nobody uses that can only be triggered if the CTRL key is pressed or something.

"Press the skull button and escape at the same time to restart the app".

Mind you it's Windows...so 50% of the time it will lead to this...

"It didn't do anything"

*sigh* "alright just reboot the machine then" *mutes the speaker phone* "FUCKING BOLLOCKS BASTARD TWAT ARSE SHITE BOLLOCKING BASTARDING ARSEHOLES FUCKING WINDOWS" *unmutes speakerphone "Ok, has it rebooted yet? Updates still going? Ok." *mutes speakerphone and flips the table, kicks his fucking bin across the room*

[I could be a dog really]

Re: Intuitive GUI? My arse.

If only I had more than one upvote for that last bit

[David Hicklin]

Re: Intuitive GUI? My arse.

> dedicated key on a keyboard to "restart current app" would be great

Ah but would Windows understand which app is the current one ?

[yetanotheraoc]

Re: Intuitive GUI? My arse.

> dedicated key on a keyboard to "restart current app" would be great

Press any key to continue.

No not that one!

[nautica]

Re: Intuitive GUI? My arse.

"...but I couldn't find the"ANY" key..."--old joke/cartoon.

[doublelayer]

Re: Intuitive GUI? My arse.

"I'd go one step further than a big red button on the PC itself and go as far as to suggest a dedicated key on a keyboard to "restart current app" would be great"

I will take the opposing side there. The user can learn to close applications. They can learn that there is no restart Outlook button, and that when you say "restart" you mean exit and relaunch. Or you can say "exit and relaunch". Either is much simpler than adding a key to a keyboard that is completely unnecessary.

If we start adding more keys for every situation that comes up some time, the desk will have no space for a mouse or papers because it will all be a keyboard with buttons like restart app, clear print queue, actually check for network interface having a connection rather than have the user assume that their internet is down, enable remote access for the helpdesk to show you what to do, close remote access because a scammer told you to push that button, figure out what application the user wants to use to open that file instead of the OS default because they don't know how to change it, etc.

[mdubash]

Re: Intuitive GUI? My arse.

I still miss the BRS.

[captain veg]

Re: Intuitive GUI? My arse.

In Mint the on-screen Shutdown button is nice and red.

Well, it is in my installation. Since I didn't explicitly choose that, I assume it's by default.

-A.

[doublelayer]

Re: Intuitive GUI? My arse.

A CLI has a claim to being the least intuitive interface to the unfamiliar user, however. If you already know a command exists, you can probably look up a help page on it, but if you're asking a question like "What do I need to perform [action]", you don't have any way of finding that out quickly from the interface. You could look through every binary available on the path on the assumption that it's probably one of those, but those aren't organized in any way, have names that don't tell you anything about what they do, and not all of them will even have man pages. Invoking them to hope that they all have a --help argument and won't, for example, run some program that ignores the parameter is dangerous. Don't get me wrong, I spend most of my day in CLIs and I'm posting here while I wait for another CLI command to finish, but that works a lot better because I have had years of experience with it and I'm using a system where I already know the commands I'm using most often, know what they are capable of, and have DDG at my side in case I need someone to tell me the incantations related to something I haven't worked with before.

[nautica]

Re: Intuitive GUI? My arse.

Good point.

"...but if you're asking a question like "What do I need to perform [action]"..."

What's the suggestion as to where to go to get a compendium--list, plus short-form listing of result(s) of using each command--of all the terminal commands available (to me, for example) running the bash shell? I've been using the terminal since starting with Linux, but only using those commands which I've been exposed to via the literature.³ I'm certain I could be a lot more productive if I knew all terminal commands which are available to me even though I'd probably use only a small percentage.

Once the general usage of [command] is known, one can always get specific help--at the terminal--with "man [command]", or "info [command]".

³Since I sometimes have a hard time remembering the exact date, one of my all-time "stumbled-upon" favorites is "cal", and/or "ncal". Give them, along with "info (n/)cal" a try. Simple command; simple output; very rich feature set if you need it. [need this month's calendar? Type "cal". Need next month's? Type "cal 01 2024". Need date of Greek Orthodox Easter, or a Julian-calendar date? Type "info ncal"]

[doublelayer]

Re: Intuitive GUI? My arse.

My suggestion is to write a quick script in any language of choice that looks something like this:

for directory in path_environment_variable:

for filename in directory:

manpage = output_from_command(man filename)

synopsis = manpage.parse_line_starting_with("Synopsis")

print(filename +": " synopsis)

The problem comes when you have commands that don't structure their man pages like that, don't have a useful synopsis when they have one, or the many things in there that don't have man pages.

Writing code in the comment box doesn't work well. It was indented properly when I put it here.

[Old Used Programmer]

Re: Intuitive GUI? My arse.

Check out the "apropos" command.

[Old Used Programmer]

Re: Intuitive GUI? My arse.

Try "cal 09 1752". Then figure out why the output is correct.

[Bill Gray]

Re: Intuitive GUI? My arse.

Nice! I didn't know it would do that.

I'd say picking that date as the switchover is a minority choice, though. The astronomy code I wrote has the switchover in October 1582, when the Catholic world of that era dropped ten days. I think Turkey didn't switch until 1923.

man cal says that unless you specify a country code, ncal

tries to guess the switch date from the local environment or falls back to September 2, 1752. This was when Great Britain and her colonies switched to the Gregorian Calendar.

So if some of our fellow commentards run cal 09 1752 and say "so what?", that's why.

[nautica]

Re: Intuitive GUI? My arse.

Neither "cal" or nor "ncal" gives you 'Stardate'. Yet. (but programs exist on the interweb which do; for Christmas, 2023, at 10:50 am EST, Stardate is -299017.93093607307)

[rcxb]

Re: Intuitive GUI? My arse.

but if you're asking a question like "What do I need to perform [action]", you don't have any way of finding that out quickly from the interface.

If you learned "man -k" first, you do.

And the GUI isn't any better in many cases. Sure, there's a list of programs, and a menu, and obvious close button, but more than that and you just need to start guessing, looking around EVERYWHERE, and just hope you get lucky and find the exact context menu you need.

How about formatting drives, or the famous example of ejecting a disk on a Mac?

In fact the Windows UI has gotten so completely unusable that a search function had to be implemented, just like you're at the command-line or something...

Going further afield, I'd also point to the IBM HMC web UI as a counter-example... There are so many different contexts, so many options in each, and many of those options go a dozen steps deep with sub-options that if you don't have any idea at all where to look it would literally take you YEARS to search through possibility. A situation that can be resolved by just having one page of common CLI commands... Compare to needing several pages of explanation for just ONE thing in the web UI, describing where to navigate to in the GUI to find the same info.

[doublelayer]

Re: Intuitive GUI? My arse.

The man -k command is a pretty rudimentary search facility which usually doesn't work. It can't handle any kind of complex query, and it falls back to hoping you can find a keyword that only matches the command you're looking for with it being quite easy to get nothing or twenty unrelated things instead. Here's an example. I've installed a command, pdftotext, which does what it sounds like. Imagine that someone new has sat down at my terminal, doesn't know that command exists, but wants to do that.

man -k "convert PDF to text"

convert PDF to text: nothing appropriate.

Well, maybe the quotation marks are not right here? They wrapped it because it is a command line argument with spaces in it, but when you do that in a search engine, it means to literally find the phrase. Let's try without.

$ man -k Convert PDF to text

30-systemd-environment-d-generator (8) - Load variables specified by environment.d

Git (3pm) - Perl interface to the Git version control system

RAND (7ssl) - the OpenSSL random generator

__fbufsize (3) - interfaces to stdio FILE structure

__flbf (3) - interfaces to stdio FILE structure

[over a thousand more results removed]

Fine, so maybe a phrase isn't the best search pattern. We don't want a thousand results. What if we use the smallest term possible:

$ man -k PDF

pdfattach (1) - Portable Document Format (PDF) document embedded file creator (version 3.03)

pdfdetach (1) - Portable Document Format (PDF) document embedded file extractor (version 3.03)

pdffonts (1) - Portable Document Format (PDF) font analyzer (version 3.03)

pdfimages (1) - Portable Document Format (PDF) image extractor (version 3.03)

pdfinfo (1) - Portable Document Format (PDF) document information extractor (version 3.03)

[8 more results]

This would seem to help a bit, after all I only have thirteen PDF handling tools installed here and they all came from the same package anyway. However, what happens if I run the same command on, for example, a system where I have a lot of LaTeX tools, which output to PDF. You get pages even with a terse search term like that. The search facility is very broad and the only way to restrict things involves regular expressions, which can work (man -k "PDF.*text.*convert") or can fail (man -k "PDF .* text .* convert"). Yes, the latter search pattern doesn't work because the description we're looking for has PDF in parentheses. This worked because I already knew the right command and could work back to a search pattern. For a user who doesn't know what the command's description has in it, they will have many more problems.

[yetanotheraoc]

Re: Intuitive GUI? My arse.

Well yes, info and man work best when you already know the name of the command. Otherwise a web search works great. For "linux man convert pdf to text", duckduckgo gives: first, a linuxuprising.com tutorial mentioning pdftotext in the summary; second a linux,die.net online man page pdftotext(1). I noticed the same problem on Windows and Mac, and on iOS there is *only* the web for help.

[Peter Ford]

Re: Intuitive GUI? My arse.

The apropos command works on my Mac:

% apropos pdf

snmpdf(1) - display disk space usage on a network entity via SNMP

Not much use though...

[rcxb]

Re: Intuitive GUI? My arse.

That seemed to work reasonably well for you.

What is your better GUI alternative?

Will searching for "convert PDF to text" in Windows quickly find a solution?

Is there a "convert PDF to text" icon on everyone's desktop, or in everyone's applications menu?

Is there a "convert to text" option in the context menu if you right-click (or ctrl-click) on a PDF?

Does Acrobat Reader show a prominent "Convert to text" icon, when you open up a PDF?

I don't see this being a failing of the command-line. If you need to do something new, you're going to have to spend a little time figuring out how to do it, whatever UI you are using.

[doublelayer]

Re: Intuitive GUI? My arse.

I made two points in two comments, and I think you may have mixed the two to disagree with them. The pdftotext example wasn't about a GUI being superior, it was to demonstrate why "man -k" is not a functional solution to finding a command you didn't know about. And no, it did not work well for me in my example. I only found the command because I already knew it existed and was able to figure out what the search term needed to be to make it come up. I pointed out why several logical choices that a user who didn't know the command existed would make completely failed to find the command. I had a second example which I decided not to include because it would have been similar, just a lot longer and less successful. You are correct, however, that the GUI would not necessarily solve that problem.

However, while a GUI won't make it obvious what every installed program does, it does make local option discovery easier for the unacquainted user. You can pull up contextual menus on an object and get a list of actions that can be taken on the object. This is quite useful in finding out what actions you can take, whereas the command line often doesn't have that because they expect the user to understand which commands you can send streams to and what they do. The original example of how to shut down Windows demonstrates this. I don't know how long it took them to think that the big button opens a menu and maybe the shutdown option would be in there, but since there was no other system menu, it probably wasn't very long. Once they opened that menu, they could explore all the other things in there and, knowing what options they had, start to use them. If you don't know what options are available to you, a GUI usually tells you that information more quickly than a CLI does. That doesn't make the CLI bad, it makes it harder to learn quickly, but since the CLI also comes with a lot of power and convenience once you've done that, it's still a valuable skill to have.

[Anonymous Coward]

Re: Intuitive GUI? My arse.

GUIs are never better, functionally speaking...GUI design is opinionated...which means you don't always get access through the GUI to all the possible features and combinations, only what the developer decided that you needed and was willing to expose.

They're only better if you'd struggle to get any functionality at all otherwise.

[doublelayer]

Re: Intuitive GUI? My arse.

"GUI design is opinionated...which means you don't always get access through the GUI to all the possible features and combinations, only what the developer decided that you needed and was willing to expose."

That's all interfaces. Developers of CLI tools have exactly the same problem. They run out of single letters for flags, the new option will conflict with an old one and users will complain if any part of the interface changes, the new option requires them to come up with a complex command syntax and write a parser for it and they really don't think the users will use that interface enough to justify that work, or they don't want to write the hundred lines that the new option will require to reject invalid combinations, so they leave it out. That is if they can, for example the other options are available in a config file somewhere or they're writing a frontend to something someone else wrote which has the option. Whenever you run a program, you are going to get the options the developer chose to put in it. A GUI doesn't necessarily have any fewer options than a CLI, and the best way of knowing which one has more options is to know which one came first because it probably got the canonical set, while some developer figured that their version could skip something that they thought was unimportant.

[I could be a dog really]

Re: Intuitive GUI? My arse.

If you already know a command exists, you can probably look up a help page on it, but if you're asking a question like "What do I need to perform [action]", you don't have any way of finding that out quickly from the interface

Much the same as modern Windows programs. At least with menus you could look through the menus, but with the ribbon, you have a load of non-intuitive icons, which may or may not have non-intuitive names, and often you have to find the right tab on the ribbon, then the right group, then pop down a non-obvious menu, to find something with a non-obvious name. Or, you use the help, which (if you know what to ask for) tells you the command - but "irritatingly" does not tell you WTF to find it when you want it again in 2 minutes time. The number of time I have to go only and use $favourite_search_engine to find someone's web page where they describe how to do something ...

For CLI, apropos is useful to have installed.

[trindflo]

Re: Intuitive GUI? My arse.

One of the most unintuitive things about Windows is where they hide the network settings - and it changes with every version! I stopped trying to find it at some point and just memorized ncpa.cpl

[Sceptic Tank]

Re: Intuitive GUI? My arse.

You struggled with the Start button? And you admit that?

[Anonymous Coward]

Re: Intuitive GUI? My arse.

At least it was better than what's there now.

"Ok, now click the thing with four squares, it's probably on the lower left corner or kind of in the lower middle of the screen."

Windoze has gotten less usable with every release. It's virtually impossible to talk a typical user through anything now. That's why remote access software is so popular with tech support, it's the internet version of "just get out of the fucking way and let me do it".

At least it's still possible to talk a Mac user through most stuff.

[Terry 6]

Re: Intuitive GUI? My arse.

Which happens to be no different to the button that starts my car. And it's not hard to figure out that the button you use to "start" something is the same button you use to end it. It's what we do all the time irl.

[Bebu]

gruesome

Sumo sans malawashi

Not at all a nice picture.

[Joey Potato]

Re: gruesome

Not nice, but interfaces are more more discoverable.

[tiggity]

Re: gruesome

I'm sure there is some fan fiction out there that is all in favour of it...

Some of the worst things on the internet are to be found in fan fic - long since gave up on reading it as writings that initially seem OK far too often segue into deviancy (the cynic in me says probably the whole aim of the writer, the initial normal phase just to draw the unsuspecting in, before unleashing the perviness)

[HuBo]

Separate out the mawashi

Human-machine interfacing is the pits! Nearly everything is elegant and efficient inside the computer, with data in all appropriate formats, but add a user to the mix and all of a sudden everything has to be translated back and forth between internal and external representations, at huge expenditures in energy and code. Just converting sequences of characters, say 3.14259, to IEEE-754, and converting back to text (after some operations) takes hundreds of code lines, unneeded when humans are excluded.

This gets worse of course with GUIs, for which millions of bytes have to be dedicated to frame buffers, to thousands of fonts for multiple human languages, to thousands of callback functions for window control objects, to thousands of lines of code to manage human input devices (touch screen, mouse, keyboard, ...), and so forth. Take out the human-interfacing part of all this and you have a pretty streamlined, lean, and efficient system. Add it back in and, wooof, super-bloat!

I wonder of the degree to which the human-interfacing part of computing could be physcially abstracted out and implemented into its own chipset (and RAM), aimed at converting from external to internal representations, and back, in ways that satisfy the sensory characteristics of human organisms (or even dogs, cats, bees, ...), while computational backend chips would deal strictly with processing of internally-represented data. GPUs for example already deal with some highly-specialized aspects of front-end output processing for human-interfacing of visually oriented data (and are not needed without a machine-connected human).

[yetanotheraoc]

Re: Separate out the mawashi

"Take out the human-interfacing part of all this and you have a pretty streamlined, lean, and efficient system."

If a tree falls in the forest ...

[Bebu]

While keyboards

are the a major input device the disconnect between GUIs and CLI will likely remain.

Having used a pen based tablet for a few things over the last year or so, it appears to me that pen oriented GUIs could be very effective and I found creating text in Vi using handwriting recognition wasn't too odd either.

What is fairly obvious is that interface design becoming crappier and crappier - the products of deranged pigeons with an acid addiction. Fundamental concepts of orthogonality and completeness seemingly unknown.

The first time I ever encountered gratuitously coloured text was in one of (Dr) Bert Feggs Nasty Books. Still nasty.

[Pete Sdev]

GUIs were and are intended to demystify the computer as a practical tool, especially as hardware got more capable and more human life was sucked in. At this, they have been wildly successful. At the same time, they have obfuscated the core ideas of how a computer actually works.

All true, and not a bad thing. The percentage of car drivers that are also mechanics is small. As is the percentage of mobile phone users who are electronic engineers.

It being possible to use a complicated device without knowing how it works is an achievement.

The use-case of the end-user and the use-case of a maintainer or administrator are so different that not one single interface will suffice.

[Doctor Syntax]

It's important to remember that any OS, irrespective of its user interfaces, is designed to present a series of false impressions to the user. The ongoing stream of CPU operations is presented as a collection of distinct processes. The blocks of data scattered and intermixed effectively at random over the storage device are presented as a set of places containing coherent files. A single storage device may be presented as several distinct devices and, at least in Unix and derivatives, multiple devices will be presented as one. Presenting all this through multiple UIs as required is just another addition to the box of triicks.

[Flocke Kroes]

Re: Windows CLI text editor?

I have been a penguin for a long time but even I guessed the answer to "which text editor to add?" was probably "your favourite may well be installed already". Even if it wasn't "all of them" doesn't cost much storage space and avoids tech support being asked "How do I install joe?"

[Gene Cash]

Re: Windows CLI text editor?

I tried to install EMACS on a new Debian box I set up a week ago:

Retrieving bug reports... Done

Parsing Found/Fixed information... Done

serious bugs of emacs (→ 1:29.1+1-5) <Outstanding>

b1 - #1041415 - emacs: fails to install: post-installation script subprocess returned error exit status 1

Summary:

emacs(1 bug)

Oops. Guess I'll be waiting a bit.

[Doctor Syntax]

Re: Windows CLI text editor?

"emacs(1 bug)"

Seems reasonable.

Ducks.

[BlackPeter]

Re: Windows CLI text editor?

winget gnu.nano install

[Contrex]

Re: Windows CLI text editor?

You mean

winget install gnu.nano

I think

[BlackPeter]

Re: Windows CLI text editor?

you are correct. i was in too much of a hurry. :(

[david 12]

Re: Windows CLI text editor?

The weird thing is, the explanation for the consideration of a CLI editor for Win64 is that "EDIT" is not included in Win64.

But EDIT is not and was not a CLI editor.

The original link is:

https://github.com/microsoft/terminal/discussions/16440 , and the weirdness continues:

The title is "Windows Feature Exploration: Default CLI Text Editor", and the example is just opening vim, suggesting that the problem is only that there is no default editor that PS can open. The originator thinks that there is no GUI editor available, by default, at the CLI.

But that's false too: Notepad is still part of Win11. It's Wordpad that's been deprecated. And Notepad is available by default from the CLI, by reason of its location in the default path: it was Wordpad that couldn't be found by default. If you type "Notepad text.txt", Notepad opens with text.txt. If you type "Wordpad text.txt" you get "not recognised as an internal or external commnad".

I totally get the advantage of including a scriptable editor. The thought bubble from MS seems to indicate that there is at least one MS product manager who has got no idea what he is talking about.

[nautica]

Re: Windows CLI text editor?

If I remember correctly, 'EDIT' was an ancillary function of Microsoft's Basic; if MSBasic were not installed, one didn't have the EDIT program to use.

...and EDIT was, most definitely, not a terminal, or CLI, editor.

[nautica]

Re: Windows CLI text editor?

"MS-DOS Editor, commonly just called edit or edit.com, is a TUI text editor that comes with MS-DOS 5.0 and later,[1] as well as all 32-bit x86 versions of Windows, until Windows 11. It supersedes edlin, the standard editor in earlier versions of MS-DOS. In MS-DOS, it was a stub for QBasic running in editor mode. Starting with Windows 95, MS-DOS Editor became a standalone program because QBasic didn't ship with Windows..."

From "Wikipedia", "MS-DOS Editor", here.

[Denarius]

well said

Good argument well explained. I spent many productive , sometimes happy, hours using an emulated VT100, unix shell and vi. Got work done, bugs identified and squashed, happy customers. the CLI can be way less stressing than using a GUI, but it does need more training for the users. In short, use whatever does the job but I agree modern GUIs are becoming unusable. No order, discernible structure and appalling colour choices.

[Flocke Kroes]

Re: training

Training users to use GUIs is returning revenue: next year the GUI will be different enough to break whatever sequences users have learned.

If a programmer submits a patch to change the way one option behaves on an ancient command line tool then a hundred other programmers will get the patch rejected with prejudice because it breaks their scripts.

[Kristian Walsh]

Re: training

Your argument works against CLI tools too. Features often get added to commands along with inconsistent ways of enabling them: lots of projects commit the sin of not reviewing the interface to a new feature, only its code. There is definitely a failure to understand that User Interface also applies to CLIs, and that the same principles of being able to reapply things you learned already to a new tool should be followed. But once an invocation method is in place, it’s there for good, and you end up with batshit-crazy commands like ip or git whose options and submodes form a contradictory ball of crap that you just have to memorise (or keep looking up on StackOverflow).

Linux throws this into sharp relief because it has the worst examples of CLI tool design (e.g., anything networking related) installed beside the best (e.g., the gnu coretools, which have carefully preserved the principles of the Unix userspace tools while adding new features)

[J.G.Harston]

Re: well said

Squashed, happy customers? That's an achievement!

[Richard Grimwood]

“Any magic, insufficiently explained, is indistinguishable from technology." -Christopher B. Wright

[Doctor Syntax]

"the early bootstrap of learning enough to learn more"

Lovely phrase Rupert. I'll take that as an early Christmas present. Thanks.

[andrewj]

Eight Megabytes And Constantly Swapping seems quaint in comparison to modern bloat.

[Flocke Kroes]

Re: GUIs were and are intended to demystify the computer

I thought GUIs were intended to hide most of a computer's functionality so options would not cause users to get stuck pondering a choice. Apple demonstrated their understanding of their target market by changing the number of buttons for their mouse: Unix was 3, Mac started with 1. When Microsoft released their GUI they went with 2 so Unix users could not paste (until chord middle was implemented) and Mac users would only find the menu of other things that could be done by accident (and when they were not expecting it).

[Kristian Walsh]

Re: GUIs were and are intended to demystify the computer

You keep saying “Unix” when you mean “X11” there. Unix has no GUI, and therefore has no mouse.

The three-button mouse was dropped because it was hard to use. It was the one part of the Xerox Alto design (inspiration for Macintosh) that consistently confused users. Even when test users had realised that there were three buttons, shifting their grip on the mouse often resulted in mis-clicking as their fingers shifted to cover different buttons. Add to this that the third finger is also less dextrous than the first two, which made the right button slightly harder to use, and some kind of simplification was always going to happen. A single-button design has the advantage of no possibility of confusion, so the learning-curve is made easier, but it does limit the usefulness of the mouse once the user has become accustomed to using it. The two button design is a compromise that allows for additional function while solving the three-button device’s problems - not just Microsoft, but almost every other vendor of mouse-controlled PCs of the mid-1980s used a two button device; the only personal computer of this era I can think of that shipped with a three-button mouse was Acorn’s Archimedes (now more famous for being powered by the very first ARM CPU).

Apple stuck with a one-button mouse far longer than it should have (resulting in the awkward “control-click” invocation for contextual menus), but it’s 18 years since Apple finally offered a two-button mouse with its computers.

I’m surprised that the bigger ergonomic failure of the original Mac hasn’t been mentioned: pull-down menus. Before MacOS 8 gave you an option, on old Macintoshes, in order to select from a menu, you had to move to the menu bar, press the button, and then keep it held so that the menu would stay visible until you reached the item you wished to select, and then you released the button to select that option. [Contrast with the current behaviour: click menu title, move mouse to desired item, click again to select]. “Pull-down” worked okay for short menus, but it got progressively more difficult to navigate for long ones, and became an ergonomic nightmare when System 7 introduced hierarchical submenus. For users with limited mobility or strength, this one feature made Macs almost impossible to use.

[Ozzard]

Re: GUIs were and are intended to demystify the computer

Play with Smalltalk sometime - red/yellow/blue buttons, where red is "poke whatever's at the pointer", yellow is "pull up a context-specific menu about the thing under the cursor", and blue is "pull up the system menu to do generic things" (for example close the window). Makes huge sense, very quickly, and you don't get RSI moving to small targets for menus.

It's well worth looking at Alan Kay's team's work on this stuff.

[Kristian Walsh]

Re: GUIs were and are intended to demystify the computer

The problem was that inexperienced users would have to keep looking at their hands to ensure they pressed the correct button, thus breaking their gaze. It has nothing to do with the consistency of functions or colour-coding - and colour-coding isn’t useful if it makes you break your gaze to see which colour button you’re pressing. The Smalltalk environment’s use of two different menus on two different buttons isn’t that good a UI: your buttons are: “poke this”, “a menu” and ... “a menu again, but a different one”. Fine when you know there’s a distinction between contextual actions and system actions, but new users need to learn this.

Apple solved the “small targets for menus” by putting the menu-bar at top of the screen - the boundaries of the screen are, in effect, infinitely-sized when you use a mouse. Apple’s other very good idea was to make the commands that were buried in menus directly invokable by simple keyboard shortcuts, and then standardising those common key-commands across all applications: other systems allowed you to navigate the menus by keyboard (= more keystrokes to get what you wanted), but never tried to enforce any kind of standard for keyboard commands.

However, as noted in a post below this, Apple failed by not ditching the “double-click” action, which is the most difficult gesture to learn with a mouse - the default double-click time was just too short for new users, but because of how the shell was written, making the interval too long would have made other parts of Finder unresponsive to clicks. (The other hard-to-learn mouse action on Macs, later copied by Windows, was renaming a file: click on the file name, hold for just long enough, and hope that it causes the label to turn into an editable field)

The comparison between Smalltalk and desktop PCs isn’t really valid: Smalltalk was by its own definition a tool for experienced computer users - as much as it pretends not to be, it is a programming environment, not an application. The desktop computers of the 1980s on the other hand, needed to be far more accessible out-of-the-box. The Macintosh in particular was designed as a computer that would be used primarily at home: you got a manual with it, but there would be no friendly co-worker at the next desk to help you get to grips with the system, let alone an administrator - the idea that there would always be an “IT department” or “Admin user” to fix things or do difficult configuration tasks is the single biggest factor that prevented Windows getting to the level of “it just works” that you saw in the 1980s-1990s Macintosh.

[Old Used Programmer]

Re: GUIs were and are intended to demystify the computer

First time I ever encountered a Mac, I couldn't figure out how to do anything. "Double clicking" is not intuitively obvious. (And, no, I couldn't look it up in the manual. The owners of the Mac didn't have the manual yet. It was a test and evaluation system owned by UC Berkeley.)

[IvyKing]

Re: GUIs were and are intended to demystify the computer

Back when I was a freshman at Cal, the UI consisted of the white "CDC 6400" punch card with the account number and job name punched in followed a couple of job cards (lgo, cldr, etc), followed the program data cards and finally the reddish 6789 card. Editing was punching a new to card to replace an old card. A couple of years later, I was hearing about something from Bell Labs provoking comments like "If Bell Labs hadn't invented the transistor the Phone Company would still be using vauum tubes" and their programming language being an abomination in the eyes of the Lord".

[Terry 6]

Re: GUIs were and are intended to demystify the computer

press the button, and then keep it held so that the menu would stay visible until you reached the item you wished to select, and then you released the button to select that option

Have they done away with that, then? Always IMHO a stupid design*. I hated it when I needed to use a Mac- a few decades back. In fact it's the main, perhaps only, reason that I refused to use one at work, when I was at a site that had some.

*Apple fans at the time seemed to delight in it, yet apparently now it's......gone?

[Kristian Walsh]

Re: GUIs were and are intended to demystify the computer

Yep. It silently changed in 1997 with MacOS 8.0. If you clicked and held a menu title or a popup-menu control, you got the old behaviour (release to select), but if you just clicked, you got the new, industry-standard behaviour instead (click again to select).

The original feature itself had poor usability, but what existed after MacOS 8.0 is actually an example of good UI, in that it allows you to discover different ways of accomplishing the same thing. When it changed, people who were used to the old way of using menus on Macs didn’t even realise it had changed, while people who were unfamiliar with Macs didn’t even know that there was another way of using menus compared to on other windowing systems.

(Bonus shout-out to Atari GEM with it’s drop-down menus, that automatically appeared on mouse-over... I can’t decide if they’re better or worse than the Mac pull-down variety)

[VicMortimer]

Re: GUIs were and are intended to demystify the computer

Apple has never shipped a 2-button mouse.

A brand new Magic Mouse is, out of the box, a 1-button mouse. You can configure the touch sensitive surface to act like 2 buttons, and most users do, but I've got lots of clients who are much more comfortable with it as shipped, single button.

The 1-button mouse was the right call in 1983 when it shipped with the Lisa, and it's the right call today. It's easier for new users.

[Terry 6]

Re: GUIs were and are intended to demystify the computer

I have to reluctantly agree that I think you may be right. While I use the right click ( in Windows) a lot. I've seen so many users that only ever click the right button by accident and then get confused/worried when strange unexpected menus appear.

[John Sager]

Workspaces

The really useful adjunct to terminal emulators on Linux. The only permanent windowed apps on my laptop are the Firefox and Thunderbird. I have, currently, 11 terminal emulator windows scattered over 3 workspaces, plus browser & email on another. It's just convenient to have different CWDs on the various terminal windows. I do use other graphical apps like Audacity, IDEs and graphical editors, but even building apps for Espressif, Zephyr, etc I prefer the CLI.

[nautica]

Creating a new CLI editor as elegantly simple as vi, edlin, or pico, et al, is beyond the capability of most, today, simply because most software designers, and their managers, feel that their proficiency at 'coding' (or not, sadly) relieves them of the responsibility to relate to the needs of the user, i.e., to understand precisely what is required (and, even more importantly: what is not required) of a truly good and well-thought-out man-machine interface--which responsibility is the paramount reason for their very existence.

-----------------------------------------------------------------------------------

"A little retrospection shows that although many fine,‭ ‬useful software systems have been designed by committees and built as part of multipart projects,‭ ‬those software systems that have excited passionate fans are those that are the products of one or a few designing minds,‭ ‬great designers.‭"--Fred Brooks

[Anonymous Coward]

Both have their places

But a good GUI can help bucketloads with the weird switches and what they do in CLI programs. If you see a checkbox that greys out a whole panel. it's a prompt as to what that section does and what information it needs.

[RegGuy1]

Re: Both have their places

That's when man is your friend.

[Kristian Walsh]

Re: Both have their places

Have you seen the man-pages for modern Linux tools?

Actually, even the Unix ones aren‘t great these days: once tools gained more options it became fairly clear that the “Examples” section should have been the second one after the basic description, with the most common use-cases listed there. In too many pages, the “Examples” is an afterthought, but it’s the one place that should shows you how to use the the tool to do something useful (best set of examples on a man-page I’ve seen recently is for the hex parser/display tool xxd).

[Howard Sway]

What's best - GUI or command line?

The answer is GUI and command line. The combination of using both together is the most efficient way I've found of coding, compiling and testing. I started my career in the days of dumb text terminals, when automating repeated tasks via scripting was essential if you wanted to be anywhere near efficient, and you in effect built your own custom commands specific to your own preferred way of doing things.

When Windows arrived, it was clear that GUI editors with mouse copying and pasting were better in many ways for text based work, but I always hated the MS command line after being so used to the Bourne shell, and the old way of scripting my work shrivelled for a few years.

Then I started to work on Unix systems again from Windows clients, and tended to work on short scripts in vi on the unix server, and bigger ones that required lots of copy & paste in Notepad++ on the Windows machine before copying them over to the Unix machine to run.

Finally, linux became my whole work environment, and I still use vi for small scripts as required, but for programming I use a GUI text editor (combination of mouse and lots of keyboard shortcuts) to code and the command line for building / running stuff on the same machine. On most projects the command line interactions become little more than hitting the up arrow and return key to re-run previous commands many times a day, whilst I still have a nicer looking coding environment, more efficient for editing multiple files in.

[Terry 6]

Re: What's best - GUI or command line?

Absolutely. I'm not a coder. I haven't written a serious programme in 40 years ( and then not many). I want to be able to do everything I need in GUI..

But sometimes you just can't.

[nautica]

Re: What's best - GUI or command line?

"... the command line interactions become little more than hitting the up arrow and return key to re-run previous commands many times a day..."

Just one outstanding example of elegant simplicity in the command-line interface...

[43300]

CLIs are appropriate for more complex tasks, and often the most efficient way of doing it.

Where they are not appropriate is when it's a simple change to one setting, and the provider doesn't provide that functionality int he GUI for no good reason. Yes, Microsoft is a prime example where there are some things where you have to use Powershell for simple settings changes. This is normally because they are trying to force something on users so make it as much hassle as possible for the admins to turn it off.

[RegGuy1]

What? You mean like setting the GUI to show file extensions, originally because they thought it would frighten granny.

Sorry, but they are scumbags. Just like they chose a backslash because Unix uses the forward slash. And I still can't get a refund for the fact I never use the virus.

[Grogan]

Hiding file extensions is one of the most FOOLISH things I've been shaking my head at since Windows 95. You have a UI that determines what action is to be taken based on the extension of the file... and they hide them by default. If I work on a computer, I change it to show extensions and hidden files (not system files because it can cause strange files to appear on desktop and other user shell dirs, that truly do confuse)

"filename.jpg.exe" with an image file icon, anyone?

Yeah, I don't use Windows anywhere either. I used to keep a Windows install for games, but that's not been necessary for years.

Not only that, when a user incorrectly associates a file with the wrong program, it makes it even more confusing. For example, command.com misassociated, with extensions hidden. The user will see "Command" and it will get a "notepad" icon. I had one person print it out and show me. "What's all this gibberish" rofl!

[yetanotheraoc]

it's a feature

"filename.jpg.exe" with an image file icon, anyone?"

The users of the client were going to the network drive and running it there, which made it slow. I created a batch file which when double-clicked would copy the client locally and launch the local copy.

Nobody used the batch file (well maybe one or two used it, but mostly not).

So I moved the client and the batch file to a different network folder, and created a shortcut (.lnk) to the batch file, with the same name as the client. Then I gave it the same icon. And because they were not shown the extension, the users were happy.

[43300]

In fairness, this is one where Microsoft can't win either way - if extensions are visible by default you will get some users changing them, clicking yes to the warning, then complaining that their file won't open!

[VicMortimer]

Old Macs did it right - with a 4 character file type and a 4 character creator type, both hidden from the user.

Sadly, that was lost when Mac OS became UNIX.

[nautica]

Sadly,some things can't be upvoted. Or downvoted. Or answered.

"...Sadly, that was lost when Mac OS became UNIX."

So, here's the vote on this one: ‽ ‽

[captain veg]

Re: they chose a backslash because Unix uses the forward slash

Er, no.

Before DOS had any notion of subdirectory the forward slash was reserved for command-line switches. Inherited, I think, from CPM.

-A.

[Jason Bloomberg]

-h or --help

Hard to remember but I am eternally grateful to coders who report "use --help" rather than give me what I want when I use -h, especially when not specifying arguments gives me the help I was after anyway.

It's whether the second argument, ala "npm install", is a command or an option which mostly catches me out these days.

[Kristian Walsh]

Re: -h or --help

I usually use “-?”, as I’m afraid that someone will decide that -h is a synonym for “--hangup”, “--hard-delete”, or something equally destructive, but yes thad does annoy me.

The problem with tools like npm (or apt, git, or ip) is that they’re just dispatchers to other commands: the first argument is the actual command that you’re asking for. That’s against the basic philosophy of Unix: “one command, one function”, but it has become the norm for modern tools, and we’re stuck with it now.

[doublelayer]

Re: -h or --help

"That’s against the basic philosophy of Unix: “one command, one function”, but it has become the norm for modern tools, and we’re stuck with it now."

I think that makes the most sense. A package manager should be able to manage packages, which means that it should be able to install and remove them. Is "apt install" and "apt purge" really that worse than "apt-install" and "apt-purge", because that's what you would get if you insisted that the app-install command be unable to delete a package. I don't think the philosophy was that each minor difference in function should be handled by a completely separate program, but that programs shouldn't succumb to scope creep away from their initial function. Installing and deleting packages is one function. Starting, stopping, and reporting on a service is one function.

[Kristian Walsh]

Re: -h or --help

No, your example isn’t right. If apt had followed the Unix pattern, the syntax would be something like “apt --purge <packagename>” and “apt --install <packagename>”: one tool, one task, but you seelct the action using options, not magic-word “sub-commands”. (Compare with how “tar” both archives and unarchives files).

“apt” isn’t the big villain here, though. Look at “ip” and how many things it does, and how different the syntax gets depending on where you are.

One of the unfortunate side-effects of the trend for sub-commands is that they tend to be chosen from a misguided desire to make the whole command invocation read like an English sentence. That’s a fool’s errand (you quickly get to a function that cannot be cutely expressed like this) that also makes the system less usable for people whose first language is not English. Unix did not have this problem to the same extent: the commands were odd abbreviations, and knowing that “ls” was short for “list” wasn’t really much of a help in learning the system (I, a native English speaker, actually only learned that particular command origin a year or so after I’d already been using Unix)

[doublelayer]

Re: -h or --help

So your complaint is about the lack of --? That's really not the important part in all of this. Lots of commands have different syntax for their parameters. For example, do you do --param value or --param=value? It doesn't really matter, because the man page tells you that. Similarly, --install or install makes no difference. IP is different, but it doesn't really change the mess you're going to have regardless. IP could be split into different programs, and each program's arguments could be simpler, but then you'd just have thirty commands for doing something to a network interface and the complexity would be figuring out which of the thirty you needed. It would be no easier than figuring which of the many functions of IP you want and how to invoke that.

[nautica]

Re: -h or --help

This entire comment appears to be offered in support of a personal opinion, only, and is not borne out by fact. No situation has ever been encountered in which "...they [i.e., sub-commands] tend to be chosen from a misguided desire to make the whole command invocation read like an English sentence...".

Offered as a very simple counter-example is the inxi command, the following example of which is used to obtain a fairly complete listing of one's system parameters (furthermore--I'm still having difficulty forging an English sentence, using the (supposedly English) 'word' which is at the very root of this very "English-sentence-like command invocation "--"inxi" ):

sudo inxi -FmxZ , or, sudo inxi -F -m -x -Z ["sudo" is needed by the "m" option because root privilege is required in order to display installed memory. You will be asked for a password--the same one you use to sign in to use your Linux distro]

This is a simple example of the "inxi" command. Read the full listing of all of "inxi"s capabilities by typing either "man inxi", or "info inxi" at the terminal's command line. You will quickly be disabused of the notion that the creator(s) of "inxi" were laboring under a "... misguided desire to make the whole command invocation read like an English sentence...".

[captain veg]

A pedant writes

It's "a la", two words. Or, better, "à la". French, you know.

-À.

[Grogan]

I use a combination of both. Sometimes file manager, sometimes file manager and pop open terminal to work in that directory. Sometimes graphical text editors/utilities, sometimes vi and diff etc.

Pretty much never graphical configuration utilities though, that's a great way to stuff things up. I once trashed a web server using "Webmin" back in the day. All I did was change one setting to disable a module. Little did I know, that webmin didn't just edit the existing httpd.conf, it generated a new one, wrongly, because I didn't use webmin to configure it. It was like day one with this server and I didn't have any backups of my configs yet. I never used anything like that again. Another example of a stupid configuration utility back in the day, that caused things like that to happen, was "linuxconf". That was decades ago, but once bitten, twice shy.

I'd use a "control center" if I'm using a desktop environment with complex settings, but not for system configuration settings.

Even in Windows sometimes it's better to use the CMD shell. For example, "rmdir /s /q" is faster than trying to delete, say 2 years worth of disconnected "temporary internet files" using the file manager that does more reads and processing of stats etc.

[Roo]

NeXTSTEP

Not sure I'd lay the lack of CLI on Jobs, after all he did found NeXT, which produced an OS (NeXTSTEP) that was built on a MACH kernel with a BSD userland, and had a pretty neat GUI complete with a terminal emulator (ie: CLI) application. As it happens NeXT was bought by Apple on the return of St. Jobs, and Darwin just happened to be a MACH kernel with a BSD userland - exactly like NeXTSTEP.

Apparently the NeXTSTEP terminal emulator lives on in Mac OS/X, though I would guess it must have changed beyond all recognition by now... Surely ?

[Tim99]

Re: NeXTSTEP

NeXTSTEP was good (and [one of?] the first OOP GUI development IDEs?). If you had the money - As a result, the main paying users were spooks and the military, with some academics (who may well have got a substantial discount).

[Kristian Walsh]

Re: NeXTSTEP

It’s well documented that Steve Jobs hated text-driven interfaces (or at least he did once he’d visited Xerox Palo Alto). The Macintosh project, as originally led by Jeff Raskin was originally a keyboard-controlled product; Lisa* was the mouse-and-graphics computer that would lead Apple into the 1980s. But when Lisa bombed in the marketplace, Steve Jobs effectively took over the Macintosh development project and turned it into a cheaper Lisa (largely by following all of the advice he had ignored during the Lisa’s development).

Jeff Raskin’s original vision for Macintosh became the Canon Cat - a very different kind of computer, entirely driven by the keyboard (but with a couple of very powerful additional function keys): it had a longer learning-curve than a mouse-driven UI, but it’s the sort of thing that you could become extremely proficient at.

At NeXT, the command-line came for free due to the OS being built on top of BSD/Mach, and in any case, the target market for NeXT wasn’t the same as for Macintosh. The Mac was a general-purpose home/office computer, but the NeXT computer was to be a high-performance workstation for scientific research: in that market, shipping without support for Unix made no sense.

__

* it takes a special kind of personality to deny being the father of a baby, but then use that same child’s name for the most important project in your company, but that was Steve Jobs...

[Paul Hovnanian]

AutoCAD

Years ago, I took a class on AutoCAD. The instructor showed us the GUI menu item and then quickly switched to the CLI equivalent. She said that experienced users, once over the steeper CLI learning curve, found it faster to use.

Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D man quit ^C ^c ?Quit ?q CtrlShftDel "Hey, what does this button d..."

[Arkeo]

Not sure...

...but it seems to me that you have a grudge against distractions (and I totally agree) - but I remember writing my first short stories on a Macintosh Classic with Word 5.1 (I think). No CLI whatsoever. It worked just fine and it still does (not the actual HW & SW, I mean the principle).

I vaguely remember when I had to write something on a terminal, I think I was on Slackware back then. Then came Debian, Ubuntu and Mint. And I don't have to worry, or write scripts, for anything. It just works. Like that old Classic running System 7.1

And BTW, emacs and vi/vim suck. Even nano sucks. When I need to I usually just "sudo gedit", almost like on a *real* Mac from the 90s...

[nautica]

Re: Not sure... [and I'm really not.]

...in light of your last sentence, can't give you an up-vote; so I'll just respond, and very un-originally;

There's a time and a place for everything.

[yetanotheraoc]

This is Microsoft, right?

"When you're in a full-screen CLI, especially editing, what you get above all is focus. Compared to a GUI desktop or, heaven help our grasshopper minds, an in-browser task, it is supremely quiet and uncluttered. It is you and your keyboard, and text that wants to be free of variant forms and options."

Er, no. It's not a 2024 Microsoft CLI until it's integrated with Teams! And Copilot! And here are some words you might be interested in, brought to you by our Partners.

[Tim99]

For hours of entertainment

Where many would use a GUI based app, try ffmpeg on a *nix based OS CLI. I have learnt to like it. Most of the entertainment comes from fiddling with the program, and not from playing what you produced. Today I had hours of fun creating and adding chapters to a home movie: See ffmpeg.org:-

 ffmpeg -i INPUT -i FFMETADATAFILE -map_metadata 1 -codec copy OUTPUT 

[JulieM]

How I see it

Using a GUI is like pointing and gesturing in the hope of making a foreign shopkeeper understand what you want to buy.

Using a CLI is like speaking to the computer in its own language.

There probably will be times when you really do want to click yes or no to every instance of a word you are searching for and replacing; but the rest of the time, you can't beat sed.

[doublelayer]

Re: How I see it

"There probably will be times when you really do want to click yes or no to every instance of a word you are searching for and replacing; but the rest of the time, you can't beat sed."

Or the "Replace All" button? Which doesn't require your editor to close the file before you do it.

[martinusher]

What's the big deal about CLIs?

The CLI is useful because its simple, it creates compact commands that can be chained together in scripts to do quite complex tasks. Its really easy to implement on anything -- if you're working with bare metal then all you need is a UART or equivalent (often built into the JTAG interface) -- a couple of three line functions and you're in.

To do anything graphical requires a lot more code which implies a lot more hardware -- working hardware.

[CrazyOldCatMan]

as unthinkable as a Sumo wrestler without their mawashi

Nice to see a mention of my 2nd-favourite sport [1] on El Reg..

Mind you, Takakeisho nearly made me rage-quit when he blatantly cheated his way to victory in the September (he probably would have won anyway - Atamifuji doesn't really have the skills yet to get to the very top but Takakeisho not bothering to put his hands onto the Doyjo like the rules require (and the gyoji *not* calling a mata) slightly soured me. I notice that in the November Basho he was more careful to obey the rules so I assume that his oyakata probably Had Words along the lines of "the Japan Sumo association *will* take action if you keep on doing it"..).

Fortunately, my wife also enjoys it - she remembers watching wrestling on the TV with her gran in the 70's and sumo has a similar feel (but without the blatant scripting and match fixing!)

[1] First is the NFL. Mind you, we have some Japanese Roku gin that I'm only allowed to use during the 15 days of the Basho but there's no special drink for the NFL - unless the 49ers win the Superbowl - in which case I have a bottle of nice champagne at the back of the cupboard.. (BTW - the Superbowl is vary rarely the best game of the season - the divisional chamipionships are usually a lot better.

[nautica]

Re: as unthinkable as a Sumo wrestler without their mawashi

...got very interested in Sumo, and was a huge fan of the sport, when Jesse Takamiata (sp?) became the first US person (born in Hawaii) to go into the sport very big time...and created a lot of US fans of the sport, by the way.

My total lack of knowledge of the language--and the lack of Dallas-Cowboy-type cheerleaders--led to my not following very closely once Jesse retired.

------------------------------------------------

“The method [of learning Japanese] recommended by experts is to be born as a Japanese baby and raised by a Japanese family, in Japan. And even then it's not easy.”― Dave Barry, Dave Barry Does Japan

[Sceptic Tank]

CUI not my ... type

I find it interesting that the picture accompanying this article shows the (Linux?) top utility to trumpet the glory of CUI. But that app has a GUI for all intents and purposes even if it is text based. (Borland's Turbo Vision back in the day attempted to emulate GUIs in text mode and it worked fairly well until it got buried by Windows). I use the git CUI because [reasons], but I'm grateful that I can do my coding in Visual Studio and not have to echo, sed, awk, or COPY CON to get stuff done.

[archie99]

I always found Beginner Reconfigurable Interactive Editor (BRIEF) or b to those that know it - to be way ahead of it's time, intuitive and still the tool I use to mark and select columns rather than lines.

The programmatic support for C and Clipper when I used it was an even better invention at the time - now other editors can do the same and more, but I just like its simple interface, use of buffers, split screen and column select.

[StrangerHereMyself]

Sold

As far as code editing is concerned I'm sold on GUI editors. I, however, just now checked vi on Linux and it supports bigger screens than the cramped 80 x 25 line ones it was originally designed for. Amazingly it also supports syntax coloring!

However, vi is still a line based editor, which I find archaic compared to screen-based editors. So vim would probably be more to my liking.

[nautica]

Re: Sold

vi/vim for Linux and edlin for DOS have a lot in common...

edlin for dos--a line editor--was a real bitch--until one learned it. Then, driving it became automatic, as the old Volkswagen ads used to say. It stayed around so long because of one quality: the fact that it came with every version of DOS meant that it was universal; it meant that no matter what machine you were on, you had an editor

You still do, if you use DOS. Take the time to learn edlin (and vi/vim); the discipline will be good for you.

[StrangerHereMyself]

Re: Sold

I know darn well how to use vi, but I still prefer modern GUI editors, thank you.

I still use vi in emergencies on Linux when I can't get my desktop running and need to edit files.

[captain veg]

two things

There are two exceedingly brilliant uses for CLI.

One is emailing a command in text rather than inserting endless screen grabs of the steps to achieve the same thing in a GUI. The other is the existence of shell scripts.

If Microsoft (or Apple) had early on created a 100% visual scripting tool that worked in every context then we wouldn't be having this discussion. Is that possible? Can't see why not. Would it be easy? Probably not. So far as I can tell, they didn't even try.

-A.

[nautica]

Re: two things

"There are two exceedingly brilliant uses for CLI."

Here are two more exceedingly brilliant uses of the CLI which are unmatched elsewhere: software updating, and software upgrading. ["sudo" is required for administrator privilege; "apt" is the package manager for Debian-based distributions; "yum" and "dnf" are for Redhat; "pacman" is for Arch-based distros...]

-------------------------------------------------------------------------

To simply update software, type (at the command line, of course)

sudo apt update

To simply upgrade software, type

sudo apt upgrade

To perform both tasks at the same time, simply type

sudo apt update && sudo apt upgrade

-------------------------------------------------------------------------

Now, try updating and/or upgrading your software as easily as this using GUI methods.

[JulieM]

Some things are just hard

The fundamental problem with GUIs is that just adding a GUI onto a task that is inherently, fundamentally hard by nature does not actually make it any easier.

Sure, it's possible to create a graphical interface to script-building. You just drag icons from a "toolbox", line them up in order of what you want to make happen, then click on each one in turn to select the file you want it to act on, and any other parameters you want to pass. So, basically, drawing a flowchart on screen and filling in the details.

But it wouldn't be easy to use. Because script-building is an inherently hard task. It requires you to know what you want to do; and that is actually the hard part of the operation. Expressing it directly in words a computer can understand isn't necessarily much harder than pointing and clicking.

In the 1990s, I was doing PCB design on a Windows 95/98-based system.

Today, just for fun, I'm writing a PCB design program for a rather less capable 8-bit machine. There's no mouse, so it's all command-driven. If you want to move the component C2, you type M C2 and now you can move C2 around the screen and put it down somewhere. If you want to wire a connection from, say, IC1 pin 3, you type W IC1 3 and it draws a line from IC1 pin 3 to some pin connected electrically to it; and then you can use Z, X, :, / and Return (now you know exactly which retro platform I'm referring to :) ) to add vertices along the way, and cycle through possible destinations by pressing N. If you know the connection you want to wire goes from IC1 pin 3 to R7 pin 1, you can type W IC1 3 R7 1; and if you just know it goes to R7 but can't remember which pin, you can use W IC1 3 R7. (Basically the second parameter, if given, is just where it will start searching until it finds another pin connected to the same circuit node.)

Compare and contrast this with the mouse-driven method of clicking on a component lead, selecting "draw track" from the menu, selecting the destination from one of the highlit pins and then clicking each vertex along the way. It's really no easier, especially when you know that circuit because you designed it yourself (or at least prototyped it on breadboard).

If you already know exactly what you want to do, a command line can even be quicker than a GUI. (Especially with smart Tab-completion.)

[nautica]

Re: Some things are just hard

Very good!

"Few things are harder to put up with than the annoyance of a good example.‭"--‬Mark Twain‭

[rcw88]

The WIMP capabilities dumbed down the entry point into computing for those for who found word processing under CP/M just a bit beyond their capacity. After multiple decades and counting, the CLI refuses to FOAD, meanwhile, those of us who grew up with DIR and ls -al are shuffling off into the joys of retirement - no woke HR wonks telling us to wear this years flavour of rainbow pointy hat. Thankfully the geeks at the Raspberry Pi foundation hung around long enough to give newbies a replacement for the Sinclair and the BBC micro so propelling multiple generations into affordable computing power that doesn't always need a rodent. It never went away, even on Windoze, because the dumbed-down point and click brigade were incapable of automating their points and clicks as fast as ten lines of Powershell can... Revenge of the geeks methinks.

[ben kendim]

Finally, that rare someone who understands where we live on the spectrum...

Merry Christmas. Thank you for this gift:

"When you're in a full-screen CLI, especially editing, what you get above all is focus. Compared to a GUI desktop or, heaven help our grasshopper minds, an in-browser task, it is supremely quiet and uncluttered. It is you and your keyboard, and text that wants to be free of variant forms and options. If you're coding or writing text where actual content is more important than form, it is a zone for reason and thought like none other in modern computing."

[HelpfulJohn]

So, back to machine code?

If a command line interface is better, would not Assembler or bare machine code be even betterer?

If I want my machine to run a video file using VLC, I start the program by tapping an icon, hit "open file" on the menu bar and scroll about for the file.

Doing that in a command line means remembering how, remembering relative pathing and remembering all sorts of switches.

No.

Graphical user interfaces were added for a very good reason. They make life *easier*.

CLI's are cool for geek-work and problems but for 99.99999999% of Life, GUI's are far better. That's why we have them.

[nautica]

Re: So, back to machine code?

The only problem here is the conflating of the different types of computer-user interfaces.

The GUI has not always been with us. As a matter of fact, the one program which is, arguably, responsible for the PC's "taking off", was 'Visicalc' (the forerunner of Lotus 1-2-3, and originally written for the Apple IIe--but quickly ported to the IBM PC), which is said to have had the result of people buying hardware just so they could run a piece of software. Visicalc, and all programs of the era, are referred to as TUI, or "Text (-based) User Interface" programs--which are all, always, full-screen programs.

The CLI is a single-line only user interface medium whose express purpose is for the very easy inspection, maintenance, and repair of an operating system and the hardware it runs on; and certainly not for the writing of production-level programs.

Your point is very well taken: GUI programs absolutely make life easier when it comes to using fairly complex applications...but so does the single-line TUI command-line interface CLI make life easier when used in its proper context.

Different horses for different courses...

[Ben Tasker]

Re: So, back to machine code?

> If a command line interface is better, would not Assembler or bare machine code be even betterer?

You're conflating low-level with convenience (for an experienced user).

Assembler is lower-level but it's almost never going to be more convenient because its interface relies on the user keeping tracking of some extremely low-level stuff.

A CLI is often more convenient than a GUI because you can script it (to automate repetitive tasks), don't need to move your hands from the keyboard and can rely on muscle memory to a greater extent.

> Doing that in a command line means remembering how, remembering relative pathing and remembering all sorts of switches.

Not really:

vlc ~/Downloads/BigBuckBunny.mp4

Admittedly, VLC probably wasn't the best example for you to choose, because it's pretty permissive in terms of command structure - it figures a lot of stuff out by itself.

To fire up VLC in a GUI, you still need to do some of those steps

- Remember what your video player is called

- Find it in the start menu (or remember that it's on your desktop etc)

- Remember which menu to click

- Remember where the file you wanted to play was saved to and navigate there

It's certainly more *discoverable* for a new user, but you're not really remembering much less

[darkrookie28]

Software devs are outta ideas

So they are going to do everything again from the beginning.

[Anonymous Coward]

I want both!

There's no reason not to have a powerful CLI and GUI. The Xerox Alto had it all fifty years ago. Why shouldn't every GUI app have an associated CLI?

Some areas of computing have gotten a lot better, but some have actually gotten worse.

With a GUI-only system, how do you teach someone how to do someone without having universal session sharing? Pre-mouse days, you might have been able to relate a series of keystrokes that would navigate through the various menus and submenus until you reached the target action. Now, if you have a system that's identical to theirs, you might be able to make a long video that shows them all the steps. Of course, they will probably need another device so they can listen to you and watch the video and perform all the actions. If they have a smartphone, they can hold it with one hand and point it at the screen and point and type one-handed.

The real future is voice and AI. You'll say "Find all the wedding pictures of me that have a red wine stain on the front of my shirt, and remove the stain."