I'm not sure how big the subset of people that use unix systems and are ignorant of the command line is.
Most of your GUI users are on Windows, and unix shell commands mostly do not work or are aliased to other commands that don't work exactly the same way as they do in GNUland.
Oddly enough, even in the Windows world, I'm seeing more and more instructions for things like installing a software app or component, as a list of commands that you enter into the shell or the taskbar search box.
Installation instructions for Windows are horrifying -- page after page of pictures, with circles and arrows and a paragraph... And when the OS is updated, all of the dialog layouts and icons change just a bit and you're lost. Just gimme some shell commands.
Even worse is the more recent trend of Youtube videos showing you how to do something on your computer.
"OK, GUYS! We're going to start at the desktop. Now click on Start..."
Watch someone moving their mouse around for 20 minutes, making mistakes, backtracking, hovering over things so they remember what to do, then finally achieving what the tutorial was about. Ending the video with "Don't forget to like and subscribe!"
This could have been a single command line command.
> This could have been a single command line command.
... that you could have copied and pasted.
When it comes to technical support on Linux, few people seem to realize how much easier it is to provide support with a handful of shell commands. Describing how to do things in a GUI usually involves awkward descriptions, multiple screenshots, or a video demonstration. Actual support involves doing all of that in both directions (or having someone else log into your machine to do that for you). With a terminal, you're just copying and pasting text.
Is it still that bad? I haven’t used Windows since 7, I just assumed at some point in the zillion pivots since then MS would take a cue from macOS and make installing apps as easy as a click or drag-dropping a single “file”. It couldn’t possibly be a huge design or engineering feat to copy. Do people who use Windows just actually prefer installers?
Like the other poster says, it has gotten vastly more consistent, but that consistency depends on the software author or vendor keeping up to date. As you drill down into the depths of niche or technical software (aka "the good stuff"), there are more surprises in store.
> I'm not sure how big the subset of people that use unix systems and are ignorant of the command line is.
Probably way more than you'd think. Most people get thrown into the unix shell at some point without learning it properly. And its easy to accidentally miss a lot of fundamentals due to imposter syndrome + the terminal's terrible discoverability.
I made a simple build system at a company I worked at a few years ago to build production docker images. It was a little nodejs process which ran docker build in a subprocess, and streamed stdout / stderr to the browser. So you could kick off a build with a few clicks of the mouse and you could see it build + deploy. The whole thing was just a couple hundred lines of code that I whipped it up in a day or two.
Some of my coworkers were way more impressed than I expected. They're great senior web programmers, but apparently they just never learned unix properly and didn't realise how easy it is to do stuff like that.
Presumably you’re intentionally excluding phones and tablets (nearly all of which run some Unix or GNU variant), but it seems exceedingly odd to overlook macOS. While I don’t have hard numbers on Mac CLI usage/familiarity, I would assume it’s proportionally higher than Windows (lots of tech adoption especially since Macs switched to Intel) but lower than Linux (lots of consumer adoption, similar timeframe).
Most the things in this list are things that you technically don't need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you could do all those file operations in the terminal, but chances are you're already browsing files using a GUI file manager so opening a terminal to do those things is pointless. Terminal is great if you want to do something complicated that a GUI program can't handle, or you need some sort of automation (ie. programming).
Quote: "..you want to do something complicated that a GUI program can't handle..."
Name one thing that a GUI program can't handle, I dare you. Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least.
"can't handle" is super subjective. Sure a GUI can have every feature available and be super capable. But it can also lead to it taking 10+ clicks to do something, and another 10+ clicks to do it again. Super painful.
So just because companies have proven that GUI is successful and capable, it's still possible that it "can't handle" a lot of things nearly as effectively as CLI in some cases.
A GUI doesn’t disallow using hotkeys. Hell, it has superior opportunities for using both keyboard and mouse. You don’t have to imagine a dumb ok and cancel button on a window, what about blender? It extensively uses intuitive hot keys, and would be plain impossible to do anything 3D modeling related in a CLI.
You can write a GUI for anything, so if you are willing to spend enough time searching for software, you can solve anything with GUIs. But the big difference is with CLI, there is no need for third party software, the functionality is right there.
Here is a simple task which can easily occur in business: you have a folder with thousands of files named somewhat haphazardly. Copy all the files with have numbers 2011 to 2019 anywhere in the filename to an usb stick.
I think there's a golf game that could be made from these type of real world puzzles.
I would search for "2011 2012 2013 2014 2015 2016 2017 2018 2019", select everything that shows up in the search results, and copy those to the USB. Wonder what I'd do with millions of files though.
Google has been around since 1998, and after 23 years, their search is still a CLI stuck in a form.
> Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least.
No you can't. There are 5 companies with a market cap over a trillion. We can easily rule out Apple, Microsoft, Amazon and Google as they have all developed CLIs.
That leaves Saudi Aramco. Doesn't take long to see they have openings for CLI heavy jobs.[1][2]
The fact that nearly everyone misunderstood you indicates that you didn't communicate well. A trillion dollar business suggests a singular wherein a singular could be a single corporation or industry in common usage. Without surrounding context to the contrary it isn't trivial to distinguish the intentions.
Aside from that being an entire industry as opposed to a single company, are you not aware that BigCo games generally contain a developer console of some sort? Even the ones that don't provide end user access to it still usually have one buried somewhere.
Plus many of the dev tools for manipulating assets are either CLI based or have one integrated ...
The game industry uses CLIs in text adventure games, besides all their development tools. Many games put out utilities to enhance thier games, some of which have CLIs.
There are actually a couple of good GUI bulk file renamers. I'm fond of the one built into xfce's Thunar file manager [1], but there is also ReNamer [2] and Ant Renamer [3].
Because it is obvious, but apparently not to the HN crowd. Let me name it then. Game industry, it's bigger than both music and film industry and it runs exclusively on GUI. Even text based games are GUI actually, not CLI.
You said "a trillion dollar business", not "a trillion dollar industry" so of course people misunderstood you!
And even though the game industry primarily makes GUIs, it still uses CLIs everywhere in the development process, so it's pretty silly to say that it "uses only GUI and not a single CLI." And the console that's present in just about every game doesn't seem very "graphical" either.
That's their problem, not mine. Gaming is a business, Apple is a company. I heard plenty of times here on HN that Google's business is advertising. So go and argue this with the other million of post that uses this semantics.
There is a GUI with piped input, and piped output, which can be used to filter the pipeline objects using ctrl-click to multiple select "I want this, this, and that" in a view that is sortable and filterable.
Here's an easy one: take all the files in a directory, including files nested in subdirectories, pick ten random ones, and open 'em in a new Firefox window.
firefox (find . -type f | shuf -n10)
I doubt your computer comes with a GUI program that can do that for you. My point is that CLIs can easily be plugged into each other whichever way you want, but GUIs (except in some niches like audio) aren't built that way for some reason.
I think you miss the point of API's regardless of your programming language. If it's used inside a CLI then definitely I can write a GUI program that does the same.
You could write such a program, but my point is that it's a horrible inconvenience. CLI programs compose to the moon, but it's hard to get GUI programs to compose at all.
Alternatively, writing a program just is what you do at the shell with the find command, without building a GUI AND all the ceremony around getting a typical programming language needs to orchestrate processes.
I do most file operations in a terminal because I can switch between my editor and the terminal without picking up the mouse. I do use a file manager to organize media files.
Very true https://i3wm.org/. I3 is a great WM that allows you to avoid having to use the mouse.
That said I now work in the Windows world. I find that if you are using the same tools day in day out then the keyboard is the way to go. If you have to use new tools every other week the GUI is hands down much better. Unfortunately in my role I'm doing exactly that.
Different people will draw the line in different places. Take your example of file management: since I'm usually in a terminal, it takes far less effort to enter a command than it does to open up a graphical file manager and navigate to the desired directories.
The other issue is that few file managers are as powerful as command line utilities. There are exceptions. I am quite fond of Directory Opus while using Windows since it feels like a program designed by people who understand the scope of file management. Alas, it is an exception rather than the rule. Most file managers facilitate basic functions then stop there. With the shell, that's not really an issue since you can always add another utility to your tool box.
The list can go on. The GUI may be better when you have to manually pick through a small number of files, but calling up a file manager to handle a single file or a bulk operation rarely makes sense (if you're already in a shell).
There's more than just effort to consider. Discoverability, confidence, error recovery, and consistency come to mind.
You might be in a terminal, in the directory you're you want to copy a file within... $open ., type file name, command-C, command-C, command-W would do a great job, require minimal additional effort, but provide better visibility into the status of the copy, allow you to better handle file name collisions, allow you to retry, and be undoable.
If you didn't know the correct program or arguments for zip, you could simply look around the menus and find 'compress'.
Even scripting, you can use the best tool for the job. AppleScript or similar can be used to script GUIs and also for testing.
For 90% of this stuff “discoverability” isn’t a problem anymore, I’ve already crossed the learning curve of the command line and I just think in terms of the available command line programs. For the next 5%, I tend to pipe a command like find or ls to a file and then use vim to quickly make a shell script that does what I need.
I don’t know if it’s more efficient, objectively, but this just is the workflow that matches how I think.
I've been using the terminal (admittedly not as my main interface) for 20 years and I still have to consult man pages, documentation, and google about 10 times a day. I'd say discoverability is certainly still a large problem with CLI.
Apple had an interesting take on discoverability with AU/X and MPW: you could pull up a dialog box with the available options and descriptions. Unlike man pages, you could select the desired options from the dialog box and execute the resulting command. It's not the sort of thing you would want to use often, but it was great for learning how to do things or to refresh one's memory.
In zsh, I think Ctrl-/ pops up the manpage and then restores the command line when you quit (this may be just my config). It’s not as nice, but zsh’s line editor does implement everything you need to extend it with this sort of workflow
Even if you move your hands (gasp) off the keyboard to the trackpad or the mouse that is presumably very close by, typing that command is probably not faster and more convenient than double-clicking.
Yes. I am a huge CLI nerd, yet, I cannot be dishonest with myself - GUI is faster in a lot of things.
When copying files from one directory to the other - CLI vs GUI is debatable in terms of speed (I'd still say GUI is faster, but let's assume its debatable). But what if I want 1, 2, 5, 7 and 10th file; not all files? It is remarkably faster in GUI: Ctrl + click files I need and drag+drop. Done. Good luck fumbling around with CLI.
CLI nerds are the most annoying people I've encountered. They're myopically obsessed with their tmux + cli workspace and are not open minded.
I like cli for navigating directories, and finding and moving files. Using a graphical file manager feels clunky to me. I do use a gui for other things, like I finally switched from vim to vscode, but file management has always felt more natural in the cli.
The real problem is navigating to the file... I can tab complete or otherwise hop my way around my hard drive much faster than I can visually find a target to click on (and frankly I am shocked that isn't true of everyone who knows how to use a terminal--obviously I appreciate the "easy for beginners" aspect--I feel like the GUI could only possibly be faster for a contrived use case that would never come up in reality... oh, I have one: if the files you are organizing are all images and they have useful previews! I totally use the GUI file manager to organize photo albums... but of course I am barely using the mouse as I do so ;P).
GUI does not imply mouse-only interaction. Any good file manager will let you browse using the keyboard, with typeahead for file selection and accelerators for the context menu.
I can type over 120WPM --- that's less than 100ms per key.
I would've been able to type open and tab-complete the filename in the time it takes to move my hand over to the mouse, move the mouse to the right file, and double-click. The mouse is close, but not as close as the keys under my fingertips.
I use Qutebrowser which works well and is configurable, though there's no extensions which can be a bit of a bummer, but there's a built in adblocker which works pretty well at least.
I have that shortened to o instead of xdg-open and jump to recent directory with zoxide an autojump alternative invoked with z followed by a few characters
So z [4 chars] enter o [2 chars] tab to complete enter is actually pretty quick.
The "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'" is a bad joke. Heck, it's better to just tell them to `brew install mc` and use `mc` afterwards (or `exa` or whatever else). I usually just type `open .` and do the rest in Finder, although this admittedly breaks the command line workflow.
No matter how fast you can type, typing this clusterf*ck of a command isn't faster than using a better utility (command line or GUI). And I assume complete beginners (which the page seems to be for) don't know how to set up shell aliases just yet.
It often times is faster, or roughly the same speed. What's your point?
Say I want to edit .psqlrc
Doing it in GUI is like 10x slower. First dot files are usually hidden by GUI, so I have to search through menus on how to enable their display. Then I have to look for the damn file. Where it is among 200 similar dotfiles? 5s later I find it. Now right click, pick an corect editor from a submenu of a context menu. Edit. Save. Now go back to file browser and disable dotfiles display, otherwise all my regular files get drowned in noise, slowing the normal usage. It's retarded.
Alternative. Open terminal. Type vim .psqlrc. Edit save. Close terminal. 3s top for the non-editing parts of the workflow.
Just about everything in that list I do from a terminal. But I practically live in the thing. I’ve literally had trouble finding my home directory in the Mac Finder UI. Never had that issue in the terminal ~
I just use Cmd+Shift+G (go to directory) to get around anywhere in Finder. It's worked out well so far, and I can still use ~ to go to my home directory.
It's in the "Go" menu, along with the keyboard shortcut. You can also put it in the sidebar, either via Preferences->Sidebar or dragging your home folder there.
I'm guessing that the reason it's not there is that for most casual/GUI users, Documents/Downloads/Desktop (which are all in the sidebar) takes the role of /home in traditional Unix.
> chances are you're already browsing files using a GUI file manager
I haven't had a GUI file manager installed on any of my desktop computers since the early 2000s, and the last time I used one regularly was the mid 1990s.
Hacker News in 2021: Where the "hackers" think that "doing it in command line is pointless."
Dolphin file manager has a terminal built-in; the GUI follows the current directory in the shell, and vice versa. Best of both worlds! Never type 'ls' again.
I’d argue that if you’re using an ncurses based UI, you no longer have a command line interface, and you’re not scriptable anymore. Which is fine of course, but what you really have at that point is a rather ugly and limited GUI...
I agree. Although for most tasks I tend to prefer having a command line interface, just because of things like programmability and my typing speed, I'd be lying to go as far as to say the CLI is _always_ the best way to do something. For example, I like to construct git commits using a GUI, since I'm faster at selecting lines to commit than I am sifting through potentially hundreds of changes looking for the right one to add to a particular commit.
Additionally, I think some of the listed tasks are objectively better in the GUI, despite being possibly slower. For example, in the command line, deleting a file doesn't send it to the "Recycle Bin" or your OS's equivalent, it simply deletes it. This is better for things like scripts, but worse for someone using it as a GUI replacement, since now there's a risk that they could permanently delete an important file due to misspelling or something of the sort. I find it hard to remember sometimes that Emacs is a GUI too, and it can often be the best way to do any given task.
Something like Vim still benefits from the composability of the command line interface. I can write and read buffers to/from other processes, asynchronously run commands and pipe the output into Vim, and of course I can always put Vim in the background at any time which immediately drops me into my shell, where I have complete and full access to the entirety of the machine.
These are the main reasons I stick with terminal based editors over something like VS Code with Vim bindings. Using a separate GUI breaks that deep integration with the shell, which for me just creates too much friction for not enough benefit.
Midnight commander, for example, has the command line in it, so you don't lose it. But even without the command line embedded, I'm sure I could do common file operations much faster in it than 90% of command line lovers.
Good curses based GUIs can be quite efficient. Usually won't beat the command line, but can get close, and are much easier to learn.
GUIs support the concept of undo. It would be great if all shells indicated the command to undo what you just did, and you could turn off that warning message with an environment variable.
And, almost none of these work in the Windows command prompt. I've tried powershell and while there are some great ideas, nothing behaves as I would expect after using bash for 20+ years.
These are the reasons people use the GUI. Without acknowledgement of that, this readme loses some of it's lustre.
Undoing isn’t a feature of a GUI though, but rather running in a context that maintains history/state. There’s no reason a command line program couldn’t do something like this in theory.
Yep, Vim is the first thing to come to mind. I'm not sure there's any program with better undo-ability.
I also am not quite sure what the post above means by "GUIs support undo". Yes, most apps,e g., on Windows, support CTRL-Z for undo. But this functionality depends on each app implementing its own undo, nothing OS-wide, and results will vary. I'm not sure what there is in GUIs that supports "undo" other than an app/user convention like CTRL-Z, which hardly seems to rise to the level of "supports undo".
Windows Explorer, macOS Finder, KDE Dolphin, and GNOME Nautilus all beg to differ.
The issue is that tasks on the CLI tend to be split between many different utilities. So you'd either need a standardized method for sharing an undo tree between the different utilities, or alternatively to integrate all the different tasks under a single program.
Yeah there are definitely a lot of edge cases when it comes to filesystem operations. It works for the simple stuff though (ex accidentally grabbing the wrong file or dropping it in the wrong folder).
I mostly just use Ranger in a VTE to be honest. Cut/Copy/Paste and directional navigation of a tree using standard Vim keybindings is just more fluid than anything with a mouse could ever hope to achieve. Add to that dropping to the shell with `S` with my hands already on the keyboard and it's by far the best workflow I've come across.
Ranger is great; I do wish it had the ability to have windows rather than just tabs; it would be easy enough to setup an orthodox style view if that were the case.
To late to edit my other reply, but the fact that I use 3/4 of those regularly and didn't know they had that feature is possibly a point against "discoverability" being something GUIs naturally have.
There are plenty of commands that essentially cannot be undone. Let's consider
`curl --upload-file ~/.ssh/id_rsa https://dontworry.youllundothat.tk`
for example.
Even when it's doable, some of us prefer to risk unrecoverable mistakes if it avoids having to take an extra step for the command we launched to be effective. I don't want to "empty a bin" after a `rm`, I want free disk space, and yeah, it could be almost impossible to undo.
I understand that safeguards around destructive actions or actions cancellation can help UX, however at some point you can't make an omelet without breaking eggs.
GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks)
TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder.
If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful).
In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
It's interesting that there is some analogy to object-oriented and functional paradigms -- if I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it. Might be a too far fetched analogy though.
I think we need all of it, and also need to make the distinction less apparent. Would be nice to make GUIs more composable, and TUIs more discoverable. Ideally it should be a spectrum of interfaces, so you don't have to make a hard choice and can gradually move into the direction you want.
just once to (re)build the index. Results are guaranteed to be of high quality only on a real UNIX, preferrably one of open source Solaris (illumos) distributions, and likely FreeBSD.
'help' is already the shell's built-in help function in most cases. That'd be a poor choice of alias.
There are a small number of seed keywords which are ueeful to know. 'help' (shell), 'apropos', 'man' (online manual), 'info' (GNU documentation), and dwww (local documentation presented through a Web interface, available on Debian-based Linux, see https://ostechnix.com/dwww-view-complete-debian-documentatio...) are among them.
Knowledge requires a certain baseline.
If that's too much ... perhaps a GUI is in fact advisable.
A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discoverability you mention found in the GUI based system. It was just easier to use. This didn't come for free however. At a different client making the same transition from TUI based system to GUI based system (same target software), we measured the productivity of well trained staff and the TUI was well ahead in daily productivity. Now the different companies had different employment profiles; they were both retail businesses, but the first one that measured training was more decentralized and saw higher staff turnover rates and so cared more about training efficiency; the other had more centralized operations and so had fewer, more senior staff members with longer tenures where daily performance was a more important metric for efficiency.
Now a TUI isn't the same as command line and most GUIs allow for substantial keyboard functionality, but I think developing for a TUI tends to get you thinking about a person working a keyboard whereas developing a GUI you're thinking more about the person with a mouse/trackball/trackpad/touchscreen.
Personally, I do a lot of database work; mostly PostgreSQL. I decided some years ago to bite the bullet and get rid of the GUI and just use straight psql. I largely haven't looked back, though if I'm doing heavy development work I just started using DataGrip since it helps avoid stupid errors that a simpler text editor doesn't find.
I have, but it's been awhile since I looked. My recollection was that it felt sluggish, but that might be a false memory. I think what it brings to the table is helpful, but not enough for me to warrant it's use. When I'm writing simpler queries at the command line, I'm usually well within my knowledge of the databases I'm writing for or would have to appeal to something like the table definition anyway... which as I recall I couldn't really do in pgcli (start writing, flip to the table definition, pick up where I left off).
When the sorts of things that pgcli does becomes most helpful is when I'm writing functions and procedures, but then the command line isn't well suited for that. That's where I'm finding something like DataGrip helpful: a database tool focused on development rather than administration. DataGrip has a lot of faults, but for the past couple of weeks I've been using it, it's been on balance a win.
You can use the .psqlrc for this purpose, though I suppose you could also real that in via a file on demand, too. You make entries something like:
\set show_slow_queries
'SELECT
(total_time / 1000 / 60) as total_minutes,
(total_time/calls) as average_time, query
FROM pg_stat_statements
ORDER BY 1 DESC
LIMIT 100;'
and then later at the command prompt you access it as; ":show_slow_queries".
I have a few system queries like this in my .psqlrc file, but I don't do much which this feature often truth be told. I have a pretty strong knowledge of the database schema I work with, I do a lot of work on systems I don't regularly control so its not dependably available, and readline history suffices for more immediate needs.
What about a system that shows actions in a GUI as a list of equivalent plain text commands. New users would have the discoverability of a GUI while being able to see what goes on command-wise. With time they would be able to convert to plain-text commands and scripting for increased efficency.
Maybe one day everyone will adopt PowerShell as the CLI standard.
PS scripts (and even functions) declare command line arguments up front, and depending on how much time and thought you put into it, you can constrain the arguments quite well. See [0] for overview of the available functionality. A quick TL;DR:
- You can make parameters typed, and PS will handle relevant conversion if the user just types strings in. E.g. you can mark a parameter as [DateTime], and if the user types e.g. "2021-04-01", the script will receive an object that represents the midnight on that day. If the user types in "foobar" instead, they'll get an immediate error[1] telling them the parameter cannot be read as a date.
- Add [] to parameter type (e.g. [DateTime[]] instead of [DateTime]), and now the parameter can accept multiple values (arrays), - but behaves smartly if only one is given.
- You can mark parameters as mandatory. You can mark parameters as positional (i.e. provided without specifying parameter name on invocation). You can mark a parameter as designated "catch-all". You can define aliases for parameters, to allow user to write e.g. -Runs, -Run or -R, and have all three refer to the same parameter.
- You can mark parameters as "accepting values from pipeline" (and define how exactly). Since PS pipes transport typed objects, not raw bytes, this is how you can both set expectations, and write scripts that can flexibly mix pipes with commandline arguments.
- You can define validation for every parameter individually.
- You can group parameters into sets, based on what other parameters are provided, or some custom logic. So e.g. if arguments -A and -B only make sense together, and then -C doesn't do anything, you can encode this cleanly.
- Autocomplete in PowerShell is aware of all these things! It'll hint you appropriately. And you can provide your own autocomplete hints too.
How is all that relevant to this thread? The last point is a spoiler: all these declarations can be extracted from the script, and they provide enough information to build a high quality GUI for the script automatically. PowerShell ISE, that comes with Windows, exploits this to a limited degree - it contains a GUI for running PS cmdlets that lists parameters and their types, makes use of optional/mandatory status, and groups them by parameter sets. There's nothing stopping one from building an equivalent UI generator that would also provide custom widgets based on argument types (e.g. file pickers for paths, calendars for DateTimes, etc.).
[1] - Errors in PowerShell are a bit user-unfriendly. Niceties like invocation with underlined mistake are surrounded by long error text and small stack trace. I wish they improved on that; even for script developers, most of the error message is quite useless.
I like powershell, but I find its Syntax very hard to learn for casual usage.
-eq is just cruel if you are used to proper programming languages.
I'd love to see a sane script language ala typescript established as general purpose shell/shell scripting language!
TypeScript is not yet expressive enough for direct shell usage, but not much is missing imo (most importantantly a pipe operator).
Agreed. Having recently written a bunch of PowerShell scripts that were too big for their own good[0], I'm pretty much in love with it, but the language itself does bug me constantly. Operators are one of the big annoyances. -eq, -gt, -icontains, -match...
But I get it. It's the consequence of trying to use the same language for code and command line input. > and < are already used in pretty much every single shell to indicate IO redirection; particularly with >, it would be really dangerous for it to have context-dependent meanings. And then foo -match bar is more CLI-input-friendly than foo.match(bar) or match(foo, bar). You can get a similar experience if you try to use (or design) a Lisp shell. S-expressions are awesome, but having to move the caret back and forth to add/modify structure in your command is too annoying for a shell language. For shells, you essentially want as much appending and as little editing as possible.
And as much as I don't like JavaScript ecosystem, I would like something like TypeScript in the shell. Personally, my main requirements are 1) optionally typed, and 2) piping structured data instead of unstructured text/byte streams.
(And then I'd like a terminal emulator that makes full use of type system in pipes and command arguments.)
--
[0] - They started simple, then they grew, and before I noticed, they've crossed the threshold where, if I were to write them again, I'd use a regular programming language. I think the point in which I started including bits of C# code in the scripts should've been a wakeup call... but on the other hand, isn't it just cool you can drop down to C# in the middle of a script and have it Just Work?
Good to know, thanks! I've been mostly developing on the Windows PowerShell, but I'm about to move to PowerShell/.NET Core, so I'm happy to know error messaging improves there.
AutoCAD sort of does that - actions can be launched both via the GUI and the command line, and all actions launched via the GUI also appear in the command line history, so you can pick up the names of the commands over time as you're using them (alternatively, they're also mentioned in the mouseover tooltip in the GUI).
An interesting UI paradigm I've run across [0] is using a keyboard-accessible hierarchical menu for all actions. It's similar to how AutoCAD works, but the "commands" you type are actually just sequences of menu hints. Most desktop apps support these hints with Alt, so the capability is there, but there is something about using the hint sequences as primary keyboard shortcuts that appeals to me.
The nice thing is that by using the keyboard to navigate menus, you develop muscle memory for "shortcuts" without really trying. And if you ever get "stuck", not knowing how to complete the sequence, you only have to look at the currently open menu.
Formica doesn't do this, but this could be extended into rudimentary scripting.
This kind of paradigm won't fit all software, for example I don't think it's a good fit for software where typing mildly structured text is the main mode of interaction. It might be mainly useful for shortcut-heavy software.
I've actually contemplated this very idea and think it has merit. What I've found in many applications is that there is a stark distinction between GUI and TUI/CLI that isn't completely necessary... I speculate that there's more room for grey between the two. To be clear many GUIs can be used via keyboard alone, but often times that ability feels bolted on in that you only get things like shortcuts for a button presses whereas many text oriented interfaces offer more actions which are composites or which might not make sense in a visual presentation of the functionality.
Having said that, I think that the inertia of "good enough" is a real danger to the concept. The new user that uses the less efficient GUI aspects of the interface to learn quickly may not have much incentive to go the next step and work the keyboard oriented workflow into their muscle memory. Also, if you realize that issue, there's also the problem that if the keyboard interface were less used, there would be less incentive to fix issues or add features to it as the application changed. Rightfully, it could become less useful because of less attention. I can tell you that in practice I find it fairly uncommon to see staff using the keyboard capabilities insofar as it's already supported by their GUI applications.
FoxPro worked like that. The language itself had commands for various IDE actions, like editing a source file (MODIFY PROGRAM ...) - these worked everywhere, but were really meant to be used in the Command window, basically a REPL. And then if you use the GUI to do the same thing - e.g. File -> Open - it would simply execute the corresponding command in the Command window.
This worked surprisingly well. New users mostly stuck to the menus to discover things, but then gradually switched over to commands for common actions, because they were faster. It also helped that the Command window had context-sensitive help, so once your menu action generated the corresponding command, you could easily open the manual page for it to read up on the details.
All GUI apps should be controllable entirely through the keyboard.
This is generally true of built in Windows applications (even if the transition to ribbon interfaces complicated flows). It is spotty for third party applications.
Unfortunately on Linux, at least on KDE (I don't like Gnome since v3), keyboard navigation is broken even on default applications like Dolphin or Discover.
Mac OS, I remember (Tiger -Lion) being pretty good.
Out of curiosity, what's the practical difference between TUI and GUI when it comes to discoverability? The kinds of TUI I'm familiar with - mostly from DOS, so stuff like e.g. Borland IDEs (and various third party apps written using Turbo Vision), FoxPro, and VB for DOS - are essentially the same as GUI in that regard; you get a drop-down menu on top, windows with various widgets, often a help bar at the bottom and/or context-sensitive help with F1 etc.
> I can right-click to see everything that can be done with the file, including some third party programs
Smart move by (for instance) Microsoft when they did that in Windows 95 and continued it til now. You could theoretically design the same functionality into a text user interface. Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) it could give you a menu to choose from context specific commands. It would seem pretty natural in that case if you are using post-fix (arguments(s) and then commands, like in Forth). Maybe something already exists like that.
In bash I can type, for example, "git <tab><tab>" and it will list out all of the git commands. Not quite as nice as a menu, I suppose, but still helpful for discoverability.
> Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with)
How about:
$ file --help | grep util
-u, --utils output utilities related to FILE
$ file -u index.html
index.html: HTML document, ASCII text, with very long lines
cat index.html
ed index.html
lynx index.html
That sounds like a GUI; how do I pipe [open, copy, rename, etc] into sed or awk? (Because the^Wa problem with GUIs is that the answer tends to be "Why would you want to do a wierd thing like that?".)
I can try... Specifically, given a command that produces a list of "everything that can be done with the file", how do I cause the (unstructured) text of that list to be piped into a arbitrary other program, in the same way that `grep foo a.txt | bar` causes a list of occurences of 'foo' in a.txt to be piped into arbitrary program bar.
Ah, thanks for the clarification, it definitely cleared up what you mean.
As I understood the suggestion re. file actions it is meant as some sort of interactive completion. So if I type the name of an image file and press tap, I am given the suggestions or options about resizing, format conversion etc. Several shells already have interactive completion of file names.
And I think that pattern makes sense from an exploration perspective. If you learn that file name + tab gives suggestions, then a lot of the learning about what the command line can do can be done directly in the command line.
And maybe it could be a command rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
I really don’t see how this is incompatible with existing workflows :-)
Update. I tried the `file -u` example you gave above and the `-u` flag doesn't exist in my version of `file`. I also find it a bit hilarious that the example lists `ed` as the editor of choice.
> the `-u` flag doesn't exist in [any] version of `file`
Yeah, I was giving a example of a sensible way to design it, not documenting something that already exists; sorry if that wasn't clear.
> And maybe it could be a command [like `file -u FILE`] rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
Pretty much that, yes.
> I also find it a bit hilarious that the example lists `ed` as the editor of choice.
I don't think unix had TECO as a standard utility, so I went with what was available.
This reminds me of my first experience with (DEC) Unix at JHU. I had been a VMS user, so when I logged into the unfamiliar system I typed in "help." The JHU site admin had helpfully set the output of the help command to be, paraphrasing, "I see you know nothing about Unix, please talk to the staff member." He told me, "oh, in Unix help is spelled man." Obvious!
$help
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
These shell commands are defined internally. Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.
GUIs are great, but not having a CLI is an anti-pattern. Also, having an API, but no reference CLI is an anti-pattern (depends on your API, but if your examples are poorly constructed bash scripts with cURL lines you need a proper CLI).
One thing that I hate to admit is great at this, is JIRA. It is definitely a UI centric product! But when I want to compose it with something, the REST API is right there. In fact, when a mostly-background system needs a human in the loop, sometimes we can grab JIRA to be our UI.
I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag.
Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications? I see no technical reason for the lack of it. Look at something like htop -- it has a sort of "command line version of a macOS menu bar" with each menu selected by a function key. I could easily seeing this idea being extended to, say, being called by the familiar --help flag, or each menu visualizing a sub-menu upon pressing a function key, etc...there's no reason CLIs can't have the same discoverability as GUIs.
There are shells that help with discovery. And auto completion helpers. These are great. You might infer from documentation. There was a big thing about spacial awareness years back, my brain works well like that, familiar brain paths for controls in certain places. But that relies on repetition. I pretty much always forget shell incantations. So any helper tools are a boon for me. Self described to GUI or richer UI would be welcome. If it's not already done.
File explorer multi pick is the thing I desperately claw for for a pointer.
I don't think there is a club to be in, but if you want to feel in the club about such things, just say something like "I expect that there is an option for like '-w whatever_madeupoption' that is useful here, but I'd have to take a look at the man page or use '--help' to know for sure". Be prepared to respond to "how would that work?" with APIs/syscalls/etc that you might use to implement that or say something like "I'm not sure, it sounds like an interesting problem if I had time to solve it"
The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not all, Windows GUI conventions and keyboard shortcuts come from CUA, and this is its lasting legacy.
That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands.
Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities.
And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified.
This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX.
Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).
You touch upon the problem.
The space is actually bidimensional instead of unidimensional.
On one axis we have graphical (raster mode) at one end and text at the other.
On the other we have as you calld them action-oriented (WIMP) and line-oriented (I would call it command-oriented).
There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like *Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.
And there are graphical command-oriented apps like Jupyter or ReGIS or Sixel or iTerm or TermKit or Kui or the command palette in VSCode or Atom or others.
And you can have them mixed like in youtube-dl GUI or ffmpeg GUI where the changes you make in the GUI are reflected in different arguments for the command and you can see and edit the command before executing it. This is similar to getting keyboard shortcut suggestions in menus or tooltips.
We need more innovation in this space. Ways to achieve both discoverability and scriptability. We need more hybrids and less systems that stay in their lane.
Graphical text editors with command pallettes, PowerShell with its object oriented piping, Jupyter are moves in this direction.
This is a power user direction. And it is opposed both to the minimalist touch friendly trend and to the terminal-first mindset.
> There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.*
These are graphical programs, just with a substandard drawing api.
Actually even this two axis classification is imprecise.
CLI programs like the coreutils are actually sort of missing a user interface. They are just programs that receive arguments on launch.
How should we classify the following?
- Programs like coreutils that receive arguments and return a result
- Programs that start a menu or wizard in text mode
- Programs that start a interactive command line like various database CLI interfaces, shells
- Programs like Vim that have a TUI and are command line driven.
- Programs like Tilda that have a WIMP TUI
I think the last four have graphical equivalents (eg. Windows installers, Jupyter, VSCode, Notepad++ respectively) and what is missing is a graphical interface for passing arguments to programs.
I understand your point and your definition of GUI is much more inclusive. I however disagree with your definition and I consider it is not that commonly accepted.
I do agree with your definition of a command line interface as a stream of commands and responses.
I just keep cheatsheets handy. For new scenarios, if I find they aren't already on the sheet, I add them. The best command line tools have good documentation you can find with a command like "help" or the "-h" flag. I am slightly annoyed there isn't a convention for this though. Perhaps it should be made into a RFC standard.
Cheat sheets are not form of discoverability. People generally want to use software and learn-while-using. By searching beforehand for a cheatsheet or reading a man page you are already studying how to use the software before actually using the software.
Compare that to most GUI apps where you can just open and use and learn as you go.
I just want to achieve an outcome. An argument could also be made that GUIs are a pita because you have to spend too much time discovering when you could just read the manual and do the task.
> Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications?
On IBM i (originally known as OS/400), you can press a function key and automatically get a fill-in-form for any command.
This is because command line syntax is defined, not in your program's code (getopt calls etc), but using declarations in what you might consider to be a separate command definition file (technically called a "*CMD object"). The OS does command line parsing and validation, marshals the result into a memory block, and passes that to your program rather than the raw command line. And the OS uses the same command syntax declarations to generate the (text mode) fill-in form for display.
Other systems which use the idea of command line syntax declarations, with the shell doing option parsing based on those declarations instead of each program doing them itself, include OpenVMS DCL and PowerShell. (PowerShell actually copied this idea from OpenVMS DCL and IBM OS/400.)
I think the big reason why this is less common in Unix-like systems, is the design decision to give each command responsibility for parsing arguments/options, rather than doing it in the shell. This makes the whole approach of automatically generating fill-in forms at the worst impossible, at the best unreliable. You can try parsing --help output or man pages, but that method isn't always going to work, centralising option parsing in the shell does. It is likely rather too late for Unix-like systems to change their approach.
Macintosh Programmers Workshop and I believe AU/X had this sort of functionality (different implementation, though) back in the 80s/early 90s. It was nice. :)
More to your point. I think TUI/CLI apps would be much more usable if help files where written for Beginner, Intermediate and Advanced (or similar). With the flat format we have now man pages and --help are overwhelming when something is brand new to you.
GUIs have a nice ramp-up and a fixed ceiling, whereas command lines require you to climb a brick wall (the part where you learn enough commands to make it worthwhile, pretty much by rote) but, as long as they're scriptable, the ceiling is close to unlimited.
(TUIs are, or can be, GUIs with box drawing characters instead of pixel displays. They're not necessarily any more scriptable or any less discoverable; however, a TUI on top of a command line, like Norton Commander or Midnight Commander, can be a real winner of a design paradigm.)
By nearly the same token, though, one could say that Windows NT, which is for most practical purposes a descendant of VMS, implemented these ideas... and UNIX lost out to it.
I think that some version of this dichotomy has existed at nearly every point of computer history where technology allowed it, and that is surprisingly far back!
How did UNIX lose out to NT, when market forces coerced Microsoft to include a shoddy copycat version of UNIX named GNU/Linux inside of NT? That is almost the ultimate punishment for Dave "Gettabyte" Cutler, the father of NT and a notorious UNIX hater.
> If I don't remember the `df` command... what do I do apart from searching on the internet?
I'd try "ls /bin" and see if any of the names sounded familiar or possibly relevant. Or "man -k space" which shows "df (1) - report file system disk space usage" on line 24, which isn't a lot of reading.
GUI's aren't always intuitive. Nothing worse than not having the option in your right-click menu because you tried right-clicking in the left "explorer" column, but really needed to open the parent dir then right-click on the folder in the right-hand side. GUIs can be infinitely more difficult/complex.
Back in the Win95 days, I recall a case where someone couldn't figure out how to format a floppy. After struggling for hours, he did a search which found format.exe, and used it. It's hard to discover that you can right-click on the drive to get the option, because there are many things that don't show up there... You can't create partitions or change drive letters in the right-click menu there, for example, but how would you know? You've got to learn the options/capabilities for your system, whether its GUI or CLI.
What a GUI really has going for it, is that it offers a limited set of options, greatly simplifying the exploration. Something like Norton Commander, DOSBox or other limited/restricted shell (which shows only the most common commands) has similar discoverability benefits without the graphics, and still with those cli benefits available to you.
> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs).
No. One has to be trained to right-click. What about interfaces that don't have a right-click, such as a touch interface?
Not only that, but the right-click menu has to be programmed. A lot of designers want minimalistic interfaces and would remove anything that isn't used often. So your right-click menu won't have those features.
> TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder.
Are you kidding?! I've found that doing one-off things is massively easier and faster in a TUI than in a GUI!
> In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
I've found plenty of GUIs that simply don't have what I want. Or... maybe they do have what I want but I couldn't find it.
> Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution?
My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a completely different interface so nothing is ever consistent even on the "same" operating system.
> For example?
Example 1: download one file from a url mentioned somewhere
curl -fLsS "$(query for url)" -o ~/Downloads/file
Example 2: download a bunch of PDF files
cat ./file | grep -P '\.pdf$' | while read -r url; do curl -fLsS "${url}" -o ~/Downloads/"$(basename "${url}")"; done
sort <(grep -lRIiw "magic" /path/with/content | while read -r path; do basename "${path}" .txt; done) <(pdfgrep -l "magic" /path/to/pdfs | while read -r path; do basename "${path}" .pdf; done) | uniq
And now, I have accepted a file from a team member which describes URLs to PDF reports with magic. I have generated a one-off report describing which files have magic content that needs to be reviewed because it contains magic that's described in in a local database.
How about generating a git-diff, encrypting it, and emailing it?
cat <(echo Subject: diff for the work you needed) <(gpg -a -u inetknght -r recipient -o - -e <(git diff new..old)) | sendmail recipient
... Okay so those one-off things are complex things. How about simple things?
Example 6: move a file.
mv ~/Downloads/foo ~/Documents/
Example 7: open a file
xdg-open file
Example 8: delete a file
rm file
Example 9: mount a thumb drive
mount /dev/device /mnt/filesystem
Example 10: unmount a thumb drive
umount /mnt/filesystem
Example 11: shutdown, and don't let any bad app stop the shutdown
> My solution is that touch interfaces are a bad design in the first place.
Don't get me wrong, I also hate touch interfaces, for all the reasons you mentioned. But saying they're "bad design" is not a solution – it's a starting point at best.
What alternative are you suggesting for smartphone-sized devices? Mobile phones did have physical buttons, but once touchscreen-only devices came out, customers voted with their money. So much so, in fact, that smartphones with a physical keyboard are a tiny niche today. That's because keyboards just don't work well with small devices. Using a CLI with a smartphone keyboard would be an awful experience.
It certainly is easier for you or me, but not for an average person. Let's look at the command names. find, sort, and even mount are ok. curl? Does it have anything to do with curling? cat? What do cats have to do with files? Oh, it's because I'm using a mouse, isn't it. mv? Why not move? Or going back to previous examples, why not fnd or srt? Consistency is important and you don't want users to guess. grep, xdg-open, and systemctl are just random letters for most.
And that's just those who can speak English. If someone doesn't, it's just nonsense for them.
> One has to be trained to right-click.
One has to be trained to understand which commands exist and what do they do. I can't imagine someone without any training typing `grep -nRIiw`. Sure, you can look it up in the manual, but that's the thing - you shouldn't. You should consult the manual when you're using something for the first time or something isn't working. I can pick up any vacuum cleaner or get in a rental car and start operating them right away. I have to look up how flag works with different CLI apps. I shouldn't have to. Good design should be obvious.
That's why we're not typing `systemctl poweroff --force` to turn off a TV, we just press a button on a remote. And I can pick up remotes from other TV sets and turn them off without looking up their manuals.
> nothing is ever consistent even on the "same" operating system.
Funny you mention that. I tried some of your commands. Turns out, I don't have systemctl or pdfgrep installed. So much for consistency.
What if there was such a thing as a right click menu for command line programs?
Like if I type ffmpeg or youtube-dl with no args, it lists the 3 most common ways to use it, and maybe allows an interactive CLI menu where you can build up the correct argument list by answering a few questions.
I would love the most useful commands to look like:
ffmpeg --resizeVideoTo input.mp4 50% (0.5 also works of course)
youtube-dl --do-the-thing-you-know-i-want-to-do <YOUTUBE_URL>
cd --show-a-menu-of-the-last-10-paths-i-changed-to
git --i-fd-up-my-last-commit-please-help
Most realistically, I'd want the invocation without arguments to show an interactive menu of the top 3 uses, so I could just select what I want to do.
Or if I provide a partial argument list, it should ask me to supply the rest of the args. Or maybe it should guess and do the right thing.
For example:
ffmpeg input.mp4
>> What would you like to do with input.mp4? 1) resize 2) rotate 3) crop 4) change video format
youtube-dl URL
>> Download the best video for URL to the current path? Press Enter to confirm.
cd
>> Here are the last 5 paths you switched to. Choose 1...5.
find
>> Start typing a partial file name and we will show the top 10 matches from this path and its subdirectories. CTRL-<period> to turn on regular expression search.
When I enabled tab completion for git and google cloud CLI, my life became much better.
However, I still think there needs to be a "right click menu" for command line programs. Someone needs to determine the 3 most common uses and make it so that --help lets me choose one of them by pressing 1, 2, or 3.
Right now, --help usually gives me something that is difficult for me to understand, especially if I have never used that command before.
Tab completion works great if I have used the command before and want to save time.
Tab-completion could additionally list the "most common things given the context* I have".
Tab-completion needs not nessecarily be postfix. I've seen completion tooling** that would work somewhat like `invoice.pdf<tab> -> `open invoice.pdf\n cp invoice.pdf` etc.
And if `<tab>` conflicts, or breaks your mind because it must only work on postfix, it could be anything really, such as `<cmd>-r`.
Additionally, or underlying, a reasonable simple command like `whatcan` or `ctxt` (context) could work and be leveraged: `whatcan invoice.pdf` -> a list of common commands given the context* I have.
---
* Context I have would be your ~.\_history, the current directory-tree, permissions (why show `mv` if you don't have write access?), applications available, etc. pluggable maybe?
** e.g. the <ctrl>-r, interactive bash history search come to mind as pattern. But also tools like FZF https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an... that don't nessecarily only "complete" on tab, but may replace larger parts of the commandline.*
There is something like Gooey [1] that you can put to your own applications. I think it is technically possible to use Gooey to wrap existing applications, but not sure about the automation.
While not entirely matching your vision for this, TLDR [1] does provide for a similar functionality (discoverability of functions of specific applications).
This doesn't help when you want to map the fuzzy idea of performing a specific action to a particular existing program but it has helped me avoid having to search online for how to perform a particular task with ffmpeg.
That's basically what cheat.sh does. It's an editable wiki that contains common use cases (cheat sheets) and can be called directly from the command-line, e.g.:
That's what aliases or shell functions are for. Put them into your .bashrc/.zshrc/.whatnotrc and you can have commands like that, without messing up the fine tools you mentioned for the rest of us. Just drop the first space.
ffmpeg--resize-video video.mp4 50%
.bashrc:
ffmpeg--resize-video() {
ffmpeg ... "$1"
}
You'll have added benefit that ffmpeg--<TAB> will suggest you only your own UI, without interference from the tool's own options.
I make extensive use of aliases and bash functions. It's my only way to keep sane since I'm not smart enough to remember all these command line arguments....
Except modern UI design sort of threw the aspect of discoverability out the window. Context-sensitive elements, dependent elements, hidden elements, and the dreaded hamburger menu are all awful for discoverability, and they're present on nearly every GUI.
There's always a space tradeoff, of course. If you didn't make some things contextual or put them behind a menu, you'd have to find permanent space for it on-screen. At some point, your UI then turns into a "Find Waldo" scenario.
For everything negative you can say about modern UI patterns like the hamburger menu, lack of discoverability isn‘t one of them imho. You have a single button with an almost-standardized icon, from which you can get an overview of all the (non-context-sensitive) actions. Relative to menu bars, the actions are sorted more by their importance than some vague categories. (Where do you find Settings? Under File, Edit or Help? No, as a top-level entry of the hamburger menu.) Of course it has its own problems, like number of clicks...
Hamburger menus work because software that employs them is trivial. Often not far from a toy MVP. Discoverability is easy when there's not much to discover.
All the pre-Web UI patterns start to shine when you're working with more powerful software tools - where there are more than half-dozen available actions, so you can't just stuff them under a single hamburger list. You have to start categorizing, grouping actions by their commonalities. You can't sort by importance, because importance changes from minute to minute.
And menus of old were plenty discoverable. They weren't categorized for discoverability, because that's not the job of categorization. If you want to discover what the software can do, you spend 60 seconds expanding every single menu and reading available options. The categorization is there to introduce grouping concepts that are easy to remember, so that next time you're looking for an action you know (or suspect) exists, you know where to look for it.
Yeah I'm confused about what OP meant was wrong with hamburger menu, the paradigm is "if the screen is too small for File | Edit | View | Etc. | Help, then collapse them behind the hamburger, which is generally good and sane.
what do I do apart from searching on the internet?
On a real UNIX like HP-UX, IRIX, Solaris, FreeBSD or illumos (and any of its distributions), you'd run catman -w as root only once for the lifetime of the system, then run:
man -k "disk space"
and then you'd search for SEE ALSO with "/", eventually you'd run into df(1), under the very bad presumption that it isn't the first hit.
EXAMPLE (Solaris 10, identical for illumos / SmartOS)
> man -k "disk space"
cfsadmin cfsadmin (1m) - administer disk space used for caching file systems with the Cache File-System (CacheFS)
df df (1b) - display status of disk space on file systems
df_ufs df_ufs (1m) - report free disk space on ufs file systems
snmpdf snmpdf (1m) - get a listing of disk space usage on a remote machine by means of SNMP
space space (4) - disk space requirement file
df df (1) - report file system disk space usage
df df (1gnu) - report file system disk space usage
...on a real UNIX, manual pages are THE resource, they are very comprehensive because they were written by professional documentation departments, respectively professional technical writers in those departments working with the actual engineers who developed the software.
The manual page system on a real UNIX is designed to locate exactly the type of information you would be looking for quickly, efficiently and most importantly, consistently.
It's GNU/Linux manual pages that are utter garbage, ergo switch to a system like SmartOS and never look back.
> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate
I think that's more a design-problem than actual trait of GUIs.
GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells.
> TUI/console is very good for interoperability/automation/muscle memory,
TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript.
> If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.
Text-based interface with fuzzy contextual autocomplete is the best of both worlds. Think of an IDE's autocomplete popups, but for terminal commands. Or how the Command Palette in means I almost never have to memorise where some obscure setting because I can just type the first few letters and find it as a top match.
No such UI exists for terminal emulators because they don't work that way, but I'm convinced if someone made a program entirely around text with autocomplete it would be just as accessible to non-technical people.
>GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file...
You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable.
My wife, for example, grew up before Windows 95 and its descendents were invented, holds multiple post-secondary degrees, and works with computers every day. She has no idea a second mouse button exists let alone that she can use it to perform file manipulation operations. She doesn't quite get the idea of "home directories" or "nested folders" or anything that is hidden like menus (or, frankly, tabs in the browser.. or multiple browser windows in fullscreen mode). Those things are not intuitive or discoverable in any way if you haven't been trained in their use. I, too, often forget the context menu is there although with practive I'm getting better. I certainly would never forget the `df` command though because it's second nature to me after over 40 years of use.
People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar.
You're right that there's some irreducible aspects to even GUIs that isn't intuitive and you just need to be told how to use it once, but GUIs have an advantage in that the overall 'language' of those things is far more limited at a basic level.
Once you've figured out that mouse movements correspond to moving the pointer, clicking your left button usually means you want to do the primary interaction with whatever you're clicking on (opening a program, pressing a button, checking a checkbox), and right click gives you additional things you can do with the thing you're right clicking on, you've figured out enough to be able to at least use the system (I agree you're by no means proficient in it though).
To get comparable proficiency with a command line requires a much larger set of things to remember for even basic usage.
> "People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar."
That is not the argument they made, they said right-click acts as a "tell me what I can do with this file" discoverability tool, not that right-click is itself discoverable. There is approximately no way to discover this on a command line, but if you right-click and "play with Windows Media Player" is there, it tells you something useful.
But I'm going to make the argument that it is discoverable. Why isn't the context menu second nature to you after over 25 years of use? You put your hand on the mouse, it has two buttons, you click one of them in ordinary operation, what kind of hyperbole is it to say that "clicking the second button does things" is "not discoverable in any way"? You discover that by accidentally mashing it one day, if nothing else.
That's apple's problem. I've been fixing apple devices since the puck mouse. They choose to go against the grain on purpose. Sometimes it makes sense and sometimes it makes absolutely none.
It means it's not the fault of the Windows 95 GUI paradigm most middle-class North Americans millennial age or younger have been trained with. Windows 95 is not the GUI paradigm, it's one single product that implements a GUI paradigm.
> You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use.
it's easy because MS has spent years in formal user studies for almost every element of the 95 UI to make sure that it was easy for pretty much everyone.
Meh if my grandma can get folders and hidden menus with just using simple box in a box analogies and a couple of drawings of the difference between RAM, hard drive, and CPU I'm sure your wife can too. Sometimes there's just the lack of curiosity about such things that prevents people from learning it, not age. I had a friend who mf'ing wizard at spreadsheets and vba because she likes what you can do with it. I tried to talk her though just installing an adblocker and newpipe install for better access to youtube and I might as well as have walked outside and started talking to my wood fence to get the same end result. So she drove over and I installed it for her.
I work in a public library and it has come to be my opinion that there's nothing at all intuitive about MS GUIs. Of special note is the awfulness of printing about which I'm asked 3-6 times a day, every day.
The thing about graphical interfaces is that a lot of the lack of standardization is purely cosmetic. A context menu may have rounded corners, or a black background and so on but the user doesn't have worry about these differences.
Cosmetic differences in CLI applications are actually important to get them to work in the first place. dash vs double dash, equals sign or no equals sign. CLI parsing is completely nonstandardized. Each command reinvents parsing and is completely unpredictable.
The only way you could possibly solve this is by letting the shell parse CLI arguments and just pass them as a JSON like object to the application. The ship for that has sailed a long time ago.
> I can right-click to see everything that can be done with the file, including some third party programs
Everything? Almost certainly not! That is the main problem with GUIs. The "everything" is defined by the programmer, not the user. Sometimes that works for you, sometimes it doesn't.
It's important not to confuse TUI with "console". TUIs are essentially the same as GUIs in this discussion. CLI (console) is completely different. CLIs use a language to describe what you need. To use an analogy, imagine ordering food in a restaurant. You could get away with pointing at the menu as long as you're happy with getting the default configuration. If you want to ask for no cheese, or less mayonnaise, you have to use language.
I'm surprised there is a distinction between the two at this point. What we have are "user interfaces" and both are graphical, whether it's interacting with text or graphics.
I think the main issues of usability are paradigm-independent—how do you make the UX more discoverable for text interfaces? How do you make the GUI more powerful and accessible to scripts? GUI development was introduced to make computers more tactile, and feel more life-like and accessible; and it works.
The reason Text-UIs work better for automation is that programming languages these days are text-based. How might one shift to a more graphical-programming paradigm? Machine learning I think has a lot of potential in this area and I would love to see some new work in this space.
> f I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it.
No OOP language can have a search feature as useful as Hoogle:
I feel like the autocomplete offered by fzf with <command> * is a step in the right direction. I don't think it supports flags atm but that could probably be done with a script.
"free space" doesn't turn it up, but on my system only turns up one result that obviously isn't it, no big loss.
"free" also doesn't turn it up, which seems like a missed opportunity. Going through the 40ish results before you're confident it's none of them is needlessly painful, but not crazy.
Both "disk" and "space" do turn it up, though, and also surface du (amongst about 50 other things).
I don't think scanning through <100 text items is clearly worse than digging through (say) the Windows control panel GUI.
~~~
I'd also note that TUI encompasses two kinds of thing - the utility in the shell (like df) and the captive interface that takes you away from your shell for an extended time as you navigate possible actions in some other manner. The latter has more of the benefits and drawbacks of a GUI.
~~~
In any case, I don't think your thesis is too far off, and I certainly welcome improvements to composability and discoverability across the board.
Regular users rarely type in commands. Either reverse search or zsh/fish/bash auto completion makes it much easier to run something in one two key strokes compared to few clicks in a GUI. Also switching to mouse from keyboard constantly slowes you down.
The inefficiency of mouse as interface is best illustrated in Excel which has power user shortcuts for every menu item. Expert users will never use the mouse if they can avoid it for the same reason. IDEs and many other apps work the same way.
Finally for developers who hav to work with servers, You don't have the luxury of working with GUI, you will have to learn these kind of commands anyway, using these locally on your desktop is more convenient.
1) I have an App - https://nocommandline.com - that is the opposite of this i.e. it says you should use a GUI instead of CLI (for a specific set of scenarios).
2) I'm not a 9-5 programmer even though I have a computing background
At a very high level - I generally disagree with 'you don't need a GUI' or 'CLI is better than a GUI'
At a nuanced level, I would say - it all depends. Sometimes CLI is much better than a GUI, other times it is the opposite. It all depends on what you are doing and who is doing what.
Software is all about automation and making life easier for you and/or others. If instead of having to remember a bunch of commands that I have to type, I can just click and get the same result, then click for me is better. It has made my life easier/simpler which is the essence of automation. GUI also becomes more useful for commands that you don't get to execute regularly. And GUI makes it easier for others to uptake the technology/learn it. Think about it - programmers tend to use IDEs to write their code and not notepad because IDE colors the text and so they know which are variables, restricted values, etc.
There is the argument that you can't automate GUIs. That is true in some contexts but in others, GUIs are usually built on top of the raw CLI commands so you have both worlds.
In other situations (and generally speaking), CLI is much more powerful because you have complete control of the 'innards' of the program. For such, I would say - yea, CLI all the way.
> "There is the argument that you can't automate GUIs."
Windows of the 2000-2010 era; when business tools were desktop programs and they would generally have a GUI, probably hooked into MMC so they could manage remote computers as well, have .exes which took at least some command line arguments, have a COM automation interface, and have tools which use fairly standard Win32 GUI controls which could be changed or scraped for data interactively with third party programs like Sys Exporter and had decent support for keyboard navigation with system-wide patterns like accelerators and tab ordering.
Take Kaspersky AntiVirus management console, it has:
- a GUI, a standard MMC style with a treeview on the left and a web page on the right[1], which is approximately "every gui management tool of the era".
- Various CLI tools that will do things like "check connection from client to server" and "force update"[2]. (Although rarely will Windows tools like this have command line options for everything).
- Documented automation interface using COM with examples for VBScript and JScript, but which can be used by any COM-supporting language (which is most of them on Windows - PowerShell, Python, C#, Dyalog APL, Java,...) [3] where the documentation is in a help file that installs locally with it. The ubiquity of COM automation in the Windows world of yesteryear is way under-discussed in the "can't script GUIs".
- Backed by a database, with documented stable views for you to query for reporting and integration, and the documentation is in a locally installed help file.[4]
By no means is this the end-all be-all of the computing world, but people who say "I only use a CLI" are missing such a huge part of the computing experience, and people on Linux where GUI tools appear to be completely isolated islands disconnected from each other and from everything else and second-rate afterthoughts, are as well. It used to be almost the default in Windows world for tools to take Active Directory / single-sign-on logins, to have granular AD backed permissions, to be automatable with COM, and so on. Ropey, unstable, proprietary, but far more amenable to poking-inside than people typically give it credit for. And it's going with the rise of "why invest when we could take profit instead, why build for the long term when I'll be changing jobs in 18 months, why build a desktop app when we could build a subscription service" models.
And then in the modern day it's SaaS web applications which are their own proprietary, isolated, disconnected systems, maybe with a limited REST API locked behind a premium tier or a rate limit and everything with a limited result set because they can't let you overload their servers, and desktop programs becoming some UWP app-store isolated container, or some Electron tower, also isolated, and/or cross-platform compatible and isolated from the underlying OS and its models of doing things.
If a non-technical person can't use it, a non-programmer, it has no value as a user tool. If you can't auto-deploy 1,000 servers at the other end of a headless network connection, it has no value for scripting. I'm sure there's a use-case falling by the wayside, technical people who could and would script GUI tools together - not for automation, for interactive use, for exploration.
The amount of times I've put |gvim - at the end of a pipeline to load the results into Vim, but then they get stuck there. Only to be saved as a file, or run through a new shell launched from Vim or copy-pasted out. There's no way that I know of to do `ls -l | gvim - | mv ./old` for example; you can do it if you know in advance what commands to run then you can use Vim in headless mode.
My point is there could be a missing, under-explored computing mode, part-CLI and part-GUI.
You need a GUI. The user experience of GUIs are superior to CLIs in discoverability, consistency, etc...
The only reason CLIs are still useful is because we still haven’t found a way to compose GUI applications well. We still can’t automate GUI applications, use the result of one app from another app etc... But that’s not something inherent to the GUI paradigm.
I think it is, which is why it hasn't happened. We shouldn't couple ourselves to the GUI itself (widgets, layouts, etc.). When you decouple the data and core operations from the presentation, you get APIs. Slap a flag parser around those and you've got yourself a CLI. (PowerShell is an interesting case study here too.)
You absolutely can automate GUI applications. The Mac had AppleScript and the Amiga had ARexx back in the late 1980s. Even iOS, which a lot of people think of as very obstinately non-scriptable/customizable, can automate a surprising amount of stuff using Shortcuts. What you need, as cle mentioned in another reply, is a way to decouple the data and core operations from presentation -- to wit, for applications to provide AppleScript "dictionaries," ARexx "ports," Shortcut "actions," or the like.
If you mean you can't automate a GUI entirely within a GUI paradigm, then you're closer to the truth, although Shortcuts -- and the third-party Mac utility Keyboard Maestro[1] -- are at least blurring the lines there.
Mac still has AppleScript, and for the past several years you can write Javascript (JXA) to achieve the same goals, with an extremely similar interface but a less-insane syntax
I've been using command line since my first computer with DOS in 1995, and I regularly use it now. For some tasks, like git or text processing, I strongly prefer it. Over the years I've used bash, fish and finally stopped on a pretty vanilla zsh setup, and can confidently call myself a mediocre console user.
But filesystem stuff? Looking at lists of files, ordering them, copying and moving? That's exactly what GUIs are easily superior at. Especially when the files you're working with are some kind of media.
Funnily enough, even with my own code made for running calculations only I will ever care about, I don't feel like a program is really complete until I've made myself a lame little GUI to drive it.
The problem is always the same. The "ugh" factor when I try to make the program do something I haven't made it do in a while. If code doesn't have a pretty front end for me to click on, I'll run it much less frequently.
(The second benefit, entirely unrelated to the article, is that it also allows me to make all my code incredibly fragile to bad inputs, right up until the point I make a GUI which is extremely fussy about inputs. Obviously, that could be done without the GUI, but it keeps me from spending to much time-- both in the sense of programming time and in the sense of run-time-- over-sanitizing inputs in the bulk of my code.)
Once learned the GUI actions are impossible to forget.
Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list.
The reason is simple: the brain can associate the GUI actions to many concepts from the real world. CLI concepts exist on computers and nowhere else. That knowledge is too abstract and too expensive to be kept unused in our brain's cache non-stop.
That seems like a poor rule. As a dev and systems engineer those shortcuts are codified in my head, but I've noticed other devs won't even know simple ones. I've taken months off and not forgotten them. GUIs change, get deprecated, can vary by medium etc... so the same can be said for them.
Generally, whether I'm making a CLI or a GUI, I establish contracts for display, input, and output. This at least allows for some albeit veritable consistency.
I struggle with memorizing CLI commands' parameters and special characters. This happens with git commands too and I use them all the time. Something like CLI autocomplete would be awesome.
Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list.
As someone who uses both GUI and CLI, and has taken month-long travels where I don't use a computer at all, I don't think this is true, at least for me. CLI is like a language; once you've really learned, it takes a long time to forget.
Yeah, like a language. However if I ommit a commmmma or mispel or abbreviate smth you'll still be able to understand me. A computer on the other hand...
Thankfully while computers are indeed picky about typos, they also gladly guess, complete and validate what you're trying to tell them if you ask politely (a.k.a. banging repeatedly on the tab key).
Your shell probably does though, at least for files and commands. Some like ZSH even have completions for common commands readily available, accept external completion plugins and let you write your own as a last resort.
Very easy to click the wrong thing in a GUI, It can be rather punishing. Keep in mind the buttons are like preconfigured CLI commands, so things can be more catastrophic.
Terminals have history. Or if you are working locally, just put the command in a script and name it something more memorable.
GUI layouts get moved around so you have to relearn where options are. In some cases, options get removed entirely in the name of 'user friendliness', whereas nobody's going to do that with CLI options.
I used to think I knew the Firefox layout (I've used it for more than 15 years), but now it takes longer to find things than what it used to.
History is really important here: I have like 10k lines in my shell history file of all the tasks I do on a regular (and not so regular) basis all of them are an Escape-? away (vim bindings in my shell).
That's supposing that said GUI are stable enough relatively to how often you use them.
Beside that, it still entails that you've to "wire your brain" so that it integrate the twisted specific ways they map on "the real world", with no guarantee that they won't change for external reasons, nor that there will be any sort of consistency across applications.
> Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list.
Sweet Jesus, the GUI lovers in this discussion really need to learn how to use computers.
I have a text file that includes several thousand commands that I have run during the past 20+ years. In one column there are the commands with placeholders, and in the other column there are descriptions of the commands. I have a shell function that provides this text file as input to fzf, and the shell function is bound to a key. I press the key, type a few words to find the command I want to run, press enter, and then the command is placed in the command prompt without the description. I can select any one of several thousand commands in 2-3 seconds because I type 120+ words per minute.
Don't get me wrong. I personally am a command line person too and I like your setup.
However, contrast:
> Right click and select menu option
with:
> In one column there are the commands with placeholders, and in the other column there are descriptions of the commands. I have a shell function that provides this text file as input to fzf, and the shell function is bound to a key. I press the key, type a few words to find the command I want to run, press enter, and then the command is placed in the command prompt without the description.
Is this satire? You're unironically arguing in favor of something that needs 20 years of Institutional knowledge to be compiled into a text file. When happens when you lose that file? What happens when you use a similar computer without that file.
You are so incredibly out of touch with regular human beings.
> Sweet Jesus, the GUI lovers in this discussion really need to learn how to use computers
Do you have any idea how obnoxious this comment is? I would love to have a discussion with you when you're 38 years old. I think you'll be amazed at how even your big impressive brain degrades, especially in memory.
There's a GUI I need to use twice a year. It contains confusing icons and processes that take multiple clicks with no way to come back. I used to do variations of the same mistakes every time until I wrote the steps in a text file (in other words I translated the graphical actions into text to remember them)
Some peoples' brains (such as mine, I believe) are more wired to be symbolic. I suspect that, for these people, using a textual-command-oriented CLI interface is going to be noticeably easier/more intuitive than those whose brains are wired to be more visual/kinesthetic/whatever else there might be.
I don't think that it's very strongly weighted towards "transferability toward other real-world concepts". The modern GUI interface doesn't seem to share many characteristics with non-computer parts of the real world.
I think many people are missing the point. I'd say the emphasis in the title is more on the "need" than the "don't".
Sometimes, you're in the terminal and something needs to be done quickly and knowing the correct command might be the best option. The author is merely trying to help people out with some useful commands for these instances.
I would, however, prefer that the author recommended using the interactive and verbose option for commands like `cp`, `mv` and `rm`, which I've personally found super helpful. Here's what I have in my `config.fish` (with a bonus for cp that preserves "mode, ownership and timestamps"):
I am confused if this article is serious or a subtle kind sarcasm aimed at bash. I'll assume its serious for the purpose of this reply.
> "they often require more resources"
I never had any resource issues with a file system manager, even on really old hardware. This line in particular feels very old school and nostalgic. Sometimes glitches happen if you're browsing a really large folder (thousands of files, very rare), but waiting a few minutes or using the filter textbox or switching to detail view (no thumbnails) usually takes care of it.
As a side note, the example is that of a Xerox station, and those were beasts of a machine back then with very expensive and powerful hardware specifically to demonstrate how powerful and fast GUI can be. Perhaps a gif of Pentium IV machine running Windows Vista would have been more reflective of what the author is talking about (sadly, those did actually exist back in the day, mostly running pirated copies of Windows Vista Ultimate).
> "are less powerful"
All the examples provided can be done with a single click on the UI. Granted the CLI can do more, but there isn't any example in this list of that nature. Even then, there are 3rd party plugins to any OS file manager that can do pretty much anything that isn't natively supported, at least for any major OS distributions.
> "automate via scripting"
I agree, albeit on Linux "dotnet run" [1] makes so much more sense over the bash code mentioned here, at least for anything that isn't a single one-off operation.
The File [2] class is an excellent example that makes for code that's readable even for someone who doesn't know anything about computers.
You can even do "dotnet run" on straight code, without having a file to execute. Of course aliasing it is the way to go if you'll do it regularly (dr? dnr? just d or just n?).
Alfred[1] (Mac app) w/It’s ‘Power Pack’ add-on gives you a clipboard history manager, text expansion, launcher and more. Very power. You can even navigate your file system, copy, move files... Easily the most crucial piece to my setup and keeping my hands on the keyboard. It’s been a solid app for a very long time.
The 3D visualization software ParaView allows you to capture all mouse and keyboard events by logging each event as its equivalent in their Python API [0].
For example, say that I’m visualizing a 3D scene. Clicking and dragging in the viewfinder changes the perspective of the camera, so this is recorded in the log as something like:
camera.Roll(45)
camera.Yaw(45)
Render()
If more GUI apps had exposed APIs, this would be a trivial feature to add.
GUI is a superset of TUI, in theory it's inherently better, they're often bad because it's a lot easier to mess up and designers are bad. Use GUI or not completely depends on the case, you don't need GUI if you want a list of file names under a directory, but you'll really want one if you're doing video / image / audio editing (cases where there's no well defined or multiple "input" and "output"). It's nice to have a compiled list of commands but the thumbs down is a little condescending.
I am incredibly grateful that the Chia cryptocurrency simply bundled all the complexity of their client into an electron app and made that available for their mainnet release.
It meant that instead of forcing me to screw around with novel terminology, novel design, and how those relate to a bunch of CLI commands, I could just:
1. Open a window
2. Be presented with a very friendly UI that stepped me through the process of creating a wallet and preparing my machine to mine.
3. Follow the easy to read instructions, without running into any error or any warnings whatsoever.
4. See the message that given my stock setup it would take me approximately 2 months to mine a coin.
5. Immediately uninstall the app.
If I had been forced to use CLI that would have taken me probably another ten minutes, for no gain.
Even if I had all that memorized I wouldn't be able to type it faster than I could do it in the GUI and one out of ten times I'd make a typo and have to tediously fix it. I deeply envy the skills of those to whom this page applies.
As much as I like the command line, I couldn't help noticing from the first 10 or so entries[1] that the "stop" text consists of one of:
1. Drag and Drop
2. Right clicking
3. Ctrl-C and Ctrl-V
So these 3-5 things do everything in the list in a GUI, and instead the author wants us to learn 35 different command/syntax combinations?
As an aside, I'd like to write an article saying "You Don't Need Github To Write an Article". If you insist on using Github for that purpose, at least do it properly with a static site generator.
You don't even need a static site generator. GitHub Pages uses Jekyll behind the scenes, so it converts your markdown to HTML for you. You can even select from a list of themes from the GitHub UI.
I, a developer, spend the majority of my time between IDE and terminal. I am most efficient if my hands do not leave the keyboard.
My business partner, not a developer, but a savvy user, but is pure GUI with the addition of some browser automation and various extensions. He is impressively productive.
It is all about what works for an individual user. I appreciate this post, because I’m a keyboard-focused user. Looking forward to reading it more thoroughly.
I think this document is a bit too belligerent. "STOP DOING xxx". Really, users should be free to do as they wish. I prefer using console a lot (though I use GUI a lot too!). But I wouldn't force others to do so. Educating them how (if they're interested) is a great thing. Making it sound like they're doing it wrong is not.
PS: One thing where a GUI really shines is picking a bunch of files from a folder and moving them elsewhere, based on a manual criterium that isn't easily identified by a wildcard. For instance, from a folder of documents pick all the ones related to a certain topic. A GUI shines for this, commandline is horrible for it. If I don't have a GUI available I will use mc for this.
However for other tasks, the commandline is gold. Finding all JPGs in a huge tree of folders and moving them all to one central folder. Easily accomplished with 'find -exec'. Very much work to do in GUI with default platform tools, usually you'd have to download some utility to do this.
So, for me they are both great options with their strengths and weaknesses. They complement each other. A good operator should be aware of both.
100% agree with everything you said. So many people use gatekeeping around using CLI, it's crazy frustrating. Use what you're efficient at for the job at hand.
To expand on your example: for a lot of readers of HN, moving all JPGs in a bunch of folders is going to be easier and faster with a CLI. But for <non-technical person in your life> who needs to do it very rarely, it's probably still going to be faster for them to navigate folder-by-folder in a file explorer, sort by file type, shift+select, repeat, than it is to learn how to use CLI to do it.
For technical people, GUIs also reduce burden, and let us be lazy. I "know" (or at least once did) how to configure Samba by hand, but for the last many years I've run OpenMediaVault at home and use the UI to do it for me. I don't use Samba for anything else in my life or work, so why do I want to remember or even spend the time reading the manual when I need to make a change to it once a year or so? I'd rather just log into the UI, click a few things, and be done. Nothing to actually remember, as the GUI gives me enough information to figure it out as I go.
I spend a lot of effort to be lazy. If I was regularly moving JPGs out of a folder, I'd probably go further and write a shell script or alias, or even just make a cron job to do it for me; likewise I'm happy to install/use a GUI app for certain things if it means I save time vs reading man pages or having to remember arcane commands I rarely use.
I do enjoy ranger (TUI) for the reasons you mention, but I find something like pcmanfm feels less powerful, and harder to control.
This isn't because pcmanfm is a GUI program, but rather the culture around GUI programs. If you want a good GUI, look at emacs. As good as the TUI version, but with support for images and more colors. It's possible, but rare. I think the devs for each type of program tend to differ in mindset.
> Finding all JPGs in a huge tree of folders and moving them all to one central folder.
That's easy in Windows File Explorer. Type Ctrl+F, then *.jpg, then Enter. Wait for the search to finish. Type Ctrl+A to Select All, then Ctrl+X to Cut. Then go to the target folder, in the same or a different File Explorer, and Ctrl+V to Paste.
Someone who isn't familiar with the keyboard shortcuts can do the same with the mouse. Either way, if they have ever edited a document and done something similar with cutting and pasting text, there is nothing new to learn except understanding that the same steps work in File Explorer.
It also works in the default file manager in Ubuntu with minor changes: don't hit Enter after typing the search text, do click in the result list before the Ctrl+A.
436 comments
[ 4.9 ms ] story [ 828 ms ] threadMost of your GUI users are on Windows, and unix shell commands mostly do not work or are aliased to other commands that don't work exactly the same way as they do in GNUland.
Installation instructions for Windows are horrifying -- page after page of pictures, with circles and arrows and a paragraph... And when the OS is updated, all of the dialog layouts and icons change just a bit and you're lost. Just gimme some shell commands.
"OK, GUYS! We're going to start at the desktop. Now click on Start..."
Watch someone moving their mouse around for 20 minutes, making mistakes, backtracking, hovering over things so they remember what to do, then finally achieving what the tutorial was about. Ending the video with "Don't forget to like and subscribe!"
This could have been a single command line command.
... that you could have copied and pasted.
When it comes to technical support on Linux, few people seem to realize how much easier it is to provide support with a handful of shell commands. Describing how to do things in a GUI usually involves awkward descriptions, multiple screenshots, or a video demonstration. Actual support involves doing all of that in both directions (or having someone else log into your machine to do that for you). With a terminal, you're just copying and pasting text.
Probably way more than you'd think. Most people get thrown into the unix shell at some point without learning it properly. And its easy to accidentally miss a lot of fundamentals due to imposter syndrome + the terminal's terrible discoverability.
I made a simple build system at a company I worked at a few years ago to build production docker images. It was a little nodejs process which ran docker build in a subprocess, and streamed stdout / stderr to the browser. So you could kick off a build with a few clicks of the mouse and you could see it build + deploy. The whole thing was just a couple hundred lines of code that I whipped it up in a day or two.
Some of my coworkers were way more impressed than I expected. They're great senior web programmers, but apparently they just never learned unix properly and didn't realise how easy it is to do stuff like that.
Personally I think the link is an enormous waste of time.
Name one thing that a GUI program can't handle, I dare you. Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least.
So just because companies have proven that GUI is successful and capable, it's still possible that it "can't handle" a lot of things nearly as effectively as CLI in some cases.
Here is a simple task which can easily occur in business: you have a folder with thousands of files named somewhat haphazardly. Copy all the files with have numbers 2011 to 2019 anywhere in the filename to an usb stick.
I would search for "2011 2012 2013 2014 2015 2016 2017 2018 2019", select everything that shows up in the search results, and copy those to the USB. Wonder what I'd do with millions of files though.
> Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least.
No you can't. There are 5 companies with a market cap over a trillion. We can easily rule out Apple, Microsoft, Amazon and Google as they have all developed CLIs.
That leaves Saudi Aramco. Doesn't take long to see they have openings for CLI heavy jobs.[1][2]
[1]: https://apply.aramco.jobs/us/jobs/1786333?lang=en-us
[2]: https://apply.aramco.jobs/us/jobs/1780310?lang=en-us
Aside from that being an entire industry as opposed to a single company, are you not aware that BigCo games generally contain a developer console of some sort? Even the ones that don't provide end user access to it still usually have one buried somewhere.
Plus many of the dev tools for manipulating assets are either CLI based or have one integrated ...
- Optipng
- ffmpeg
- sox
And so on.
[1] https://docs.xfce.org/xfce/thunar/bulk-renamer/start
[2] http://www.den4b.com/products/renamer
[3] http://www.antp.be/software/renamer
Pipe input/output between programs. Chaining cli tools is essential for my work and personal usage.
> Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least.
That's observably not true. Why didn't you just type out the name?
And even though the game industry primarily makes GUIs, it still uses CLIs everywhere in the development process, so it's pretty silly to say that it "uses only GUI and not a single CLI." And the console that's present in just about every game doesn't seem very "graphical" either.
A CLI represents that structure by accepting textual commands and presenting output textually.
A GUI represents that structure by displaying objects graphically, showing their spatial representation and connection.
And, traditionally, a GUI tends to show more structure up front while a CLI simply prompts you for a command.
The distinction isn't perfect, but a text adventure game is well inside the CLI camp.
2. Every single company in that industry uses cli tools.
Both assertion from your original statement are incorrect. What’s your beef with the command line anyways? It’s just an interface.
That said I now work in the Windows world. I find that if you are using the same tools day in day out then the keyboard is the way to go. If you have to use new tools every other week the GUI is hands down much better. Unfortunately in my role I'm doing exactly that.
The other issue is that few file managers are as powerful as command line utilities. There are exceptions. I am quite fond of Directory Opus while using Windows since it feels like a program designed by people who understand the scope of file management. Alas, it is an exception rather than the rule. Most file managers facilitate basic functions then stop there. With the shell, that's not really an issue since you can always add another utility to your tool box.
Linux (whatever env provides this): xdg-open $dir
qmv -f do *.pdf
find -name "*.epub" -exec mv {} ~/books/ \;
cp *.c ~/remote/hostname/src # with sshfs
The list can go on. The GUI may be better when you have to manually pick through a small number of files, but calling up a file manager to handle a single file or a bulk operation rarely makes sense (if you're already in a shell).
EDIT: inserted line breaks
You might be in a terminal, in the directory you're you want to copy a file within... $open ., type file name, command-C, command-C, command-W would do a great job, require minimal additional effort, but provide better visibility into the status of the copy, allow you to better handle file name collisions, allow you to retry, and be undoable.
If you didn't know the correct program or arguments for zip, you could simply look around the menus and find 'compress'.
Even scripting, you can use the best tool for the job. AppleScript or similar can be used to script GUIs and also for testing.
I don’t know if it’s more efficient, objectively, but this just is the workflow that matches how I think.
Yeah, because that's way faster and more convenient than double clicking on an icon.
This one is great too: Don't open the file explorer! Instead you should type "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'"
Seriously?
It is if you happen to have both hands on the keyboard.
That said, I usually navigate a GUI file explorer using the keyboard too, so pressing Enter to open a file is even faster.
(This comment was submitted entirely using the keyboard.)
When copying files from one directory to the other - CLI vs GUI is debatable in terms of speed (I'd still say GUI is faster, but let's assume its debatable). But what if I want 1, 2, 5, 7 and 10th file; not all files? It is remarkably faster in GUI: Ctrl + click files I need and drag+drop. Done. Good luck fumbling around with CLI.
CLI nerds are the most annoying people I've encountered. They're myopically obsessed with their tmux + cli workspace and are not open minded.
I would've been able to type open and tab-complete the filename in the time it takes to move my hand over to the mouse, move the mouse to the right file, and double-click. The mouse is close, but not as close as the keys under my fingertips.
How did you do that? Using a specific browser extension?
I am looking for ways to use my browser with keyboard only.
If you're willing to ditch the mainstream browsers, there's Nyxt. For browsing static wikis from a tty, there's ELinks.
So z [4 chars] enter o [2 chars] tab to complete enter is actually pretty quick.
No matter how fast you can type, typing this clusterf*ck of a command isn't faster than using a better utility (command line or GUI). And I assume complete beginners (which the page seems to be for) don't know how to set up shell aliases just yet.
Say I want to edit .psqlrc
Doing it in GUI is like 10x slower. First dot files are usually hidden by GUI, so I have to search through menus on how to enable their display. Then I have to look for the damn file. Where it is among 200 similar dotfiles? 5s later I find it. Now right click, pick an corect editor from a submenu of a context menu. Edit. Save. Now go back to file browser and disable dotfiles display, otherwise all my regular files get drowned in noise, slowing the normal usage. It's retarded.
Alternative. Open terminal. Type vim .psqlrc. Edit save. Close terminal. 3s top for the non-editing parts of the workflow.
They do say you can just write `tree` on Linux. If you don't have that command, you can just alias `tree` to the find command.
I'm guessing that the reason it's not there is that for most casual/GUI users, Documents/Downloads/Desktop (which are all in the sidebar) takes the role of /home in traditional Unix.
I haven't had a GUI file manager installed on any of my desktop computers since the early 2000s, and the last time I used one regularly was the mid 1990s.
Hacker News in 2021: Where the "hackers" think that "doing it in command line is pointless."
(Ok, with the exception of wanting to look at a bunch of images in thumbnail mode. Then I launch a GUI file manager.)
The shell is where I "am" and launching a GUI seems more cumbersome than typing the command.
In fact reading this post made me realize that using the terminal for file operations is not as common as I thought.
Even when I use Finder, I use it like a CLI: typing and shortcuts for everything and minimal clicking.
The only exception is that I occasionally drop files, urls and documents from GUI applications into iTerm, rather than type out the whole thing.
Additionally, I think some of the listed tasks are objectively better in the GUI, despite being possibly slower. For example, in the command line, deleting a file doesn't send it to the "Recycle Bin" or your OS's equivalent, it simply deletes it. This is better for things like scripts, but worse for someone using it as a GUI replacement, since now there's a risk that they could permanently delete an important file due to misspelling or something of the sort. I find it hard to remember sometimes that Emacs is a GUI too, and it can often be the best way to do any given task.
Use trash-cli: https://github.com/andreafrancia/trash-cli
These are the main reasons I stick with terminal based editors over something like VS Code with Vim bindings. Using a separate GUI breaks that deep integration with the shell, which for me just creates too much friction for not enough benefit.
If you're okay with waiting 5-10 seconds for your editor to load, fine.
Midnight commander, for example, has the command line in it, so you don't lose it. But even without the command line embedded, I'm sure I could do common file operations much faster in it than 90% of command line lovers.
Good curses based GUIs can be quite efficient. Usually won't beat the command line, but can get close, and are much easier to learn.
But...
GUIs support the concept of undo. It would be great if all shells indicated the command to undo what you just did, and you could turn off that warning message with an environment variable.
And, almost none of these work in the Windows command prompt. I've tried powershell and while there are some great ideas, nothing behaves as I would expect after using bash for 20+ years.
These are the reasons people use the GUI. Without acknowledgement of that, this readme loses some of it's lustre.
I also am not quite sure what the post above means by "GUIs support undo". Yes, most apps,e g., on Windows, support CTRL-Z for undo. But this functionality depends on each app implementing its own undo, nothing OS-wide, and results will vary. I'm not sure what there is in GUIs that supports "undo" other than an app/user convention like CTRL-Z, which hardly seems to rise to the level of "supports undo".
Why doesn't bash in a friendly system like Ubuntu have undo for mv.
The issue is that tasks on the CLI tend to be split between many different utilities. So you'd either need a standardized method for sharing an undo tree between the different utilities, or alternatively to integrate all the different tasks under a single program.
I mostly just use Ranger in a VTE to be honest. Cut/Copy/Paste and directional navigation of a tree using standard Vim keybindings is just more fluid than anything with a mouse could ever hope to achieve. Add to that dropping to the shell with `S` with my hands already on the keyboard and it's by far the best workflow I've come across.
Which makes it all the more infuriating to the user that they don't.
Even when it's doable, some of us prefer to risk unrecoverable mistakes if it avoids having to take an extra step for the command we launched to be effective. I don't want to "empty a bin" after a `rm`, I want free disk space, and yeah, it could be almost impossible to undo.
I understand that safeguards around destructive actions or actions cancellation can help UX, however at some point you can't make an omelet without breaking eggs.
TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder. If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
It's interesting that there is some analogy to object-oriented and functional paradigms -- if I have a rich object in a debugger in Python, I can call dir() on it to immediately see what I can do with it. Whereas if it's a simple dataclass, I'd need to search through code to find how I can use it. Might be a too far fetched analogy though.
I think we need all of it, and also need to make the distinction less apparent. Would be nice to make GUIs more composable, and TUIs more discoverable. Ideally it should be a spectrum of interfaces, so you don't have to make a hard choice and can gradually move into the direction you want.
You can do that locally on the command line too!
https://en.wikipedia.org/wiki/Apropos_(Unix)
$ apropos "disk space"
df (1) - report file system disk space usage
$ man -k "disk space"
df (1) - report file system disk space usage
and
$ man -k "disk usage"
docker-system-df (1) - Show docker disk usage
More seriously: You can alias it to something you can remember, for example:
There are a small number of seed keywords which are ueeful to know. 'help' (shell), 'apropos', 'man' (online manual), 'info' (GNU documentation), and dwww (local documentation presented through a Web interface, available on Debian-based Linux, see https://ostechnix.com/dwww-view-complete-debian-documentatio...) are among them.
Knowledge requires a certain baseline.
If that's too much ... perhaps a GUI is in fact advisable.
Now a TUI isn't the same as command line and most GUIs allow for substantial keyboard functionality, but I think developing for a TUI tends to get you thinking about a person working a keyboard whereas developing a GUI you're thinking more about the person with a mouse/trackball/trackpad/touchscreen.
Personally, I do a lot of database work; mostly PostgreSQL. I decided some years ago to bite the bullet and get rid of the GUI and just use straight psql. I largely haven't looked back, though if I'm doing heavy development work I just started using DataGrip since it helps avoid stupid errors that a simpler text editor doesn't find.
https://www.pgcli.com/
When the sorts of things that pgcli does becomes most helpful is when I'm writing functions and procedures, but then the command line isn't well suited for that. That's where I'm finding something like DataGrip helpful: a database tool focused on development rather than administration. DataGrip has a lot of faults, but for the past couple of weeks I've been using it, it's been on balance a win.
i use ssms for mssql, and i have a large solution with multiple projects
i know datagrip can be used in the same way as ssms, but can you this be done using psql
and then later at the command prompt you access it as; ":show_slow_queries".
I have a few system queries like this in my .psqlrc file, but I don't do much which this feature often truth be told. I have a pretty strong knowledge of the database schema I work with, I do a lot of work on systems I don't regularly control so its not dependably available, and readline history suffices for more immediate needs.
https://github.com/hediet/ts-cli/blob/master/cli/README.md
PS scripts (and even functions) declare command line arguments up front, and depending on how much time and thought you put into it, you can constrain the arguments quite well. See [0] for overview of the available functionality. A quick TL;DR:
- You can make parameters typed, and PS will handle relevant conversion if the user just types strings in. E.g. you can mark a parameter as [DateTime], and if the user types e.g. "2021-04-01", the script will receive an object that represents the midnight on that day. If the user types in "foobar" instead, they'll get an immediate error[1] telling them the parameter cannot be read as a date.
- Add [] to parameter type (e.g. [DateTime[]] instead of [DateTime]), and now the parameter can accept multiple values (arrays), - but behaves smartly if only one is given.
- You can mark parameters as mandatory. You can mark parameters as positional (i.e. provided without specifying parameter name on invocation). You can mark a parameter as designated "catch-all". You can define aliases for parameters, to allow user to write e.g. -Runs, -Run or -R, and have all three refer to the same parameter.
- You can mark parameters as "accepting values from pipeline" (and define how exactly). Since PS pipes transport typed objects, not raw bytes, this is how you can both set expectations, and write scripts that can flexibly mix pipes with commandline arguments.
- You can define validation for every parameter individually.
- You can group parameters into sets, based on what other parameters are provided, or some custom logic. So e.g. if arguments -A and -B only make sense together, and then -C doesn't do anything, you can encode this cleanly.
- Autocomplete in PowerShell is aware of all these things! It'll hint you appropriately. And you can provide your own autocomplete hints too.
How is all that relevant to this thread? The last point is a spoiler: all these declarations can be extracted from the script, and they provide enough information to build a high quality GUI for the script automatically. PowerShell ISE, that comes with Windows, exploits this to a limited degree - it contains a GUI for running PS cmdlets that lists parameters and their types, makes use of optional/mandatory status, and groups them by parameter sets. There's nothing stopping one from building an equivalent UI generator that would also provide custom widgets based on argument types (e.g. file pickers for paths, calendars for DateTimes, etc.).
--
[0] - https://docs.microsoft.com/en-us/powershell/module/microsoft...
[1] - Errors in PowerShell are a bit user-unfriendly. Niceties like invocation with underlined mistake are surrounded by long error text and small stack trace. I wish they improved on that; even for script developers, most of the error message is quite useless.
TypeScript is not yet expressive enough for direct shell usage, but not much is missing imo (most importantantly a pipe operator).
But I get it. It's the consequence of trying to use the same language for code and command line input. > and < are already used in pretty much every single shell to indicate IO redirection; particularly with >, it would be really dangerous for it to have context-dependent meanings. And then foo -match bar is more CLI-input-friendly than foo.match(bar) or match(foo, bar). You can get a similar experience if you try to use (or design) a Lisp shell. S-expressions are awesome, but having to move the caret back and forth to add/modify structure in your command is too annoying for a shell language. For shells, you essentially want as much appending and as little editing as possible.
And as much as I don't like JavaScript ecosystem, I would like something like TypeScript in the shell. Personally, my main requirements are 1) optionally typed, and 2) piping structured data instead of unstructured text/byte streams.
(And then I'd like a terminal emulator that makes full use of type system in pipes and command arguments.)
--
[0] - They started simple, then they grew, and before I noticed, they've crossed the threshold where, if I were to write them again, I'd use a regular programming language. I think the point in which I started including bits of C# code in the scripts should've been a wakeup call... but on the other hand, isn't it just cool you can drop down to C# in the middle of a script and have it Just Work?
The nice thing is that by using the keyboard to navigate menus, you develop muscle memory for "shortcuts" without really trying. And if you ever get "stuck", not knowing how to complete the sequence, you only have to look at the currently open menu.
Formica doesn't do this, but this could be extended into rudimentary scripting.
This kind of paradigm won't fit all software, for example I don't think it's a good fit for software where typing mildly structured text is the main mode of interaction. It might be mainly useful for shortcut-heavy software.
[0]: The software in question: https://www.formica.cz/
Having said that, I think that the inertia of "good enough" is a real danger to the concept. The new user that uses the less efficient GUI aspects of the interface to learn quickly may not have much incentive to go the next step and work the keyboard oriented workflow into their muscle memory. Also, if you realize that issue, there's also the problem that if the keyboard interface were less used, there would be less incentive to fix issues or add features to it as the application changed. Rightfully, it could become less useful because of less attention. I can tell you that in practice I find it fairly uncommon to see staff using the keyboard capabilities insofar as it's already supported by their GUI applications.
This worked surprisingly well. New users mostly stuck to the menus to discover things, but then gradually switched over to commands for common actions, because they were faster. It also helped that the Command window had context-sensitive help, so once your menu action generated the corresponding command, you could easily open the manual page for it to read up on the details.
This is generally true of built in Windows applications (even if the transition to ribbon interfaces complicated flows). It is spotty for third party applications.
Unfortunately on Linux, at least on KDE (I don't like Gnome since v3), keyboard navigation is broken even on default applications like Dolphin or Discover.
Mac OS, I remember (Tiger -Lion) being pretty good.
Smart move by (for instance) Microsoft when they did that in Windows 95 and continued it til now. You could theoretically design the same functionality into a text user interface. Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) it could give you a menu to choose from context specific commands. It would seem pretty natural in that case if you are using post-fix (arguments(s) and then commands, like in Forth). Maybe something already exists like that.
How about:
index.html <tab>
And you’d get open, copy, rename, create symlink, delete, compress, etc.
Why does the order of commands or their names have any influence on whether pipes can be used? How do you pipe the output of cp into awk?
I can try... Specifically, given a command that produces a list of "everything that can be done with the file", how do I cause the (unstructured) text of that list to be piped into a arbitrary other program, in the same way that `grep foo a.txt | bar` causes a list of occurences of 'foo' in a.txt to be piped into arbitrary program bar.
> How do you pipe the output of cp into awk?
As I understood the suggestion re. file actions it is meant as some sort of interactive completion. So if I type the name of an image file and press tap, I am given the suggestions or options about resizing, format conversion etc. Several shells already have interactive completion of file names.
And I think that pattern makes sense from an exploration perspective. If you learn that file name + tab gives suggestions, then a lot of the learning about what the command line can do can be done directly in the command line.
And maybe it could be a command rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
I really don’t see how this is incompatible with existing workflows :-)
Yeah, I was giving a example of a sensible way to design it, not documenting something that already exists; sorry if that wasn't clear.
> And maybe it could be a command [like `file -u FILE`] rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
Pretty much that, yes.
> I also find it a bit hilarious that the example lists `ed` as the editor of choice.
I don't think unix had TECO as a standard utility, so I went with what was available.
index.html open | sed
Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications? I see no technical reason for the lack of it. Look at something like htop -- it has a sort of "command line version of a macOS menu bar" with each menu selected by a function key. I could easily seeing this idea being extended to, say, being called by the familiar --help flag, or each menu visualizing a sub-menu upon pressing a function key, etc...there's no reason CLIs can't have the same discoverability as GUIs.
File explorer multi pick is the thing I desperately claw for for a pointer.
That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands.
Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities.
And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified.
This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX.
Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).
On one axis we have graphical (raster mode) at one end and text at the other. On the other we have as you calld them action-oriented (WIMP) and line-oriented (I would call it command-oriented).
There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like *Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.
And there are graphical command-oriented apps like Jupyter or ReGIS or Sixel or iTerm or TermKit or Kui or the command palette in VSCode or Atom or others.
And you can have them mixed like in youtube-dl GUI or ffmpeg GUI where the changes you make in the GUI are reflected in different arguments for the command and you can see and edit the command before executing it. This is similar to getting keyboard shortcut suggestions in menus or tooltips.
We need more innovation in this space. Ways to achieve both discoverability and scriptability. We need more hybrids and less systems that stay in their lane. Graphical text editors with command pallettes, PowerShell with its object oriented piping, Jupyter are moves in this direction.
This is a power user direction. And it is opposed both to the minimalist touch friendly trend and to the terminal-first mindset.
These are graphical programs, just with a substandard drawing api.
They are not graphical programs. They are generally recognised as TUI programs. If these are graphical then so is Vi or the fancy powerline prompt.
Our point was that you can also have command lines in graphical applications and WIMP in text mode applications.
https://en.wikipedia.org/wiki/Text-based_user_interface
https://en.wikipedia.org/wiki/WIMP_(computing)
How should we classify the following?
- Programs like coreutils that receive arguments and return a result
- Programs that start a menu or wizard in text mode
- Programs that start a interactive command line like various database CLI interfaces, shells
- Programs like Vim that have a TUI and are command line driven.
- Programs like Tilda that have a WIMP TUI
I think the last four have graphical equivalents (eg. Windows installers, Jupyter, VSCode, Notepad++ respectively) and what is missing is a graphical interface for passing arguments to programs.
The mark of a command line is a stream of commands and responses, not whether it does ascii art to emulate graphics.
I do agree with your definition of a command line interface as a stream of commands and responses.
Compare that to most GUI apps where you can just open and use and learn as you go.
On IBM i (originally known as OS/400), you can press a function key and automatically get a fill-in-form for any command.
This is because command line syntax is defined, not in your program's code (getopt calls etc), but using declarations in what you might consider to be a separate command definition file (technically called a "*CMD object"). The OS does command line parsing and validation, marshals the result into a memory block, and passes that to your program rather than the raw command line. And the OS uses the same command syntax declarations to generate the (text mode) fill-in form for display.
Other systems which use the idea of command line syntax declarations, with the shell doing option parsing based on those declarations instead of each program doing them itself, include OpenVMS DCL and PowerShell. (PowerShell actually copied this idea from OpenVMS DCL and IBM OS/400.)
I think the big reason why this is less common in Unix-like systems, is the design decision to give each command responsibility for parsing arguments/options, rather than doing it in the shell. This makes the whole approach of automatically generating fill-in forms at the worst impossible, at the best unreliable. You can try parsing --help output or man pages, but that method isn't always going to work, centralising option parsing in the shell does. It is likely rather too late for Unix-like systems to change their approach.
(TUIs are, or can be, GUIs with box drawing characters instead of pixel displays. They're not necessarily any more scriptable or any less discoverable; however, a TUI on top of a command line, like Norton Commander or Midnight Commander, can be a real winner of a design paradigm.)
I think that some version of this dichotomy has existed at nearly every point of computer history where technology allowed it, and that is surprisingly far back!
I'd try "ls /bin" and see if any of the names sounded familiar or possibly relevant. Or "man -k space" which shows "df (1) - report file system disk space usage" on line 24, which isn't a lot of reading.
GUI's aren't always intuitive. Nothing worse than not having the option in your right-click menu because you tried right-clicking in the left "explorer" column, but really needed to open the parent dir then right-click on the folder in the right-hand side. GUIs can be infinitely more difficult/complex.
Back in the Win95 days, I recall a case where someone couldn't figure out how to format a floppy. After struggling for hours, he did a search which found format.exe, and used it. It's hard to discover that you can right-click on the drive to get the option, because there are many things that don't show up there... You can't create partitions or change drive letters in the right-click menu there, for example, but how would you know? You've got to learn the options/capabilities for your system, whether its GUI or CLI.
What a GUI really has going for it, is that it offers a limited set of options, greatly simplifying the exploration. Something like Norton Commander, DOSBox or other limited/restricted shell (which shows only the most common commands) has similar discoverability benefits without the graphics, and still with those cli benefits available to you.
No. One has to be trained to right-click. What about interfaces that don't have a right-click, such as a touch interface?
Not only that, but the right-click menu has to be programmed. A lot of designers want minimalistic interfaces and would remove anything that isn't used often. So your right-click menu won't have those features.
> TUI/console is very good for interoperability/automation/muscle memory, but doing one-off things is harder.
Are you kidding?! I've found that doing one-off things is massively easier and faster in a TUI than in a GUI!
> In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
I've found plenty of GUIs that simply don't have what I want. Or... maybe they do have what I want but I couldn't find it.
Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution?
> I've found that doing one-off things is massively easier and faster in a TUI than in a GUI!
For example?
My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a completely different interface so nothing is ever consistent even on the "same" operating system.
> For example?
Example 1: download one file from a url mentioned somewhere
Example 2: download a bunch of PDF files Example 2: move all PDFs that I just downloaded: Example 3: find what text file(s) have some text Example 4: find what pdf file(s) have some text Example 5: compare filenames in the two sets: And now, I have accepted a file from a team member which describes URLs to PDF reports with magic. I have generated a one-off report describing which files have magic content that needs to be reviewed because it contains magic that's described in in a local database.How about generating a git-diff, encrypting it, and emailing it?
... Okay so those one-off things are complex things. How about simple things?Example 6: move a file.
Example 7: open a file Example 8: delete a file Example 9: mount a thumb drive Example 10: unmount a thumb drive Example 11: shutdown, and don't let any bad app stop the shutdown All of these are IMO easier than in a GUIDon't get me wrong, I also hate touch interfaces, for all the reasons you mentioned. But saying they're "bad design" is not a solution – it's a starting point at best.
What alternative are you suggesting for smartphone-sized devices? Mobile phones did have physical buttons, but once touchscreen-only devices came out, customers voted with their money. So much so, in fact, that smartphones with a physical keyboard are a tiny niche today. That's because keyboards just don't work well with small devices. Using a CLI with a smartphone keyboard would be an awful experience.
And that's just those who can speak English. If someone doesn't, it's just nonsense for them.
> One has to be trained to right-click.
One has to be trained to understand which commands exist and what do they do. I can't imagine someone without any training typing `grep -nRIiw`. Sure, you can look it up in the manual, but that's the thing - you shouldn't. You should consult the manual when you're using something for the first time or something isn't working. I can pick up any vacuum cleaner or get in a rental car and start operating them right away. I have to look up how flag works with different CLI apps. I shouldn't have to. Good design should be obvious.
That's why we're not typing `systemctl poweroff --force` to turn off a TV, we just press a button on a remote. And I can pick up remotes from other TV sets and turn them off without looking up their manuals.
> nothing is ever consistent even on the "same" operating system.
Funny you mention that. I tried some of your commands. Turns out, I don't have systemctl or pdfgrep installed. So much for consistency.
What if there was such a thing as a right click menu for command line programs?
Like if I type ffmpeg or youtube-dl with no args, it lists the 3 most common ways to use it, and maybe allows an interactive CLI menu where you can build up the correct argument list by answering a few questions.
I would love the most useful commands to look like:
Most realistically, I'd want the invocation without arguments to show an interactive menu of the top 3 uses, so I could just select what I want to do.Or if I provide a partial argument list, it should ask me to supply the rest of the args. Or maybe it should guess and do the right thing.
For example:
When I enabled tab completion for git and google cloud CLI, my life became much better.
However, I still think there needs to be a "right click menu" for command line programs. Someone needs to determine the 3 most common uses and make it so that --help lets me choose one of them by pressing 1, 2, or 3.
Right now, --help usually gives me something that is difficult for me to understand, especially if I have never used that command before.
Tab completion works great if I have used the command before and want to save time.
Tab-completion could additionally list the "most common things given the context* I have".
Tab-completion needs not nessecarily be postfix. I've seen completion tooling** that would work somewhat like `invoice.pdf<tab> -> `open invoice.pdf\n cp invoice.pdf` etc.
And if `<tab>` conflicts, or breaks your mind because it must only work on postfix, it could be anything really, such as `<cmd>-r`.
Additionally, or underlying, a reasonable simple command like `whatcan` or `ctxt` (context) could work and be leveraged: `whatcan invoice.pdf` -> a list of common commands given the context* I have.
---
* Context I have would be your ~.\_history, the current directory-tree, permissions (why show `mv` if you don't have write access?), applications available, etc. pluggable maybe?
** e.g. the <ctrl>-r, interactive bash history search come to mind as pattern. But also tools like FZF https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an... that don't nessecarily only "complete" on tab, but may replace larger parts of the commandline.*
Edit: formatting.
I like the 3 top uses.
As for questions, maybe when I write:
ffmpeg gui
I'll get a gui menu where I can select all the options, and that will generate a textual command for me that I could use further.
The hard part of course is creating GUI's for all the console apps.
Can that be done mechanically?
[1] https://github.com/chriskiehl/Gooey
This doesn't help when you want to map the fuzzy idea of performing a specific action to a particular existing program but it has helped me avoid having to search online for how to perform a particular task with ffmpeg.
[1] https://tldr.sh
However I think the tldrs need to be sorted better. When tldr git, the first example was
Shouldn't the tldrs show me how to add, commit, push? Who knows.I think the tldr lists should be interactive and allow you to select by pressing 1-9.
And maybe it should re-sort based on what you use most often, hehe.
So perhaps a suggestion could be to install tldr so as to be able to call a summary in your terminal without the need for web-access to cheat.sh
ffmpeg--resize-video video.mp4 50%
.bashrc:
You'll have added benefit that ffmpeg--<TAB> will suggest you only your own UI, without interference from the tool's own options.PowerShell does this, but PowerShell is mostly despised by Linux users on forums.
All the pre-Web UI patterns start to shine when you're working with more powerful software tools - where there are more than half-dozen available actions, so you can't just stuff them under a single hamburger list. You have to start categorizing, grouping actions by their commonalities. You can't sort by importance, because importance changes from minute to minute.
And menus of old were plenty discoverable. They weren't categorized for discoverability, because that's not the job of categorization. If you want to discover what the software can do, you spend 60 seconds expanding every single menu and reading available options. The categorization is there to introduce grouping concepts that are easy to remember, so that next time you're looking for an action you know (or suspect) exists, you know where to look for it.
Also, compared to the others you mentioned, hamburger menus are the most discoverable.
On a real UNIX like HP-UX, IRIX, Solaris, FreeBSD or illumos (and any of its distributions), you'd run catman -w as root only once for the lifetime of the system, then run:
and then you'd search for SEE ALSO with "/", eventually you'd run into df(1), under the very bad presumption that it isn't the first hit. ...on a real UNIX, manual pages are THE resource, they are very comprehensive because they were written by professional documentation departments, respectively professional technical writers in those departments working with the actual engineers who developed the software.The manual page system on a real UNIX is designed to locate exactly the type of information you would be looking for quickly, efficiently and most importantly, consistently.
It's GNU/Linux manual pages that are utter garbage, ergo switch to a system like SmartOS and never look back.
Yes, we get it, you hate Linux. Your user profile page says as much. Get over it.
I think that's more a design-problem than actual trait of GUIs. GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells.
> TUI/console is very good for interoperability/automation/muscle memory,
TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript.
> If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.
To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.
You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable.
My wife, for example, grew up before Windows 95 and its descendents were invented, holds multiple post-secondary degrees, and works with computers every day. She has no idea a second mouse button exists let alone that she can use it to perform file manipulation operations. She doesn't quite get the idea of "home directories" or "nested folders" or anything that is hidden like menus (or, frankly, tabs in the browser.. or multiple browser windows in fullscreen mode). Those things are not intuitive or discoverable in any way if you haven't been trained in their use. I, too, often forget the context menu is there although with practive I'm getting better. I certainly would never forget the `df` command though because it's second nature to me after over 40 years of use.
People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar.
Once you've figured out that mouse movements correspond to moving the pointer, clicking your left button usually means you want to do the primary interaction with whatever you're clicking on (opening a program, pressing a button, checking a checkbox), and right click gives you additional things you can do with the thing you're right clicking on, you've figured out enough to be able to at least use the system (I agree you're by no means proficient in it though).
To get comparable proficiency with a command line requires a much larger set of things to remember for even basic usage.
That is not the argument they made, they said right-click acts as a "tell me what I can do with this file" discoverability tool, not that right-click is itself discoverable. There is approximately no way to discover this on a command line, but if you right-click and "play with Windows Media Player" is there, it tells you something useful.
But I'm going to make the argument that it is discoverable. Why isn't the context menu second nature to you after over 25 years of use? You put your hand on the mouse, it has two buttons, you click one of them in ordinary operation, what kind of hyperbole is it to say that "clicking the second button does things" is "not discoverable in any way"? You discover that by accidentally mashing it one day, if nothing else.
it's easy because MS has spent years in formal user studies for almost every element of the 95 UI to make sure that it was easy for pretty much everyone.
Cosmetic differences in CLI applications are actually important to get them to work in the first place. dash vs double dash, equals sign or no equals sign. CLI parsing is completely nonstandardized. Each command reinvents parsing and is completely unpredictable.
The only way you could possibly solve this is by letting the shell parse CLI arguments and just pass them as a JSON like object to the application. The ship for that has sailed a long time ago.
Everything? Almost certainly not! That is the main problem with GUIs. The "everything" is defined by the programmer, not the user. Sometimes that works for you, sometimes it doesn't.
It's important not to confuse TUI with "console". TUIs are essentially the same as GUIs in this discussion. CLI (console) is completely different. CLIs use a language to describe what you need. To use an analogy, imagine ordering food in a restaurant. You could get away with pointing at the menu as long as you're happy with getting the default configuration. If you want to ask for no cheese, or less mayonnaise, you have to use language.
I think the main issues of usability are paradigm-independent—how do you make the UX more discoverable for text interfaces? How do you make the GUI more powerful and accessible to scripts? GUI development was introduced to make computers more tactile, and feel more life-like and accessible; and it works.
The reason Text-UIs work better for automation is that programming languages these days are text-based. How might one shift to a more graphical-programming paradigm? Machine learning I think has a lot of potential in this area and I would love to see some new work in this space.
No OOP language can have a search feature as useful as Hoogle:
https://hoogle.haskell.org/?hoogle=%5BMaybe+a%5D+-%3E+%5Ba%5...
"free space" doesn't turn it up, but on my system only turns up one result that obviously isn't it, no big loss.
"free" also doesn't turn it up, which seems like a missed opportunity. Going through the 40ish results before you're confident it's none of them is needlessly painful, but not crazy.
Both "disk" and "space" do turn it up, though, and also surface du (amongst about 50 other things).
I don't think scanning through <100 text items is clearly worse than digging through (say) the Windows control panel GUI.
~~~
I'd also note that TUI encompasses two kinds of thing - the utility in the shell (like df) and the captive interface that takes you away from your shell for an extended time as you navigate possible actions in some other manner. The latter has more of the benefits and drawbacks of a GUI.
~~~
In any case, I don't think your thesis is too far off, and I certainly welcome improvements to composability and discoverability across the board.
Shell scripting and pipes are the only times a command-line is better than a GUI.
Which isn't to say everyone needs to feel like I do. But some people at least will strongly disagree that the GUI is easier.
Regular users rarely type in commands. Either reverse search or zsh/fish/bash auto completion makes it much easier to run something in one two key strokes compared to few clicks in a GUI. Also switching to mouse from keyboard constantly slowes you down.
The inefficiency of mouse as interface is best illustrated in Excel which has power user shortcuts for every menu item. Expert users will never use the mouse if they can avoid it for the same reason. IDEs and many other apps work the same way.
Finally for developers who hav to work with servers, You don't have the luxury of working with GUI, you will have to learn these kind of commands anyway, using these locally on your desktop is more convenient.
1) I have an App - https://nocommandline.com - that is the opposite of this i.e. it says you should use a GUI instead of CLI (for a specific set of scenarios).
2) I'm not a 9-5 programmer even though I have a computing background
At a very high level - I generally disagree with 'you don't need a GUI' or 'CLI is better than a GUI'
At a nuanced level, I would say - it all depends. Sometimes CLI is much better than a GUI, other times it is the opposite. It all depends on what you are doing and who is doing what.
Software is all about automation and making life easier for you and/or others. If instead of having to remember a bunch of commands that I have to type, I can just click and get the same result, then click for me is better. It has made my life easier/simpler which is the essence of automation. GUI also becomes more useful for commands that you don't get to execute regularly. And GUI makes it easier for others to uptake the technology/learn it. Think about it - programmers tend to use IDEs to write their code and not notepad because IDE colors the text and so they know which are variables, restricted values, etc.
There is the argument that you can't automate GUIs. That is true in some contexts but in others, GUIs are usually built on top of the raw CLI commands so you have both worlds.
In other situations (and generally speaking), CLI is much more powerful because you have complete control of the 'innards' of the program. For such, I would say - yea, CLI all the way.
Windows of the 2000-2010 era; when business tools were desktop programs and they would generally have a GUI, probably hooked into MMC so they could manage remote computers as well, have .exes which took at least some command line arguments, have a COM automation interface, and have tools which use fairly standard Win32 GUI controls which could be changed or scraped for data interactively with third party programs like Sys Exporter and had decent support for keyboard navigation with system-wide patterns like accelerators and tab ordering.
Take Kaspersky AntiVirus management console, it has:
- a GUI, a standard MMC style with a treeview on the left and a web page on the right[1], which is approximately "every gui management tool of the era".
- Various CLI tools that will do things like "check connection from client to server" and "force update"[2]. (Although rarely will Windows tools like this have command line options for everything).
- Documented automation interface using COM with examples for VBScript and JScript, but which can be used by any COM-supporting language (which is most of them on Windows - PowerShell, Python, C#, Dyalog APL, Java,...) [3] where the documentation is in a help file that installs locally with it. The ubiquity of COM automation in the Windows world of yesteryear is way under-discussed in the "can't script GUIs".
- Backed by a database, with documented stable views for you to query for reporting and integration, and the documentation is in a locally installed help file.[4]
By no means is this the end-all be-all of the computing world, but people who say "I only use a CLI" are missing such a huge part of the computing experience, and people on Linux where GUI tools appear to be completely isolated islands disconnected from each other and from everything else and second-rate afterthoughts, are as well. It used to be almost the default in Windows world for tools to take Active Directory / single-sign-on logins, to have granular AD backed permissions, to be automatable with COM, and so on. Ropey, unstable, proprietary, but far more amenable to poking-inside than people typically give it credit for. And it's going with the rise of "why invest when we could take profit instead, why build for the long term when I'll be changing jobs in 18 months, why build a desktop app when we could build a subscription service" models.
And then in the modern day it's SaaS web applications which are their own proprietary, isolated, disconnected systems, maybe with a limited REST API locked behind a premium tier or a rate limit and everything with a limited result set because they can't let you overload their servers, and desktop programs becoming some UWP app-store isolated container, or some Electron tower, also isolated, and/or cross-platform compatible and isolated from the underlying OS and its models of doing things.
If a non-technical person can't use it, a non-programmer, it has no value as a user tool. If you can't auto-deploy 1,000 servers at the other end of a headless network connection, it has no value for scripting. I'm sure there's a use-case falling by the wayside, technical people who could and would script GUI tools together - not for automation, for interactive use, for exploration.
The amount of times I've put |gvim - at the end of a pipeline to load the results into Vim, but then they get stuck there. Only to be saved as a file, or run through a new shell launched from Vim or copy-pasted out. There's no way that I know of to do `ls -l | gvim - | mv ./old` for example; you can do it if you know in advance what commands to run then you can use Vim in headless mode.
My point is there could be a missing, under-explored computing mode, part-CLI and part-GUI.
[1] majkinetor ↗ > There is the argument that you can't automate GUIs
You generally can, and many times easier on Windows then any other OS. Accessibility OS features allow for that.
For example, Autohotkey is really great automation language for GUI and there is nothing like it on Linux world.
The only reason CLIs are still useful is because we still haven’t found a way to compose GUI applications well. We still can’t automate GUI applications, use the result of one app from another app etc... But that’s not something inherent to the GUI paradigm.
If you mean you can't automate a GUI entirely within a GUI paradigm, then you're closer to the truth, although Shortcuts -- and the third-party Mac utility Keyboard Maestro[1] -- are at least blurring the lines there.
I've used xdotool for that. A CLI-only tool ironically enough.
But filesystem stuff? Looking at lists of files, ordering them, copying and moving? That's exactly what GUIs are easily superior at. Especially when the files you're working with are some kind of media.
The problem is always the same. The "ugh" factor when I try to make the program do something I haven't made it do in a while. If code doesn't have a pretty front end for me to click on, I'll run it much less frequently.
(The second benefit, entirely unrelated to the article, is that it also allows me to make all my code incredibly fragile to bad inputs, right up until the point I make a GUI which is extremely fussy about inputs. Obviously, that could be done without the GUI, but it keeps me from spending to much time-- both in the sense of programming time and in the sense of run-time-- over-sanitizing inputs in the bulk of my code.)
Yes, I'm sure that's the reason MS Paint was created.
Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list.
The reason is simple: the brain can associate the GUI actions to many concepts from the real world. CLI concepts exist on computers and nowhere else. That knowledge is too abstract and too expensive to be kept unused in our brain's cache non-stop.
Generally, whether I'm making a CLI or a GUI, I establish contracts for display, input, and output. This at least allows for some albeit veritable consistency.
As someone who uses both GUI and CLI, and has taken month-long travels where I don't use a computer at all, I don't think this is true, at least for me. CLI is like a language; once you've really learned, it takes a long time to forget.
GUI layouts get moved around so you have to relearn where options are. In some cases, options get removed entirely in the name of 'user friendliness', whereas nobody's going to do that with CLI options.
I used to think I knew the Firefox layout (I've used it for more than 15 years), but now it takes longer to find things than what it used to.
Beside that, it still entails that you've to "wire your brain" so that it integrate the twisted specific ways they map on "the real world", with no guarantee that they won't change for external reasons, nor that there will be any sort of consistency across applications.
Sweet Jesus, the GUI lovers in this discussion really need to learn how to use computers.
I have a text file that includes several thousand commands that I have run during the past 20+ years. In one column there are the commands with placeholders, and in the other column there are descriptions of the commands. I have a shell function that provides this text file as input to fzf, and the shell function is bound to a key. I press the key, type a few words to find the command I want to run, press enter, and then the command is placed in the command prompt without the description. I can select any one of several thousand commands in 2-3 seconds because I type 120+ words per minute.
Don't get me wrong. I personally am a command line person too and I like your setup.
However, contrast:
> Right click and select menu option
with:
> In one column there are the commands with placeholders, and in the other column there are descriptions of the commands. I have a shell function that provides this text file as input to fzf, and the shell function is bound to a key. I press the key, type a few words to find the command I want to run, press enter, and then the command is placed in the command prompt without the description.
You are so incredibly out of touch with regular human beings.
Do you have any idea how obnoxious this comment is? I would love to have a discussion with you when you're 38 years old. I think you'll be amazed at how even your big impressive brain degrades, especially in memory.
Some peoples' brains (such as mine, I believe) are more wired to be symbolic. I suspect that, for these people, using a textual-command-oriented CLI interface is going to be noticeably easier/more intuitive than those whose brains are wired to be more visual/kinesthetic/whatever else there might be.
I don't think that it's very strongly weighted towards "transferability toward other real-world concepts". The modern GUI interface doesn't seem to share many characteristics with non-computer parts of the real world.
Naturally
Sometimes, you're in the terminal and something needs to be done quickly and knowing the correct command might be the best option. The author is merely trying to help people out with some useful commands for these instances.
I would, however, prefer that the author recommended using the interactive and verbose option for commands like `cp`, `mv` and `rm`, which I've personally found super helpful. Here's what I have in my `config.fish` (with a bonus for cp that preserves "mode, ownership and timestamps"):
alias rm="rm -iv"
alias mv="mv -iv"
alias cp="cp -piv"
> "they often require more resources"
I never had any resource issues with a file system manager, even on really old hardware. This line in particular feels very old school and nostalgic. Sometimes glitches happen if you're browsing a really large folder (thousands of files, very rare), but waiting a few minutes or using the filter textbox or switching to detail view (no thumbnails) usually takes care of it.
As a side note, the example is that of a Xerox station, and those were beasts of a machine back then with very expensive and powerful hardware specifically to demonstrate how powerful and fast GUI can be. Perhaps a gif of Pentium IV machine running Windows Vista would have been more reflective of what the author is talking about (sadly, those did actually exist back in the day, mostly running pirated copies of Windows Vista Ultimate).
> "are less powerful"
All the examples provided can be done with a single click on the UI. Granted the CLI can do more, but there isn't any example in this list of that nature. Even then, there are 3rd party plugins to any OS file manager that can do pretty much anything that isn't natively supported, at least for any major OS distributions.
> "automate via scripting"
I agree, albeit on Linux "dotnet run" [1] makes so much more sense over the bash code mentioned here, at least for anything that isn't a single one-off operation.
The File [2] class is an excellent example that makes for code that's readable even for someone who doesn't know anything about computers.
You can even do "dotnet run" on straight code, without having a file to execute. Of course aliasing it is the way to go if you'll do it regularly (dr? dnr? just d or just n?).
[1] https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-ru...
[2] https://docs.microsoft.com/en-us/dotnet/api/system.io.file?v...
[1]: https://www.alfredapp.com/
For example, say that I’m visualizing a 3D scene. Clicking and dragging in the viewfinder changes the perspective of the camera, so this is recorded in the log as something like:
If more GUI apps had exposed APIs, this would be a trivial feature to add.[0]: https://www.paraview.org/Wiki/ParaView_and_Python
Edit: others have mentioned AutoCAD too in this discussion:
https://news.ycombinator.com/item?id=26748281
https://news.ycombinator.com/item?id=26748700
It meant that instead of forcing me to screw around with novel terminology, novel design, and how those relate to a bunch of CLI commands, I could just:
1. Open a window
2. Be presented with a very friendly UI that stepped me through the process of creating a wallet and preparing my machine to mine.
3. Follow the easy to read instructions, without running into any error or any warnings whatsoever.
4. See the message that given my stock setup it would take me approximately 2 months to mine a coin.
5. Immediately uninstall the app.
If I had been forced to use CLI that would have taken me probably another ten minutes, for no gain.
1. Drag and Drop
2. Right clicking
3. Ctrl-C and Ctrl-V
So these 3-5 things do everything in the list in a GUI, and instead the author wants us to learn 35 different command/syntax combinations?
As an aside, I'd like to write an article saying "You Don't Need Github To Write an Article". If you insist on using Github for that purpose, at least do it properly with a static site generator.
[1] Did not bother with the rest.
You don't even need a static site generator. GitHub Pages uses Jekyll behind the scenes, so it converts your markdown to HTML for you. You can even select from a list of themes from the GitHub UI.
Still, the author might not know this.
You think he's being serious?
I, a developer, spend the majority of my time between IDE and terminal. I am most efficient if my hands do not leave the keyboard.
My business partner, not a developer, but a savvy user, but is pure GUI with the addition of some browser automation and various extensions. He is impressively productive.
It is all about what works for an individual user. I appreciate this post, because I’m a keyboard-focused user. Looking forward to reading it more thoroughly.
PS: One thing where a GUI really shines is picking a bunch of files from a folder and moving them elsewhere, based on a manual criterium that isn't easily identified by a wildcard. For instance, from a folder of documents pick all the ones related to a certain topic. A GUI shines for this, commandline is horrible for it. If I don't have a GUI available I will use mc for this.
However for other tasks, the commandline is gold. Finding all JPGs in a huge tree of folders and moving them all to one central folder. Easily accomplished with 'find -exec'. Very much work to do in GUI with default platform tools, usually you'd have to download some utility to do this.
So, for me they are both great options with their strengths and weaknesses. They complement each other. A good operator should be aware of both.
To expand on your example: for a lot of readers of HN, moving all JPGs in a bunch of folders is going to be easier and faster with a CLI. But for <non-technical person in your life> who needs to do it very rarely, it's probably still going to be faster for them to navigate folder-by-folder in a file explorer, sort by file type, shift+select, repeat, than it is to learn how to use CLI to do it.
For technical people, GUIs also reduce burden, and let us be lazy. I "know" (or at least once did) how to configure Samba by hand, but for the last many years I've run OpenMediaVault at home and use the UI to do it for me. I don't use Samba for anything else in my life or work, so why do I want to remember or even spend the time reading the manual when I need to make a change to it once a year or so? I'd rather just log into the UI, click a few things, and be done. Nothing to actually remember, as the GUI gives me enough information to figure it out as I go.
I spend a lot of effort to be lazy. If I was regularly moving JPGs out of a folder, I'd probably go further and write a shell script or alias, or even just make a cron job to do it for me; likewise I'm happy to install/use a GUI app for certain things if it means I save time vs reading man pages or having to remember arcane commands I rarely use.
That's easy in Windows File Explorer. Type Ctrl+F, then *.jpg, then Enter. Wait for the search to finish. Type Ctrl+A to Select All, then Ctrl+X to Cut. Then go to the target folder, in the same or a different File Explorer, and Ctrl+V to Paste.
Someone who isn't familiar with the keyboard shortcuts can do the same with the mouse. Either way, if they have ever edited a document and done something similar with cutting and pasting text, there is nothing new to learn except understanding that the same steps work in File Explorer.
It also works in the default file manager in Ubuntu with minor changes: don't hit Enter after typing the search text, do click in the result list before the Ctrl+A.