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.
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.
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.
> 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. :)
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"
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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.
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.
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.
>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.
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.
> 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.
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.
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.
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....
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.
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.
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.*
'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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
> 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.
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.
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.
"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.
> 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.
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.
I think this is because of the "default" behaviour pattern. You can rightclick or do a context click on the most systems. Even on smartphones you can hold your finger on the file to get a context menue. This is not the case for cli. There is not global pattern like "context file" or "options file" that works on every cli. There are not a lot of easy common patterns in the cli world. Even for autocomplete you have to change the default shell on the popular systems.
> 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:
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.
> 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
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.
> 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.
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.
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).
I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation. Nothing will ever beat the right-clicks or Ctrl+C/Ctrl+V combos. It's just more natural to "see" things that you move.
Now when it comes to more complex applications, I'd stop using the CLI if I had to search the manpages or the internet each time for doing something I already did previously.
Since I discovered the Ctrl+R shortcut (for searching your history), it has been much easier. You read the manpage once, maybe you do an internet search, you enter the command and then you can find it back as long as it's still in your bash history (be sure to set HISTSIZE and HISTFILESIZE to correct values). I also have a DOCS.txt file where I put all the rare but useful commands I'm afraid of losing. I don't need to be an expert in ffmpeg's options (... though I sort of am now), I can just look at my history or my DOCS.txt file!
> I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation. Nothing will ever beat the right-clicks or Ctrl+C/Ctrl+V combos. It's just more natural to "see" things than you move.
I've been using a Mac full-time for the last 8 years, and I do the vast majority of file manipulation in Terminal instead of Finder, because I find the command line easier and more intuitive.
That might be more because finder is so bad and less to do with file management GUIs in general. Windows Explorer and Nautilus are both much better than finder.
Imagine using Windows Explorer...
Right Click -> New Folder
Choosing the files you want to move there -> CTRL+C -> Going into the directory -> CTRL+V
Yeah that’s just the best and most efficient way to move files into a new directory.
Windows Explorer is terrible. I used Norton Commander>windows commander>total commander>double commander my whole life. It's as fast as your keyboard gets. I cringe when I see people navigating files I'm Explorer.
> I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation. Nothing will ever beat the right-clicks or Ctrl+C/Ctrl+V combos. It's just more natural to "see" things that you move.
This might be the case for you, but please don’t mistake it for an objective truth. I find the terminal far superior for file manipulation than any of the graphical file explorers I have used. I especially find copying quite clumsy, as I either have to open several windows and navigate to the correct locations, or leave the source folder behind as I navigate to the destination. In my terminal I can stay in the source folder if I want to, and even navigate directly to the destination with a short, generic command.
I think this article might be satire because it spends so much time on files. Either that or it was written in 1992.
How many users have an iPhone or iPad as their primary computer? How often are they manipulating files?
Where's the "you don't need a gui" entry for making phone calls, sending messages, playing music, using GPS, etc... While you can certainly do all those things by command line, few people would argue it's a better experience.
Objectively nothing beats software such as Midnight Commander, Krusader, Total Commander,... for file manipulation. You can do common operations with single clicks or shortcuts and they also have the shell integrated for less common operations.
Come on. Those are three separate actions of which the last one is to "confirm" the deletion in a modal dialoge. Hardly the same as one command in the CLI.
Also if that would really happen, you can go into the trash folder and restore the items. AND of course that would only affect the current directory whereas `rm -rf ~` is a different story.
> It's just more natural to "see" things that you move.
This is the fallacy of logos.
When I was learning about files and filesystems, the GUI had not even been invented. It is certainly not natural to me to conceive of file operations as cartoons moving around on a TV screen.
What's happening here is you're mistaking what you may have first learned for what is normal or natural. That it seems normal or natural to you is an inherent property of your experience, not an inherent property of file manipulation.
I get their point, though. It's less about seeing the animation of the move, and more about seeing state. Seeing state you're manipulating is helpful. CLIs, being naturally line-oriented, don't give you that.
Myself, I do a lot of file management in Emacs these days. Dired - Emacs folder viewer - essentially turns output of `ls` into interactive folder listing, that you can manipulate the way you'd use an orthodox file manager like Norton Commander or Midnight Commander, but that you can also just edit as text and have Emacs apply changes to the file system. To kind of boost your point about "normal" being learnable, it's absolutely normal for me now to expect to be able to rename files or change permissions by editing output of `ls`.
When I say "naturally" I'm talking about the way we, as humans, naturally interact with our environment. Sight may be the most important of our senses. We don't give orders to physical objects when we want to move them. I guess that's why we call files, well, "files".
Now, as others have pointed out, when it comes to specific operations involving redundant tasks, it's obviously easier to use CLI (`rename JPG jpg *.JPG`, etc.) (though in the case of mass renaming, it's less confusing to use Thunar's Rename right-click option).
I get what you're saying but I think it depends on what sort of file manipulation you need. When I'm trying to get a large set of images renamed from e.g. IMG_NNNNNN.jpg format into sequential zero-padded numerals for use with ffmpeg I personally appreciate the option to do it with a bash one-liner rather than using the mouse in a GUI.
> I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation.
In the old days you used Norton Commander for that, which ran in text mode. I'm sure there must be some open source equivalents today which run in the terminal.
For some strange reason I have a GUI (nautilus), TUI (mc) and CLI (fish) at my disposal... but I do lots of file manipulation at CLI. Nothing will ever beat `massren` with the power of `vim`.
(But no kidding: somethings feels CLI very natural, sometimes feels GUI more natural for me.)
FWIW, `massren` + vim (or dired in Emacs) is TUI, not CLI. GP's point absolutely applies to pure CLI - operating on files by directly invoking mv, cp, ln, etc.
It depends on the context. For the purpose of this subthread, TUIs belong with GUIs, as both show you current state, make it interactive, and render a 2D view. In contrast, CLI tools only print out a snapshot of the current state (i.e. the output becomes stale as soon as it hits the TTY), and that snapshot is non-interactive.
In other contexts, you'd group CLIs and TUIs together. For example, both can be used from a terminal emulator, both are easy to use over SSH connection, and (an underappreciated feature) in both CLI and TUI apps, it's easy to just copy what they show as text.
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.
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).
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.
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.
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.
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
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).
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.
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 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.
> 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."
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.
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]
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 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.
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 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.
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.
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.
"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.
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.
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].
Even with the very good zsh autocompletion, I'd definitely be faster with a GUI in practice, if only because my file manager has thumbnails and preview and it's impossible to remember which file is which without glancing at it if you want to copy it
anyways, this repo is big elitist bullshit which reads like it was written by edgy teenagers who just discovered bash
Also cp will silently overwrite existing files (unless it's aliased to cp -i), while if you were using a GUI you'd get `(1)` appended to the filename, that while not very helpful, doesn't cause DATA LOSS when you don't know your way around the shell.
Agreed, it's written by an edgy teenager and I'm not sure who's the audience.
I agree, the STOP <GUI OPERATION> messages really trigger me. And the repo has 2.7k stars. But on the other hand, it's a very good resource to look up and discover some CLI commands that you didn't know already.
> either those file names mean something and you don't have to look at the thumbnail or you should use a better naming convention...
I mean, they certainly mean something, but I just downloaded them and I have no idea what (and definitely not the time to rename them to put human readable information in their name)
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.
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).
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.
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.
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.
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)
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.
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.
> 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.
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.
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.
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.
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".
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.
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.
It misses the point of: "How did I get to the place where the "readme.md" file is ? How did I know I wanted to put it in `documents/` ?
I'd argue that this is not what most users are really doing is.
A real-life scenario is:
1. I need to send a file to Bob. Where the hell is that file ? I think it's in the "Files" directory. No wait, is it in "Documents". Oh, ok, it's in "Project X254/Documents/Files/Revision0/VersionB".
2. Right-Click on Icon, Click Copy.
3. Where the hell do I need to put it, again ? Ah, ok, I need to put it in "Windows Share/Shared/Team/Multiple/Document/Files/Next Very Important Meeting"
4. Right-Click on Icon, Click Paste.
Using a CLI does not make steps 1 or 3 easier ; it makes step 2 and 4 unbearable (because you have to type _names_ right, and _names_ written by human beings are hard.)
One of my favourite snippets of bashrc code for navigating directories below. Whether it beats navigating with a file explorer is up to you but I drastically prefer it.
<code>
export MARKPATH=$HOME/.marks
function jump {
cd -P "$MARKPATH/$1" 2>/dev/null || echo "No such mark:
You don't have to type the names, you only need the first character + tab. To me that's much faster than reading through a list of folders trying to find and click the right one.
In case one of those folders only contain one other folder, you don't even have to type the first character, just tab+tab+tab done.
Graphical file managers can also select a file by typing the first few characters of its name (type-ahead)*. In case there's only one item, just press the down-arrow key to select it. One can navigate a GUI just like CLIs, just with slightly different keys, but with the added benefits of visualization and mouse actions such as drag-and-drop.
Edit:
* Unless you're using GNOME's Nautilus, which I think will stupidly trigger a recursive search instead.
GUI can work across multiple windows/contexts while CLI commands are bound to just one context.
For instance:
I can open two file browsers in different directories and simply drag and drop a file from one to the other.
But there is no command (AFAIK) that allows you to copy a file from the current working directory of one terminal session to another. If for instance tmux or some other terminal emulator would allow something like:
cp file.txt <<other-sessions-id>>/file.txt
to copy from one window to the next, that would be useful.
On linux you could sort of write a script for that, which uses the pid and gets the cwd from /proc/<<pid>>/cwd.
Indeed; the "don't ctrl+c/ctrl-v" copy files ignores the fact that you can copy to different windows - but they don't even need to be file browsers, you can copy files over RDP sessions or sometimes into/out of virtual machines, or sometimes into web browser pages for file upload, or in the middle of a standard Win32 "file open" or "file save as" browse dialog, or in a VMware thick-client datastore browser, or in a 7-Zip view on a compressed archive, or in a ton of different common GUI software like FTP clients and etc. etc.
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.
Not everyone is spending most of their time in a terminal already.
I'm not going to context switch to a terminal and move my hand off my mouse just to be able to type a command that I could have issued with a couple of mouse clicks in the window I'm already in.
If I'm already on the command line, yeah. I'll probably do more stuff in the command line. I just hate to switch input modalities to feel like I'm being more efficient doing stuff that makes up so little of my actual work (coming up with ideas and solving problems).
Does anyone still use Midnight commander? (mc from the command line). I think its falling out of favor, but I think a lot of people don't know about it.
Its a clone or the old Norton Commander which uses a termnal (curses based software) to create a kind of file browsing /copying/ moving tool. I like it because I know it, and its easy to browse through directories and veiw the files using a keyboard.
It also has a built in editor that behaves like old the DOS text editors from qbasic / Turbo Pascal. I think it's more intuitive than nano, especially for Windows users.
Oh for FFS, this is ridiculous. If it was April 1, I'd think it was like that artisanal hand written code post. YOU may not need a GUI, but my 92 year old dad sure does.
Reading this, my first thought was, "You don't need to buy a house" followed by a lot of tips on carpentry.
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.
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 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.)
I mostly agree with the article but there are some important considerations missing:
* Parallelization - It requires far less effort to perform parallel jobs from the same application instance in a GUI. This is entirely resultant from the APIs and interface provided by a given application more than the environment in which that application runs.
* Security - It is possible for a GUI to provide additional security controls and context not readily available to a terminal interface. This point, though, is extremely narrow in context, not guaranteed, and may likely introduce additional compromise vectors.
* Performance - In most cases and with more traditional technologies it is a generally safe assumption that GUIs require more resources than terminal interfaces. That performance gap closes as technologies become higher level (further from the metal) and more distributed across different physical devices.
* Scripting and Automation - It took considerable effort but I have managed to achieve mostly parity and some automation superiority in a GUI versus the terminal in a personal application. This point on automation is entirely dependent upon the APIs and data structures provided by a lower level system.
I just love CLI apps due to the sheer power they provide me and for composability. But every time I do any file operation I still get a tiny bit anxious. Did I mistype anything? Will some of my files get overwritten? Things like that. Compare `cp` on a brand new machine without aliases and colours with something like copy resolution dialog in DoubleCommander or `rsync --help` with the interface of the FreeFileSync, which provide copious amounts of feedback (or feedforward).
It's just a silly preposition. We need both and we'll definitely get use of the new ways too, if they ever come.
One thing that really annoys me about the GUI mindset is that developers think it's ok to just change stuff. With CLIs they expect people are using it for automation so changes are done with care. Often when I update my GUI I have to look for info in different places, click somewhere new, or learn new shortcuts. That sucks
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.
Each of these have trade-offs. Any assertions like "you don't need X" might be good for website traffic, but does not help steer the discussion on how to best serve the user.
Taking disk usage as an example, sure a quick 'df' is nice. But I do enjoy the extra power and discoverability of graphical disk usage analyzer tools. Both the CLI and GUI tools require a library.
I am not going to debate this topic, but one thing I will say is that I constantly think about how ridiculously long it takes to make a GUI application compared to a CLI application. It takes at least 10x as long. Large companies can just hire more people, but as a single full-stack person, I just hate the fact that I could make 10 CLI applications in the same amount of time as I could make 1 GUI application.
I don't really like bc. Just seems so old-school, and typing things like "100.0 / 34.2" gives you "2". Is there really nothing better? I feel like someone has to have made some new hotness in Rust by now.
I don't know if it's satire, but I can't take this article seriously. The command line, for me, isn't about doing things the hard way. Nor is is necessarily the easy way either. It's an alternate interface which has some strengths.
What is compelling about the command line is how it can be it's own ecosystem and it's possible to use most of the features of a computer within this constrained environment.
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.
I love using the terminal (fish shell, grep, find, mdfind, sed, etc etc). I also love using GUI applications such as Preview, Google Chrome, 1Password, Finder. And Emacs, not the least.
If you've never done it before, I highly recommend writing a single program with multiple front ends: GUI, TUI, CLI, API. Wrap them up in multiple interfaces: for GUI, make a web-version, a desktop version, a tablet version, a smartphone version, etc. And do it in as many toolkits as possible.
At first, you'll want to keep the program simple. My first time doing it, I made a super simple "simulation" of a fish tank. The fish just moved at random. They'd sure if you didn't feed them regularly. That's about it.
It's a highly beneficial learning experience. You get the case functionality done, and then you start implementing new features. And you start to see all the ways in which one format falls and another picks up.
Definitely try to share as much code as possible between them all. Really forces you to separate concerns.
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).
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"):
After reading the headline I was hoping this post would shine a light on how gui’s hide the functions and steps a computer takes, and how this abstraction creates an image of computing as something extraordinarily complex, and how that’s a great loss for society as many people don’t learn about the basic building blocks of computing and computers, and how we are all the pooper for this development (which alienates a great deal of people due to the break-neck speed of modern society).
Please can we talk about that instead? I am not so interested read a list of actions which this author believes are superior to be performed using the CLI.
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.
This is an outdated guide. Most of the tools here are genuinely poor replacements for their GUI counterparts. However, there are many alternatives superior to their GUI versions.
If you want something better than Activity Monitor– tells you what (which process?) is lagging your computer, and how (RAM, CPU, or swap?)– with an overall slicker interface, try:
glances
If you want something better than weather.com– no ads, fast loading– try:
curl wttr.in
Better than spotlight– full-text search over 128GB drive in less than 30s– try:
rg "query"
Force quit a program, try:
pkill -9 ProgramName
Suspend a program and un-suspend it later, try:
pkill -STOP ProgramName
pkill -CONT ProgramName
View content of a file with syntax highlighting, try:
bat file.py
Open a file and copy it to your clipboard, try:
cat image.png | pbcopy
Go to a recently visited folder with autocomplete that works reliably, try:
z foldername
Convert units– faster than typing into Google, try:
Why is it that we're so much better at consistency in GUIs than programs? We all know ctrl+c/cmd+v and friends. We all know right click. We all know where preferences tends to live and what people are likely to put under the file or edit dropdowns. Compare that to learning new non-GUI tools (shell or libraries), and you start from square one. The only thing I can think of that's universal is "--help"
Possibly because programmers have a higher tolerance for learning new, inconsistent (CLI) interfaces, partially because they're anticipating future rewards (greater efficiency, flexibility, job market, etc).
Meanwhile, new and inconsistent GUI interfaces tend to drive away non-programmer users...which results in a competitor eating your lunch.
The biggest impetus to avoid using the GUI in my experience is when you are tired of doing the same damn steps you do everyday and want to automate it. Once you reach that stage, telling you so is preaching to the converted and then it becomes a matter of whether the actions you do on the GUI can be replaced by a series of commands that can be invoked programmatically. If they can't be, you do need _that_ GUI.
Misses the point. I read a lot of these and tried the alternatives, and I can say that the alternatives require more mental energy to use and don't save appreciable time, so I won't use them. I've only got so much RAM, and the GUI makes information extremely easy to digest. People say "STOP using Twitter, use IRC" but those people also miss the point.
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.
I moved an old GUI based program over to a new system built on simple text menus and letting the user type in a basic subset of commands. At first there was resistance but after a couple of days of using it and some emails the engineers used it loved it because they could do all the stuff they used to do with mouse clicks with their keyboard, most said at least 2 times as fast. So the up front usage wasn't as nice as a GUI but since it is used often a bit muscle memory typing and not having to look anywhere but the screen and everyone but one person loved it. I think he'll come around. BTW, I'm not a GUI programmer, I've done a few but they're always ugly and I tend to like backend much more :) . Hence I chose an old fashioned text version. It's not pretty but it's much more efficient. Yeah I know this isn't for all use cases but in mine I felt it was the better choice.
I avoid using the terminal because it's just too easy to loose data. There are tons of commands that overwrite files, delete whole directories, or even overwrite blocks on the disk, and very few of them allow for simulation and delayed execution like e.g. GParted does. You always have to triple check to not shoot yourself in the foot.
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.)
> they often require more resources, are less powerful and hard to automate via scripting
That's not a problem with the GUI paradigm, that's a problem with the current implementations of it.
Current implementations of CLI/TUI programs have many problems themselves: lack of undo, poor discoverability, low intuitiveness, no previewing (e.g. in the equivalent to file browsers), poor documentation (which makes the discoverability and intuitiveness problems worse), and so on.
Moreover, with that context,
> require more resources
...is a very poor reason to use them. Computers are meant to be useful, not to sit there saving compute/RAM/electricity.
(I shouldn't have to add this here, but: obviously, if you have two identical tools but for the fact that one consumes less power, then of course I would say you should use the latter one - this is not that scenario)
Any tool that is meant to be so low-level as to not come with undo should be a library, not a command shell that can (and is expected to be) used by non-technical users.
But the examples given doesn't really convince me. Using Finder to move files from a folder to another takes less time than using the CLI, especially if the files you're moving doesn't have anything in common at all and you don't want to move all of it.
Surprisingly negative reaction to this. From the OP:
> As a computer expert, we want to be more efficient and do our jobs better. We know that command words may not be easily discoverable or mnemonic, so we try to list some common tasks that you might be tempted to do in GUI.
The target audience is software engineers. And they are right. If you're a dev, you should become comfortable at the command line. It really is far faster and more efficient for the sort of tasks we do. If your mom wants to browse through image thumbnails, let her use the gui. If you want to manipulate data files, use the command line. The responses here indicate surprisingly few of us have to work with large amounts of file data.
I think autocomplete is still in the early phase of evolution.
The problem with the CLI is it is TOO freeform, with fatfingers and the like. A better autocomplete that utilized more advanced character graphics would go a long way to making the CLI more natural.
Man page examples/sample are still inadequate even after ... ??? 40 years ???. Some analysis of grep use case frequency would probably help them a lot. I've given up looking for man pages for examples how to use a command in a specific way, StackOverflow and Google are better. But then you have to change to a different app, parse through search results, etc etc etc.
Nice selection of cli-fu. But I can't see a 'take and share a selfie with all my friends' or 'play music similar to what I'm listening to now' pipelines. Is it too lame or too tough for CLI?
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.
You don’t _need_ a GUI, but if you ever want your program to be used by people who don’t know how to use the command line, i.e. most people, then, in reality, yes you do
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 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?).
I really love how well macOS does both GUI and TUI. I can easily switch from terminal to Finder (open .) to browse files in a GUI, back to terminal (drag folder on terminal.app). Also almost everything in the system preferences has a terminal counterpart, things like network settings and such.
As a mechanical engineer:
- I wish we would use git like our software friends
- I wish commercial CAD programs had humane file formats and command line interoperability
- I wish commercial CAD programs would be supported on Linux
- You can pry MS Excel from my cold dead hands.
I still don't understand why I'd use the command line for git at least. Using a visual tool like Sourcetree I can easily see my staged/unchanged changes, the outstanding commits to pull/push of all my branches at a glance without typing anything.
I can easily fetch/pull/push/merge and switch between branches with a click, which is much faster than typing git commands and branch names. I can back merge/rebase changes basically do anything way faster than someone typing in a ton of text to do the same thing.
Plus I can get the same situational awareness across all my repos by just clicking through some tabs. No directory change commands or any further git commands to see the state of things. I feel like I have a better situation awareness, am much faster, and haven't had to type a git command in a long time. I work on a team of many developers who use the CLI and I still don't understand the appeal.
With a good CLI setup good speed can be achieved. For example ZSH with the Git plugin from Oh My Zsh and history based autocompletion with arrow up gives you super speed. I rarely type more than a few characters for all my regular operations, including auto completing all branch names and origins.
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.
Advocating for GUI tools is all fun and games until a design or marketing guy decides they know what's good for you better than you and moves everything into more inconvenient places.
Yes, hamburger menus, CSDs, all of you, I'm looking at you.
g.u.i. is a buzzword I know not of what it means and it seems fairly useless and bereft of any actual technical definition. I know what a c.l.i. is and what it is not, and I also know that the two are not exclusives, and where the border of what is and isn't a g.u.i. lies is very vague.
I'm fairly certain that the console I summoned in Counter Strike when I was younger qualified as both a command line interface and a graphical user interface.
When discussions use such ill-defined terms, I smell the stench of social tribalism more than anything.
All well and good until you try one of these commands only to be told you don't have permission. Uh oh, now you're down the rabbit hole when all you really wanted to do was copy a file :)
with thinkpad keyboards you can control the cursor very quickly without having to move your hand off the keyboard at all.
i wonder sometimes if trackpoints were standard in every keyboard would this whole gui vs cli argument be much less of an issue.
it's definitely very inefficient having to move your hand to a mouse to do something, then back to the keyboard and find the home row position again. moving the cursor with a trackpoint only requires you to move your index finger to the side so a lot of things become much quicker than typing any command
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.
GUIs are very useful for non-verbal animals, and for young children and heavily handicapped humans who cannot use language. For normal, well-functioning adults with a command of language, text or voice-based interfaces will always be superior: they are both faster and more expressive.
GUIs are very useful for people who can read, because they have text in them. Even without text, "crop a photo until it looks nice" is no task for a command line or for language.
But then again, "crop these two hundred photos to remove the white margin", certainly is. It would be extremely painful to do so without the command line.
Some of us are such nerds, that we even crop a single photo with command line utils. Something like this:
imcrop `imrectangle in.png` in.png out.png
where imrectangle is a program that opens the image in a window and allows you to select a rectangle, whose coordinates are printed to stdout upon closing the window. You can even put this line on a shell script that you can call as
viscrop in.png out.png
and does the whole deed. With some care, it can even work on pipes:
Yes, you don't need a GUI to run and do programs. But it is essential for the masses. For a guy who has no background in computers, running a program without a GUI would be hard.
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.