You Don't Need a GUI

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&#x27;s bad for composing programs and interoperability, often it&#x27;s impossible or very hard to automate (how many people are doing UI testing? there is a good reason it&#x27;s not many -- it completely sucks)<p>TUI&#x2F;console is very good for interoperability&#x2F;automation&#x2F;muscle memory, but doing one-off things is harder. If I don&#x27;t remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn&#x27;t as fuzzy (e.g. `man -K &quot;free space&quot;` isn&#x27;t very fruitful). In comparison, I know that if I start going through GUI, eventually I&#x27;ll eventually find the free disk space info.<p>It&#x27;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&#x27;s a simple dataclass, I&#x27;d need to search through code to find how I can use it. Might be a too far fetched analogy though.<p>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&#x27;t have to make a hard choice and can gradually move into the direction you want.

I&#x27;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&#x2F;Ctrl+V combos. It&#x27;s just more natural to &quot;see&quot; things that you move.<p>Now when it comes to more complex applications, I&#x27;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&#x27;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&#x27;m afraid of losing. I don&#x27;t need to be an expert in ffmpeg&#x27;s options (... though I sort of am now), I can just look at my history or my DOCS.txt file!

As much as I like the command line, I couldn&#x27;t help noticing from the first 10 or so entries[1] that the &quot;stop&quot; text consists of one of:<p>1. Drag and Drop<p>2. Right clicking<p>3. Ctrl-C and Ctrl-V<p>So these 3-5 things do everything in the list in a GUI, and instead the author wants us to learn 35 different command&#x2F;syntax combinations?<p>As an aside, I&#x27;d like to write an article saying &quot;You Don&#x27;t Need Github To Write an Article&quot;. If you insist on using Github for that purpose, at least do it properly with a static site generator.<p>[1] Did not bother with the rest.

Most the things in this list are things that you technically don&#x27;t need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you <i>could</i> do all those file operations in the terminal, but chances are you&#x27;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&#x27;t handle, or you need some sort of automation (ie. programming).

&gt; $ cp readme.txt documents&#x2F;<p>sure, works fine<p>in my ~, I have the follwing files:<p>&#x27;FOPC_0211237F_4563(1).pdf&#x27;<p>FOPC_0211237F_4563.pdf<p>FOPC_0251215K_4563.pdf<p>FOPC_0381912X_4143.pdf<p>FOPC_0381912X_4154.pdf<p>FOPC_0755890V_282.pdf<p>FOPC_0755890V_283.pdf<p>FOPC_0755890V_284.pdf<p>FOPC_0755890V_285.pdf<p>FOPC_0755890V_286.pdf<p>FOPC_0921204J_4652.pdf<p>FOPC_0952259P_58.pdf<p>FOPC_9830445S_4142.pdf<p>Even with the very good zsh autocompletion, I&#x27;d definitely be faster with a GUI in practice, if only because my file manager has thumbnails and preview and it&#x27;s impossible to remember which file is which without glancing at it if you want to copy it<p>anyways, this repo is big elitist bullshit which reads like it was written by edgy teenagers who just discovered bash

Once learned the GUI actions are impossible to forget.<p>Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author&#x27;s list.<p>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&#x27;s cache non-stop.

I think this document is a bit too belligerent. &quot;STOP DOING xxx&quot;. 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&#x27;t force others to do so. Educating them how (if they&#x27;re interested) is a great thing. Making it sound like they&#x27;re doing it wrong is not.<p>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&#x27;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&#x27;t have a GUI available I will use mc for this.<p>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 &#x27;find -exec&#x27;. Very much work to do in GUI with default platform tools, usually you&#x27;d have to download some utility to do this.<p>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.

This is terrific.<p>But...<p>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.<p>And, almost none of these work in the Windows command prompt. I&#x27;ve tried powershell and while there are some great ideas, nothing behaves as I would expect after using bash for 20+ years.<p>These are the reasons people use the GUI. Without acknowledgement of that, this readme loses some of it&#x27;s lustre.

Full disclosures:<p>1) I have an App - <a href="https:&#x2F;&#x2F;nocommandline.com" rel="nofollow">https:&#x2F;&#x2F;nocommandline.com</a> - that is the opposite of this i.e. it says you should use a GUI instead of CLI (for a specific set of scenarios).<p>2) I&#x27;m not a 9-5 programmer even though I have a computing background<p>At a very high level - I generally disagree with &#x27;you don&#x27;t need a GUI&#x27; or &#x27;CLI is better than a GUI&#x27;<p>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.<p>Software is all about automation and making life easier for you and&#x2F;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&#x2F;simpler which is the essence of automation. GUI also becomes more useful for commands that you don&#x27;t get to execute regularly. And GUI makes it easier for others to uptake the technology&#x2F;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.<p>There is the argument that you can&#x27;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.<p>In other situations (and generally speaking), CLI is much more powerful because you have complete control of the &#x27;innards&#x27; of the program. For such, I would say - yea, CLI all the way.

