xxendi

Linux user here, thought I'd give my 2 cents. Regarding the command line: the seeming reliance on it in Linux is a necessary consequence of the freedom to customize. Someone on a tech support Q&A site asks: "how do I do X", or "I'm trying to do Y but I get this error", or "Z is broken, how do I fix?" Now, there might be perfectly good answers to these questions that involve using the GUI, answers that sound like "click this menu, then go here, check those boxes, click apply". But the problem is that this will only help the users with that particular GUI -- if the answer assumes GNOME and someone else uses KDE, that second person is shit out of luck if they're Googling for the same problem. Or maybe it worked in an older version of their GUI but not in a newer one. The lack of standardization means that GUI-based documentation can only reach a limited audience. So, it's best to just give a command line solution, since chances are that will work across distributions, and command line options change more slowly over time than GUIs, so people searching for the problem in 10 years time will probably still be okay. It's kind of like how in pre-modern times, every little province had its own unique dialect, so literate people would write in Latin for religious and diplomatic purposes (and traders would use the lingua franca). The command line is the Latin of Linux. On the other hand in Windows, almost everyone is on the same interface, changes to the interface tend to only coincide with major releases, and even then there's a lot of continuity. So GUI-based answers are more robust and universal. But this leads to the regrettable situation where a new Linux user wants to accomplish something, and they're told to enter an incomprehensible sequence of incantations into a scary black terminal window. Who knows what that might do? What if they make a typo? How do they undo it? This all unnerved me when I started using Linux. As for whether it's faster or slower to do things on the command line, I actually think Ross has a point here, and that's coming from someone who likes the command line. What I mean is, for most of the things I can think of that the command line makes easy, it's also easy to think of a GUI that could do the same thing. However, such a GUI may not always actually exist, or it might exist but not let you customize it very well, or it might exist but just suck. Sure maybe it's quick to type out mkdir new_dir && cp **/*.txt new_dir to copy all text files in a nested folder hierarchy into a new directory, but I'm pretty sure something like everything can do that and it's almost as fast. Plus you need to factor in the time you spent reading manual pages to figure out all the command line options, the time you spent forgetting them and looking them up again, the time spent forgetting which command to even use, the time you spend dealing with cryptic error messages, etc. Command line programs just have poor discoverability. I've gone through all that pain already and I don't mind reading man pages, so I'll reach for the terminal more often than GUIs. But usually it's not more than a marginal gain in efficiency. The cases where the command line is flatly superior tend to be arcane things used by programmers. There are many GUI frontends for git, and they all suffer from some combination of not exposing enough features (annoying), and obscuring what exactly is being done to the repository (dangerous). But perhaps that's more about git's poor/leaky abstractions, rather than a failure of GUIs. I think the whole argument misses the point because the real power of command line programs come when you don't type them into the terminal in the first place. Instead, you chain them together in scripts and bind them to hotkeys or trigger them from other programs. This is where the UNIX philosophy really shines, and as a small example I'll give you how I customized my screenshot-taking workflow to work exactly the way I want. Here is how I wanted it to work: - I press the PrintScreen button, and it changes my mouse cursor so I can select a rectangular region of the screen. - It should then immediately take an uncompressed PNG screenshot of that region and save it with this exact filename and timestamp format: ~/Pictures/screenshots/screenshot_2020-06-03_16-26-28Z.png - I should then get a prompt that asks me what I want to do out of the four most common things I want to happen after taking a screenshot. Do I want to 1) copy the image to the clipboard, 2) upload the image to Imgur and copy the URL to the clipboard, 3) open the image in the default image-viewing program, or 4) open the screenshots folder. I should be able to use that prompt with the keyboard only. - If I chose 1 or 2, I should get a non-intrusive notification telling me that it was copied to the clipboard successfully. Furthermore, if I chose Imgur, it should save the filename, the image URL, and the deletion URL into a text file called imgur_links.txt. That way I can keep track of all the screenshots I've uploaded, and delete them later if need be. I couldn't find a pre-existing GUI screenshot program that let me do all of these exact things, and trust me, I tried plenty. Maybe one exists, but if it does, it is probably a very big and bloated program, because such a thing would have to be sufficiently general that it wouldn't just support my hyper-specific use-case, but the superset of hyper-specific use cases of many more people. That means a bigger program, bigger memory footprint, and bugs are more likely and harder to fix. However, making all of the above work was a simple matter of shell scripting. This is what I have bound to run when I press the PrintScreen button: #! /bin/bash rightnow=$(date --utc +%FT%TZ | sed -e "s/:/-/g" -e "s/T/_/g") filename="$HOME/Pictures/screenshots/screenshot_$rightnow.png" sel=$(slop -f "%i -g %g") shotgun -i $sel $filename choice=$(echo -e "[1] Copy image to clipboard [2] Upload to Imgur [3] Open saved image [4] Open screenshots directory" | rofi -width 20 -dmenu -l 4 -p "Choose what to do with the image") case ${choice:1:1} in "1") xclip -sel clip -t image/png $filename notify-send "Screenshot copied to clipboard" ;; "2") urls=$(imgur $filename) image_link="${urls% *}" deletion_link="${urls#* }" echo $filename $image_link $deletion_link >> $HOME/Pictures/screenshots/imgur_links.txt echo $image_link | xclip -selection clipboard notify-send "$image_link copied to clipboard" ;; "3") xdg-open $filename ;; "4") xdg-open ${filename%/*} ;; esac The reason this works is because there exist simple, small programs that do each little part individually, and are designed to work well together. Let's go through the most important ones: "slop" is a simple program for selecting rectangular regions. Literally all it does, is let you drag with the mouse to make a rectangle, or click on a window, and it will output the coordinates and size of that rectangle as text to the standard output. "shotgun" is a simple program for taking screenshots. You give it a rectangular region, and it takes the screenshot and saves it to a file. That's it. "rofi" is a program that lets you make DIY menus. Here's what it looks like in this case: You give it a list of newline-separated options as text, and it displays those options for you, and allows you to choose between them using the keyboard, by either typing what you want or using the arrow-keys. It narrows down the possible selections as you type, and when you press enter on one, it outputs that text and closes. Rofi can actually do a bit more than that, but that feature ("dmenu-mode") is what I use it for. It's called that because it replicates the functionality of an even simpler program called "dmenu", but it's harder to customize how dmenu it looks so I went with the slightly more featureful rofi. "xclip" comes with most Linux distributions, it lets you interact with the clipboard programmatically: copy stuff to it, and paste stuff from it. "notify-send" takes some text and displays it as a desktop notification. "imgur" on my system is the name of a script I took from the Imgur website and modified slightly. It takes an image file and uploads it to the site, and outputs just the image link and the deletion link. Each of these little programs all follow the UNIX philosophy: They all do a single simple, even trivial thing. They all communicate with each other via text, passed through pipelines. And they all are meant to work in harmony with each other and with other tools. For example, you can pair slop with a screen video recording tool like ffmpeg so that you only record a small portion of a screen. Or you could use it to select a region and send that to another program that applies some kind of effect -- perhaps enhance the contrast, or blur it out so that sensitive info is hidden in a screenshot. Notify-send lets me set custom reminders, tells me when my downloads have finished, or what new things are in my RSS feed. Rofi/dmenu in particular are very useful because they abstract the entire notion of "selecting from a list", which is extremely common. I use them to choose between screenlock/logout/shutdown/restart, or choose I file I want to open from a search, or what I want to run from a list of installed programs, or what window I want to switch to, or what commit I want to check out in a git repository ... really the possibilities are endless. When you have small programs that communicate via text, rather than a graphical interface, you can very easily duct-tape together all kinds of unique and specialized Rube-Goldberg behaviours using shell scripts (or any language really). The resulting scripts tend to be pretty small, small enough that you can understand the whole thing at once and can write them quickly. You don't need to be a good programmer to write them -- I'm a pretty bad programmer -- and even if you can't code at all, you can steal other people's from places like /r/unixporn. You can then trigger these things however you want -- with keyboard shortcuts, or at startup, or on a schedule, or when the operating system detects some event, or from a GUI front-end. The smallness and simplicity makes it easier for developers to write correct, performant programs. They don't have to think about complicated interfaces, they just need to get the main functionality right and get information in and out via standard input and output streams. For example with something like ripgrep, the creator can't be spending his time on graphics, because he's absolutely hellbent on making it the fastest and most efficient search program in the world. But if someone else wants to make a graphic frontend for it, that can be done. There's the asymmetry: commandline programs can have GUIs attached afterwards, but GUI-only programs can't get commandline input/output (except perhaps with great difficulty). This is the real reason why Linux people like the command line: it's a common language for automating workflows. In that sense it's similar to Autohotkey, but the difference is that you're not bound to a specific GUI environment, and there's also a radically different way of treating information flow between programs (pipes and standard streams). This isn't to say that Autohotkey isn't powerful -- it is extremely powerful, and can in fact do that entire screenshot workflow I outlined. Many people complain that there's nothing quite like it on Linux, again because of the fragmentation of the graphical ecosystem. Autohotkey is GUI oriented, and has an easier time gaining access to the internal state of running programs, but it can also be fragile, since the programs it's controlling aren't always designed to be used in this way. (I didn't realise this until today but there's an entire tiling window manager written in AHK, that is amazing!) There's something else that also gets conflated with "command line", and that's TUIs: terminal user interfaces. These are kind of a hybrid between GUI and pure command line tools: they run in the terminal and are keyboard-oriented, but they look like simple text-based GUIs. An example is something like the ranger file browser. These are cool because they tend to be pretty extensible and customizable. Ranger is actually cross-platform so runs on Windows, you might want to check it out. Anyway when people say "the terminal is faster" they are often including TUI programs in that, rather than just raw command line type-and-press-enter workflow. As for text editors: I'll echo the recommendation for Notepad++. I use it all the time when I'm on Windows. The killer features to me are the tabs and change persistence. You can just press ctrl-N to open a new tab, start typing notes, and you don't have to bother saving or even coming up with a filename. It just autosaves your changes to somewhere (I think in AppData?) and you can close the program without worrying -- it'll all be back when you open it again. I use it at work to take notes .. I have unsaved tabs in there going back to last September lol. It's a real shame there's no Linux version, though there is a "notepadqq" clone that's okay. I tried looking for programs that do mouse gestures on Linux. Surely there's a good one, I thought. Well, the best I could find is easystroke, but that looks to be abandoned years ago and there are a lot of unfixed bugs. That really sucks. Maybe I'll write one ... how hard can it be? Oh and it's good to see another "row-homeless" typist. I never understood the way we're "supposed" to type, with fingers always coming to rest on the home row ... whenever I tried it that way it just felt awkward and alien. When I'm not actively typing I just keep my two index fingers on the little bumps on the F and J keys to orient myself, and the rest of the fingers can chill out wherever.