54 ms·

You Don't Need a GUI

• thrower123 6y ago
  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.
  • analog31 6y ago
    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.
    • ryandrake 6y ago
      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.
      • II2II 6y ago
        > 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.
    • eyelidlessness 6y ago
      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?
      • gsich 6y ago
        no. Windows is surprisingly consistent.
      • analog31 6y ago
        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.
  • josephg 6y ago
    > 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.
  • eyelidlessness 6y ago
    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).
    • thrower123 6y ago
      I do forget that Chromebooks are a thing.
      • eyelidlessness 6y ago
        That too. But that’s also an odd response in context?
• codpiece 6y ago
  This is great! I learned a couple of new commands today, and I've been on unix for years.
  • nimchimpsky 6y ago
    because you've never needed the commands in all those years ? Personally I think the link is an enormous waste of time.
• gruez 6y ago
  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).
  • unnouinceput 6y ago
    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.
    • Kranar 6y ago
      The numerous examples given are the automation and composition of basic operations.
    • KeepFlying 6y ago
      "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.
      • kaba0 6y ago
        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.
    • 6y ago
• etaioinshrdlu 6y ago
  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...
  • aeldidi 6y ago
    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.
    • pgcj_poster 6y ago
      > 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. Use trash-cli: https://github.com/andreafrancia/trash-cli https://github.com/andreafrancia/trash-cli
  • gpanders 6y ago
    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.
• xrd 6y ago
  This is terrific. But... GUIs support the concept of undo. It would be great if all shells indicated the command to undo what you just did, and you could turn off that warning message with an environment variable. And, almost none of these work in the Windows command prompt. I've tried powershell and while there are some great ideas, nothing behaves as I would expect after using bash for 20+ years. These are the reasons people use the GUI. Without acknowledgement of that, this readme loses some of it's lustre.
  • gpanders 6y ago
    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.
    • bch 6y ago
      No need to be abstract and think of “theory”. Vim for example has undo.
      • hsitz 6y ago
        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".
    • lupire 6y ago
      It's been 50 years. Why doesn't bash in a friendly system like Ubuntu have undo for mv.
      • calvinmorrison 6y ago
        alias undo=mv $2 $1
• karlicoss 6y ago
  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.
  • koolba 6y ago
    > If I don't remember the `df` command... what do I do apart from searching on the internet? You can do that locally on the command line too! https://en.wikipedia.org/wiki/Apropos_(Unix) https://en.wikipedia.org/wiki/Apropos_(Unix)
    • homarp 6y ago
      or man -k "disk space"
      • aidenn0 6y ago
        disk space: nothing appropriate.
        • Annatar 6y ago
• throwaway823882 6y ago
  Is this satire? Every single example shown is quicker and easier in a GUI. Shell scripting and pipes are the only times a command-line is better than a GUI.
  • mkehrt 6y ago
    I literally do all of these on the command line except for using a calendar. Using a GUI is fiddly and terrible. Which isn't to say everyone needs to feel like I do. But some people at least will strongly disagree that the GUI is easier.
  • manquer 6y ago
    It is not really quicker on the GUI 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.
  • michrassena 6y ago
    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.
• nocommandline 6y ago
  Full disclosures: 1) I have an App - https://nocommandline.com 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.
  • deleted 6y ago
    [deleted]
  • jodrellblank 6y ago
    > "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. [1] https://www.av-comparatives.org/wp-content/uploads/2018/07/avc_biz_2018_07_kaspersky-1.png https://www.av-comparatives.org/wp-content/uploads/2018/07/a... [2] e.g. https://support.kaspersky.com/9292 https://support.kaspersky.com/9292 [3] https://support.kaspersky.com/us/9291 https://support.kaspersky.com/us/9291 [4] https://support.kaspersky.com/KSC/EventExport/en-US/140056.htm https://support.kaspersky.com/KSC/EventExport/en-US/140056.h...
• pcr910303 6y ago
  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.
  • cle 6y ago
    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.)
  • chipotle_coyote 6y ago
    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.
    • ebeip90 6y ago
      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
    • vitorgrs 6y ago
      And on Windows, there's also Power Automate now btw.
  • 6y ago
• golergka 6y ago
  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.
• Tomminn 6y ago
  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.)
  • smichel17 6y ago
    I don't understand your second point. The GUI gives you to sanitize inputs, or the opposite?
• qyi 6y ago
  >They were introduced in reaction to the perceived steep learning curve of command-line interfaces (CLIs). Yes, I'm sure that's the reason MS Paint was created.