I have a problem with the very first entry:<p>``` cp readme.md documents&#x2F; ```<p>It misses the point of: &quot;How did I get to the place where the &quot;readme.md&quot; file is ? How did I know I wanted to put it in `documents&#x2F;` ?<p>I&#x27;d argue that this is <i>not</i> what most users are really doing is.<p>A real-life scenario is:<p>1. I need to send a file to Bob. Where the hell is that file ? I think it&#x27;s in the &quot;Files&quot; directory. No wait, is it in &quot;Documents&quot;. Oh, ok, it&#x27;s in &quot;Project X254&#x2F;Documents&#x2F;Files&#x2F;Revision0&#x2F;VersionB&quot;. 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 &quot;Windows Share&#x2F;Shared&#x2F;Team&#x2F;Multiple&#x2F;Document&#x2F;Files&#x2F;Next Very Important Meeting&quot; 4. Right-Click on Icon, Click Paste.<p>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.)

GUI can work across multiple windows&#x2F;contexts while CLI commands are bound to just one context.<p>For instance:<p>I can open two file browsers in different directories and simply drag and drop a file from one to the other.<p>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:<p><pre><code> cp file.txt &lt;&lt;other-sessions-id&gt;&gt;&#x2F;file.txt </code></pre> to copy from one window to the next, that would be useful.<p>On linux you could sort of write a script for that, which uses the pid and gets the cwd from &#x2F;proc&#x2F;&lt;&lt;pid&gt;&gt;&#x2F;cwd.

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

Not everyone is spending most of their time in a terminal already.<p>I&#x27;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&#x27;m already in.<p>If I&#x27;m already on the command line, yeah. I&#x27;ll probably do more stuff in the command line. I just hate to switch input modalities to feel like I&#x27;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&#x27;t know about it.<p>Its a clone or the old Norton Commander which uses a termnal (curses based software) to create a kind of file browsing &#x2F;copying&#x2F; moving tool. I like it because I know it, and its easy to browse through directories and veiw the files using a keyboard.<p>A breif guide with some screenshots: <a href="https:&#x2F;&#x2F;www.linode.com&#x2F;docs&#x2F;guides&#x2F;how-to-install-midnight-commander&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.linode.com&#x2F;docs&#x2F;guides&#x2F;how-to-install-midnight-c...</a>

Oh for FFS, this is ridiculous. If it was April 1, I&#x27;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.<p>Reading this, my first thought was, &quot;You don&#x27;t need to buy a house&quot; 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...<p>The only reason CLIs are still useful is because we still haven’t found a way to compose GUI applications well. We still can’t automate GUI applications, use the result of one app from another app etc... But that’s not something inherent to the GUI paradigm.

I mostly agree with the article but there are some important considerations missing:<p>* 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.<p>* 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.<p>* 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.<p>* 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 <i>love</i> 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).<p>It&#x27;s just a silly preposition. We need both and we&#x27;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&#x27;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 <i>incredibly</i> 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.<p>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:<p>1. Open a window<p>2. Be presented with a <i>very</i> friendly UI that stepped me through the process of creating a wallet and preparing my machine to mine.<p>3. Follow the easy to read instructions, without running into any error or any warnings whatsoever.<p>4. See the message that given my stock setup it would take me approximately 2 months to mine a coin.<p>5. Immediately uninstall the app.<p>If I had been forced to use CLI that would have taken me probably another ten minutes, for no gain.

Whatever became of nuances ...<p>I thought this discussion was settled. You need to expose functionality via:<p>1. A library 2. A CLI 3. A TUI 4. A GUI<p>NetworkManager is a good example: <a href="https:&#x2F;&#x2F;wiki.gnome.org&#x2F;Projects&#x2F;NetworkManager" rel="nofollow">https:&#x2F;&#x2F;wiki.gnome.org&#x2F;Projects&#x2F;NetworkManager</a><p>Each of these have trade-offs. Any assertions like &quot;you don&#x27;t need X&quot; might be good for website traffic, but does not help steer the discussion on how to best serve the user.<p>Taking disk usage as an example, sure a quick &#x27;df&#x27; 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.<p>Surely this has to be discussed at some point.

Is this a troll? First thing is a cp command with no explanation of the file system structure or cd. Who is this for?

I don&#x27;t really like bc. Just seems so old-school, and typing things like &quot;100.0 &#x2F; 34.2&quot; gives you &quot;2&quot;. Is there really nothing better? I feel like someone has to have made some new hotness in Rust by now.

Is this satire? Every single example shown is quicker and easier in a GUI.<p>Shell scripting and pipes are the only times a command-line is better than a GUI.

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.<p>There is no contradiction there really.

&gt; find . -print | sed -e &#x27;s;[^&#x2F;]*&#x2F;;|____;g;s;____|; |;g&#x27;<p>Naturally

If you&#x27;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.<p>At first, you&#x27;ll want to keep the program simple. My first time doing it, I made a super simple &quot;simulation&quot; of a fish tank. The fish just moved at random. They&#x27;d sure if you didn&#x27;t feed them regularly. That&#x27;s about it.<p>It&#x27;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.<p>Definitely try to share as much code as possible between them all. Really forces you to separate concerns.<p>There is no &quot;GUI vs CLI&quot;. It&#x27;s &quot;GUI <i>and</i> CLI&quot;.

This is why my 3D MMO will only have command line GUI for everything. GUI is a waste of the developers and the customers time.<p>I&#x27;ll put the command line interface in the chat bubble above the players head.<p>&#x2F;join &lt;name&gt; &lt;pass&gt; to register and &#x2F;sign &lt;name&gt; &lt;pass&gt; to login will be the first commands.

I&#x27;m not sure how big the subset of people that use unix systems and are ignorant of the command line is.<p>Most of your GUI users are on Windows, and unix shell commands mostly do not work or are aliased to other commands that don&#x27;t work exactly the same way as they do in GNUland.

I think many people are missing the point. I&#x27;d say the emphasis in the title is more on the &quot;need&quot; than the &quot;don&#x27;t&quot;.<p>Sometimes, you&#x27;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.<p>I would, however, prefer that the author recommended using the interactive and verbose option for commands like `cp`, `mv` and `rm`, which I&#x27;ve personally found super helpful. Here&#x27;s what I have in my `config.fish` (with a bonus for cp that preserves &quot;mode, ownership and timestamps&quot;):<p>alias rm=&quot;rm -iv&quot;<p>alias mv=&quot;mv -iv&quot;<p>alias cp=&quot;cp -piv&quot;

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).<p>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&#x27;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&#x27;ve used bash, fish and finally stopped on a pretty vanilla zsh setup, and can confidently call myself a mediocre console user.<p>But filesystem stuff? Looking at lists of files, ordering them, copying and moving? That&#x27;s exactly what GUIs are easily superior at. Especially when the files you&#x27;re working with are some kind of media.

STOP OPENING YOUR FINDER OR FILE EXPLORER<p><pre><code> $ find . -print | sed -e &#x27;s;[^&#x2F;]\*&#x2F;;|____;g;s;____|; |;g&#x27; # on MacOS </code></pre> Yeah, I don&#x27;t think I will.

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.<p>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:<p><pre><code> glances </code></pre> If you want something better than weather.com– no ads, fast loading– try:<p><pre><code> curl wttr.in </code></pre> Better than spotlight– full-text search over 128GB drive in less than 30s– try:<p><pre><code> rg &quot;query&quot; </code></pre> Force quit a program, try:<p><pre><code> pkill -9 ProgramName </code></pre> Suspend a program and un-suspend it later, try:<p><pre><code> pkill -STOP ProgramName pkill -CONT ProgramName </code></pre> View content of a file with syntax highlighting, try:<p><pre><code> bat file.py </code></pre> Open a file and copy it to your clipboard, try:<p><pre><code> cat image.png | pbcopy </code></pre> Go to a recently visited folder with autocomplete that works reliably, try:<p><pre><code> z foldername </code></pre> Convert units– faster than typing into Google, try:<p><pre><code> units </code></pre> Find a file by name faster than Spotlight:<p><pre><code> locate &quot;pear&quot; # finds ~&#x2F;pear&#x2F;readme.txt, ~&#x2F;pearidea.txt </code></pre> To move and copy individual files around, activate the GUI:<p><pre><code> open . </code></pre> These are just a few examples of CLI tools being superior.

Why is it that we&#x27;re so much better at consistency in GUIs than programs? We all know ctrl+c&#x2F;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&#x27;s universal is &quot;--help&quot;

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&#x27;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&#x27;t save appreciable time, so I won&#x27;t use them. I&#x27;ve only got so much RAM, and the GUI makes information extremely easy to digest. People say &quot;STOP using Twitter, use IRC&quot; but those people also miss the point.