• macando 6y ago
  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.
  • kodah 6y ago
    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.
    • macando 6y ago
      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.
      • HKH2 6y ago
        Fish can autocomplete Git commands; no configuration is necessary. It generally has friendy defaults unlike Bash.
        • deleted 6y ago
          [deleted]
      • kodah 6y ago
        Agreed, these are great assets for learning. Personally, I use zsh combined with HyperJS and starship.rs. Its been a very enjoyable experience.
  • 6y ago
• malux85 6y ago
  > find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g' Naturally
  • manquer 6y ago
    You could set a alias if it too hard to remember or use tree
• 12ian34 6y ago
  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"): alias rm="rm -iv" alias mv="mv -iv" alias cp="cp -piv"
• sn_master 6y ago
  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?). [1] https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-run https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-ru... [2] https://docs.microsoft.com/en-us/dotnet/api/system.io.file?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.io.file?v...
• bkeating 6y ago
  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. [1]: https://www.alfredapp.com/ https://www.alfredapp.com/
• threesmegiste 6y ago
  You dont need monitor
• Waterluvian 6y ago
  I think a killer GUI feature that I've never seen would be a log that shows you the text-based equivalent of every action you take.
  • conradludgate 6y ago
    That would be great. Similar to the "copy as curl" command in dev tools
  • dlivingston 6y ago
    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. [0]: https://www.paraview.org/Wiki/ParaView_and_Python https://www.paraview.org/Wiki/ParaView_and_Python
  • prionassembly 6y ago
    Stata.
  • dyingkneepad 6y ago
    ddd (the debugger) has this, and it's how I learned to use gdb.
  • AlbertoGP 6y ago
    One example is AutoCAD, where GUI actions get translated to commands and inserted in the command line: https://www.youtube.com/watch?v=KZoCJ-mUffs&t=4s https://www.youtube.com/watch?v=KZoCJ-mUffs&t=4s Edit: others have mentioned AutoCAD too in this discussion: https://news.ycombinator.com/item?id=26748281 https://news.ycombinator.com/item?id=26748281 https://news.ycombinator.com/item?id=26748700 https://news.ycombinator.com/item?id=26748700
• slmjkdbtl 6y ago
  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.
• jancsika 6y ago
  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.
• Causality1 6y ago
  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.
• BeetleB 6y ago
  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. [1] Did not bother with the rest.
  • movedx 6y ago
    > 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. Still, the author might not know this.
  • benrbray 6y ago
    It's pretty damning too when an operation like "merging directories" comes with this warning: $ rsync -a /images/ /images2/ # note: may over-write files with the same name, so be careful! This is something that any GUI file manager worth its salt will warn you about.
  • mxcrossb 6y ago
    Agreed. But flashy title aside, it’s probably a nice page to send to someone looking to get started in the terminal.
  • mattmanser 6y ago
    I thought the page was a joke, showing how bad CLIs are. You think he's being serious?
• tapvt 6y ago
  I think the emphasis is on “need” here. 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.
• GekkePrutser 6y ago
  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.
  • gregmac 6y ago
    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.
• booleandilemma 6y ago
  It's 2021, I didn't know anyone was still using WinRAR.
• pugworthy 6y ago
  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.
• Vaslo 6y ago
  The people on HN don’t need a GUI. Most of our parents, spouses, and bosses have zero interest in the command line.
  • aulin 6y ago
    the people that used to be on HN... now every day I come here I feel older, but I stay because it amazes how dumb the new "hacker" generations can be
  • _0o6v 6y ago
    Zero interest? 99% of people I speak to would have no idea what the "command line" even is, let alone be interested in it.
• King-Aaron 6y ago
  > You don't need a GUI > view an image - STOP USING PREVIEW > $ imgcat image.png > # Note: requires iTerm2 terminal. Narrator: You need a GUI to run iTerm2
• moron4hire 6y ago
  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. There is no "GUI vs CLI". It's "GUI and CLI".
• fnord77 6y ago
  I kinda miss the text-based word processors from the 80s.
• happyweasel 6y ago
  A console showing multiple lines in context is already a gui.
• beckman466 6y ago
  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.
• acomjean 6y ago
  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. A breif guide with some screenshots: https://www.linode.com/docs/guides/how-to-install-midnight-commander/ https://www.linode.com/docs/guides/how-to-install-midnight-c...
  • ww520 6y ago
    I still use it occasionally. For one specific thing - tagging large files for batch delete.
  • yoz-y 6y ago
    All the time on ssh sessions, otherwise I use Forklift. https://binarynights.com/ https://binarynights.com/
  • em500 6y ago
    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.
• kjjjjjjjjjjjjjj 6y ago
  You don't need a computer either just use pen and paper to write and calculate everything.