I think a killer GUI feature that I&#x27;ve never seen would be a log that shows you the text-based equivalent of every action you take.

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&#x27;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&#x27;ll come around. BTW, I&#x27;m not a GUI programmer, I&#x27;ve done a few but they&#x27;re always ugly and I tend to like backend much more :) . Hence I chose an old fashioned text version. It&#x27;s not pretty but it&#x27;s much more efficient. Yeah I know this isn&#x27;t for all use cases but in mine I felt it was the better choice.

I avoid using the terminal because it&#x27;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&#x27;t feel like a program is really complete until I&#x27;ve made myself a lame little GUI to drive it.<p>The problem is always the same. The &quot;ugh&quot; factor when I try to make the program do something I haven&#x27;t made it do in a while. If code doesn&#x27;t have a pretty front end for me to click on, I&#x27;ll run it much less frequently.<p>(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.)

&gt; they often require more resources, are less powerful and hard to automate via scripting<p>That&#x27;s not a problem with the GUI paradigm, that&#x27;s a problem with the current implementations of it.<p>Current implementations of CLI&#x2F;TUI programs have <i>many</i> 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.<p>Moreover, with that context,<p>&gt; require more resources<p>...is a <i>very</i> poor reason to use them. Computers are meant to be useful, not to sit there saving compute&#x2F;RAM&#x2F;electricity.<p>(I shouldn&#x27;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 <i>not</i> that scenario)

I agree that CLI is better than GUI<p>But the examples given doesn&#x27;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&#x27;re moving doesn&#x27;t have anything in common at all and you don&#x27;t want to move all of it.

&gt; You don&#x27;t need a GUI<p>&gt; view an image - STOP USING PREVIEW<p>&gt; $ imgcat image.png<p>&gt; # Note: requires iTerm2 terminal.<p><i>Narrator: You need a GUI to run iTerm2</i>

Surprisingly negative reaction to this. From the OP:<p>&gt; 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.<p>The target audience is software engineers. And they are right. If you&#x27;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.<p>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.<p>Man page examples&#x2F;sample are still inadequate even after ... ??? 40 years ???. Some analysis of grep use case frequency would probably help them a lot. I&#x27;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&#x27;t see a &#x27;take and share a selfie with all my friends&#x27; or &#x27;play music similar to what I&#x27;m listening to now&#x27; pipelines. Is it too lame or too tough for CLI?

GUI is a superset of TUI, in theory it&#x27;s inherently better, they&#x27;re often bad because it&#x27;s a lot easier to mess up and designers are bad. Use GUI or not completely depends on the case, you don&#x27;t need GUI if you want a list of file names under a directory, but you&#x27;ll really want one if you&#x27;re doing video &#x2F; image &#x2F; audio editing (cases where there&#x27;s no well defined or multiple &quot;input&quot; and &quot;output&quot;). It&#x27;s nice to have a compiled list of commands but the thumbs down is a little condescending.

It starts to get inefficient when you wanna copy some of this and some of that from the same directory.<p>I can easily hold CTRL and select what I want based off of the thumbnails alone. In a terminal that would be painstaking.

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 think the emphasis is on “need” here.<p>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.<p>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.<p>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&#x27;ll assume its serious for the purpose of this reply.<p>&gt; &quot;they often require more resources&quot;<p>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&#x27;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.<p>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).<p>&gt; &quot;are less powerful&quot;<p>All the examples provided can be done with a single click on the UI. Granted the CLI can do more, but there isn&#x27;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&#x27;t natively supported, at least for any major OS distributions.<p>&gt; &quot;automate via scripting&quot;<p>I agree, albeit on Linux &quot;dotnet run&quot; [1] makes so much more sense over the bash code mentioned here, at least for anything that isn&#x27;t a single one-off operation.<p>The File [2] class is an excellent example that makes for code that&#x27;s readable even for someone who doesn&#x27;t know anything about computers.<p>You can even do &quot;dotnet run&quot; on straight code, without having a file to execute. Of course aliasing it is the way to go if you&#x27;ll do it regularly (dr? dnr? just d or just n?).<p>[1] <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;core&#x2F;tools&#x2F;dotnet-run" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;core&#x2F;tools&#x2F;dotnet-ru...</a><p>[2] <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;api&#x2F;system.io.file?view=net-5.0" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;api&#x2F;system.io.file?v...</a>

In Windows, you can do<p><pre><code> dir &#x2F;s graph.db </code></pre> to find any occurrence of graph.db in any subdirectory|<p>The linux equivalent seems to be<p><pre><code> tree -f | grep -i graph\.db </code></pre> However, this seems to be taking approximately forever<p>Edit - 20 minutes later, still not done, is this an O(N^2) operation? Edit - 35 minutes later, the wrong regex... have to do it again<p>tree -f | grep graph.db

I started computing in the 80&#x27;s, if you don&#x27;t need a GUI I have a couple of old hardware to sell, the real experience, what about that? &#x2F;s<p>We know pretty well how computers without GUIs look like for the general population since the 1950&#x27;s, that is why we moved away from them.<p>CLI or REPLs are great for special cases, that is all.

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.

If you learned computing in Windows, some of these realizations are completely new.<p>If your physiology differs substantially from the majority of the population, then yeah. You probably need a GUI.<p>Imagine if the CLI had received the attention the GUI has over the last 40 years in terms of user-accessibility.

I still don&#x27;t understand why I&#x27;d use the command line for git at least. Using a visual tool like Sourcetree I can easily see my staged&#x2F;unchanged changes, the outstanding commits to pull&#x2F;push of all my branches at a glance without typing anything.<p>I can easily fetch&#x2F;pull&#x2F;push&#x2F;merge and switch between branches with a click, which is much faster than typing git commands and branch names. I can back merge&#x2F;rebase changes basically do anything way faster than someone typing in a ton of text to do the same thing.<p>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&#x27;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&#x27;t understand the appeal.

GUIs were introduced pre-internet.<p>Now my discovery process for how to accomplish something on <i>nix typically involves search and most likely Stack Overflow.<p>The surprise here is that in this context text commands are </i>more* discoverable and easier to communicate than UI flows.

Even if I had all that memorized I wouldn&#x27;t be able to type it faster than I could do it in the GUI and one out of ten times I&#x27;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&#x27;s good for you better than you and moves everything into more inconvenient places.<p>Yes, hamburger menus, CSDs, all of you, I&#x27;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 <i>c.l.i.</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&#x27;t a g.u.i. lies is very vague.<p>I&#x27;m fairly certain that the console I summoned in <i>Counter Strike</i> when I was younger qualified as both a command line interface and a graphical user interface.<p>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&#x27;t have permission. Uh oh, now you&#x27;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.<p>i wonder sometimes if trackpoints were standard in every keyboard would this whole gui vs cli argument be much less of an issue.<p>it&#x27;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

I don&#x27;t need to live in a house either, but it&#x27;s nice.

A console showing multiple lines in context is already a gui.

&gt;They were introduced in reaction to the perceived steep learning curve of command-line interfaces (CLIs).<p>Yes, I&#x27;m sure that&#x27;s the reason MS Paint was created.

Should we consider vi&#x2F;emacs as GUIs or CLIs? I think they are no longer truly CLI so we should start using cat&#x2F;awk to read&#x2F;edit files.

there is also a web browser called ‘links’ that is completely in commandline ... i generally use it in live media during rescue if i need something

Yet another &quot;which color is better&quot; problem.

If you are using CLI please install `fzf` and `ripgrep`<p>Thank me later.

Ok the builder side, I think there&#x27;s merit to doing CLI first, then GUI. Or API then GUI, depending on the shape of the tool or app.

Alfred[1] (Mac app) w&#x2F;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.<p>[1]: <a href="https:&#x2F;&#x2F;www.alfredapp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.alfredapp.com&#x2F;</a>

&gt; view an image<p>&gt;<p>&gt; $ imgcat image.png<p>&gt; # Note: requires iTerm2 terminal.<p>I wasn&#x27;t aware of imgcat. I always use the display command that comes with ImageMagick.

Don&#x27;t want to sound too aggressive but why does this repo have ~2.5k stars?<p>AFAICT it lists basic UNIX commands :&#x2F;

Don&#x27;t tell me what I need. We are visual creatures with a huge amount of our brain devoted to that.

Here I am having used shells and vi for ~30 years and enjoying learning to use Rider as an IDE...

This is great! I learned a couple of new commands today, and I&#x27;ve been on unix for years.

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.

If you didn&#x27;t need a GUI, you wouldn&#x27;t need this document.

It&#x27;s 2021, I didn&#x27;t know anyone was still using WinRAR.

I kinda miss the text-based word processors from the 80s.

The people on HN don’t need a GUI. Most of our parents, spouses, and bosses have zero interest in the command line.

Nah. GUI, a nice GUI any day.

You dont need monitor

You don&#x27;t need a computer either just use pen and paper to write and calculate everything.

The very first example skips a step, cd into the directory.

Yes, you don&#x27;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.

I love hacker news