• mikewarot 6y ago
  In Windows, you can do dir /s graph.db to find any occurrence of graph.db in any subdirectory| The linux equivalent seems to be tree -f | grep -i graph\.db However, this seems to be taking approximately forever 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 tree -f | grep graph.db
  • cbsks 6y ago
    Or: find . -name graph.db
    • mikewarot 6y ago
      Thank you so much, that did it, almost instantly. root@Flipper:/# find . -name graph.db ./home/mike/.config/grit/graph.db
• noisy_boy 6y ago
  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.
• lamontcg 6y ago
  Here I am having used shells and vi for ~30 years and enjoying learning to use Rider as an IDE...
• when_needed 6y ago
  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. Surely this has to be discussed at some point.
• JabavuAdams 6y ago
  Don't tell me what I need. We are visual creatures with a huge amount of our brain devoted to that.
• mozey 6y ago
  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
• tumblewit 6y ago
  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
• mdoms 6y ago
  The very first example skips a step, cd into the directory.
• chme 6y ago
  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.
  • jodrellblank 6y ago
    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.
• pkulak 6y ago
  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.
  • ilyagr 6y ago
    Use 'bc -l', at least on Linux (GNU bc). Then it's suddenly useful. I recommend aliasing bc to 'bc -ql'. You can alternatively remember to do 'scale=10' before doing anything else in bc. This isn't a great ad for the article's claim that CLIs are in every way superior to GUIs, is it?
  • fyhn 6y ago
    I've used #!/bin/sh python3 -c "from math import *; print($1)" as my calculator for some time now, and it's quite useful. I need to invoke it with quotes though: calc '100/34.2'
  • gspr 6y ago
    > Is there really nothing better? I use iPython or GHCi for my calculator needs.
• pjmlp 6y ago
  I started computing in the 80's, if you don't need a GUI I have a couple of old hardware to sell, the real experience, what about that? /s We know pretty well how computers without GUIs look like for the general population since the 1950's, that is why we moved away from them. CLI or REPLs are great for special cases, that is all.
• max_hammer 6y ago
  If you are using CLI please install `fzf` and `ripgrep` Thank me later.
• permo-w 6y ago
  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
• rntksi 6y ago
  I agree that CLI is better than GUI 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.
• michaelgrafl 6y ago
  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).
  • michaelmrose 6y ago
    Your comment about task switching is fair but how much time do you spend in the file manager window? You are apt to pay that cost either way and with a lot of tasks it's as easy to have both hands on the keyboard.
  • deleted 6y ago
    [deleted]
• bullen 6y ago
  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. I'll put the command line interface in the chat bubble above the players head. /join <name> <pass> to register and /sign <name> <pass> to login will be the first commands.
• tape_measure 6y ago
  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.
• aequitas 6y ago
  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.
• yoz-y 6y ago
  Is this a troll? First thing is a cp command with no explanation of the file system structure or cd. Who is this for?
• jcelerier 6y ago
  > $ cp readme.txt documents/ sure, works fine in my ~, I have the follwing files: 'FOPC_0211237F_4563(1).pdf' FOPC_0211237F_4563.pdf FOPC_0251215K_4563.pdf FOPC_0381912X_4143.pdf FOPC_0381912X_4154.pdf FOPC_0755890V_282.pdf FOPC_0755890V_283.pdf FOPC_0755890V_284.pdf FOPC_0755890V_285.pdf FOPC_0755890V_286.pdf FOPC_0921204J_4652.pdf FOPC_0952259P_58.pdf FOPC_9830445S_4142.pdf 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
  • 1_player 6y ago
    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.
  • reeeeee 6y ago
    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.
  • aulin 6y ago
    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 wholeheartedly agree about the edgy teenager who just discovered bash
    • jcelerier 6y ago
      > 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)
• anonytrary 6y ago
  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.
• mackrevinack 6y ago
  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
• ZoomZoomZoom 6y ago
  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.
• jonathanstrange 6y ago
  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.
• approxim8ion 6y ago
  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.
• bergercookie 6y ago
  Don't want to sound too aggressive but why does this repo have ~2.5k stars? AFAICT it lists basic UNIX commands :/
• Blikkentrekker 6y ago
  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.
• m4r35n357 6y ago
  "Discoverability" is just an excuse not to have documentation.
• cpach 6y ago
  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. There is no contradiction there really.
• peter2_2 6y ago
  How true is this
• peter2_2 6y ago
  I love hacker news
• syl_sau 6y ago
  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!
  • umvi 6y ago
    Have you seen a Vim master in action? They make a really good case for terminal file manipulation.
    • tubularhells 6y ago
      'Vim for everything' mentality requires a high degree of autistic behaviour in my opinion. I'm just not there on the spectrum.
      • TeMPOraL 6y ago
        It doesn't. It just requires openness for the concept. Same with Emacs for everything. That's not to say you should do it. It's fine if you do, it's fine if you don't.
        • tubularhells 6y ago
          I consider vim and Emacs to be the same thing with different shortcuts. I have no desire to learn either.
      • Nalta 6y ago
• austincheney 6y ago
  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.
• isodev 6y ago
  Nah. GUI, a nice GUI any day.
• enriquto 6y ago
  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.
  • jodrellblank 6y ago
    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.
    • enriquto 6y ago
      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: cat in.png | viscrop > out.png
• mkoubaa 6y ago
  Ok the builder side, I think there's merit to doing CLI first, then GUI. Or API then GUI, depending on the shape of the tool or app.
• phtrivier 6y ago
  I have a problem with the very first entry: ``` cp readme.md documents/ ``` 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.)
  • thomasahle 6y ago
    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.
    • noisem4ker 6y ago
      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.
  • vergessenmir 6y ago
    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: $1" } function mark { mkdir -p "$MARKPATH"; ln -s "$(pwd)" "$MARKPATH/$1" } function unmark { rm -i "$MARKPATH/$1" } function marks { ls -l "$MARKPATH" | sed 's/ / /g' | cut -d' ' -f9- | sed 's/ -/\t-/g' && echo } </code> To bookmark a directory: $/home/user/Documents> mark To jump to it $/tmp> jump Documents source: https://datascienceworkshops.com/blog/quickly-navigate-your-filesystem-from-the-command-line/ https://datascienceworkshops.com/blog/quickly-navigate-your-... I can't find the orginal HN discussion on this but it has shown up a few times with incremental improvements like tab completions added.
• kalal 6y ago
  Yet another "which color is better" problem.
• jamesrom 6y ago
  If you didn't need a GUI, you wouldn't need this document.
• anticristi 6y ago
  Whatever became of nuances ... I thought this discussion was settled. You need to expose functionality via: 1. A library 2. A CLI 3. A TUI 4. A GUI NetworkManager is a good example: https://wiki.gnome.org/Projects/NetworkManager https://wiki.gnome.org/Projects/NetworkManager 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.
• shultays 6y ago
  Should we consider vi/emacs as GUIs or CLIs? I think they are no longer truly CLI so we should start using cat/awk to read/edit files.
• ComodoHacker 6y ago
  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?
• itsdsmurrell 6y ago
  I don't need to live in a house either, but it's nice.
• crazypython 6y ago
  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: units Find a file by name faster than Spotlight: locate "pear" # finds ~/pear/readme.txt, ~/pearidea.txt To move and copy individual files around, activate the GUI: open . These are just a few examples of CLI tools being superior.
• dhbradshaw 6y ago
  GUIs were introduced pre-internet. Now my discovery process for how to accomplish something on nix typically involves search and most likely Stack Overflow. The surprise here is that in this context text commands are more* discoverable and easier to communicate than UI flows.
• trixie_ 6y ago
  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.
  • maxekman 6y ago
    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.
• tcfunk 6y ago
  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 :)
• deleted 6y ago
  [deleted]
• grumple 6y ago
  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.
• itomato 6y ago
  If you learned computing in Windows, some of these realizations are completely new. If your physiology differs substantially from the majority of the population, then yeah. You probably need a GUI. Imagine if the CLI had received the attention the GUI has over the last 40 years in terms of user-accessibility.
• u801e 6y ago
  > view an image > > $ imgcat image.png > # Note: requires iTerm2 terminal. I wasn't aware of imgcat. I always use the display command that comes with ImageMagick.
• stjohnswarts 6y ago
  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.
• millzlane 6y ago
  It starts to get inefficient when you wanna copy some of this and some of that from the same directory. I can easily hold CTRL and select what I want based off of the thumbnails alone. In a terminal that would be painstaking.
• roguson 6y ago
  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.
• dTal 6y ago
  STOP OPENING YOUR FINDER OR FILE EXPLORER $ find . -print | sed -e 's;[^/]\*/;|____;g;s;____|; |;g' # on MacOS Yeah, I don't think I will.
• fouric 6y ago
  > 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)
  • dragonwriter 6y ago
    > Current implementations of CLI/TUI programs have many problems themselves: lack of undo This is more common with CLI than with TUI, and its largely because the former are generally aimed at lower-level use than TUI or GUI applications.
    • fouric 6y ago
      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.
• 6gvONxR4sf7o 6y ago
  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"
  • fouric 6y ago
    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.
• AtlasBarfed 6y ago
  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.