Terminals Are Sexy
terminalsare.sexy
terminalsare.sexy
- shell: the "top level" user interface for the operating system. Can be text-based or graphical, command-line based or point and click etc. It's how you do things once you've loaded an OS. Examples: sh, bash, zsh, fish, eshell (emacs).
- terminal: A hardware device for input/output of text. Originally teletype machines (ttys) but later used CRT monitors instead of a printer. Example: DEC VT100,
- terminal emulator: a piece of software that emulates a terminal. Examples: xterm, GNOME Terminal
- CLI: command-line interface. A user interface based on typing commands one line at a time. Does not include text-based UIs like htop etc. Examples: git, curl.
- TUI: text-based UI. Essentially a GUI but works on more advanced terminals (ie. not actual ttys). Examples: htop, emacs, vim.
For example, I use ZSH. Should I switch to fish? The list suggests I'd be sacrificing power and the ability to write scripts but gaining, uh, intelligence and user-friendliness? Is that true?
Then there's a ton of stuff about customizing ZSH. I know that oh-my-zsh is the most popular but I did not find it especially performant so I never really looked in to using modular components of it. Now I know there are 50 other guides I could read? Maybe I want a plugin manager. antigen is a plugin manager, maybe it'll be more performant than oh-my-zsh? But what about antibody, which is "faster" and "simpler"? But zgen is "lightweight". Are weight and speed connected? What about weight and simplicity? Maybe I should switch to pure, which is "pretty, minimal, and fast".
Then I moved on to my terminal. Currently I use iTerm 2, which "does amazing things". But maybe I should switch to Terminator, which is the "future of terminals". Or MacTerm, which is "powerful". Or Alacritty, which is GPU accelerated? (Isn't iTerm 2? I don't know?)
I went to macOS package managers. I use homebrew because it's what every webpage for everything I want to install says. Should I get fink instead? Macport, I think is old, but it "simplifies the installation of software". I thought homebrew was pretty simple, but I guess it could be simpler?
Then for text editors, I've never been good at emacs-fu, so I often use nano. Maybe I should replace with micro, which is "modern and intuitive"? Or jed, which is "freely available". I don't think I paid for nano, maybe I did.
How does a curated list of Terminal frameworks, plugins, and resources differ from an uncurated one? Can the author give some example of a framework, plugin, or resource that was considered but not included because of the curation? I suspect the things that I know aren't included simply weren't considered to begin with. Maybe I'm wrong.
Most of this criticism applies to every awesome list that gets linked, of course.
(In zsh's case, i think that's partly the project's own fault; it has very underwhelming defaults and a very overwhelming set-up process for new users.)
A lot of people seem to complain about loosing the ability to write scripts that work on other shells because Fish breaks compatibility.
Well, I’ve been using fish for a couple of years now and besides a couple of things that are very specific to my main computer, the rest of my scripts I build as POSIX as I can. I keep everything on a repo and I can then push/pull things on new machines and have everything available.
One can still execute a `/bin/sh script.sh`. Nothing prevents someone from doing that.
More seriously: it’s hard to put together a list like this because so many things are subjective. Maybe you prefer fish because it gets rid of some of the dumb things required for a POSIX-compatible shell, but I prefer zsh because it has every feature and the kitchen sink. I don’t know, and neither does the person putting together the list.
For example, I didn't realize "smart" in the list's vernacular means "deprecates dumb legacy behaviour". Your post is the first time that became obvious to me. Now to figure out what that behaviour is and why I should care and if it impacts performance and and and...
My post wasn't asking the curator to make decisions for me, it was asking them to help me make decisions.
And with the ~20 zsh "frameworks" and "plugin managers" here, they could really do some comparison, or probably even remove a couple.
I'd rather they showed me 3 good options and explained the trade-off than 20 options with little commentary (the lines seem to be mostly cribbed from the projects themselves).
Not the OP.
There’s probably better alternatives, but I’d have to summon the energy to tunnel my way over the barrier.
Just pick something and stick with it a bit....
We have distributions that are providing perfectly packaged things like Debian/Arch/RedHat.
I find already Homebrew hacky on macOS so why porting it on Linux distributions :D Is there anyone on HN using it, I'd be curious to know what are the advantages.
I don't like macOS all that much, but Homebrew is really good.
> it is (arguably) simpler to use and contribute to, and often has more up-to-date packages (especially compared to e.g. RHEL) because it tries to solve a much simpler problem.
Unfortunately, this often means it breaks or doesn’t do certain things…doing something simple like getting an old version of a package is nigh unto impossible, both because there doesn’t seem to be a built-in way to do this, and also because old packages are constantly removed from the package index. The fact that package inclusion is easy is nice, but it also opens issues that we’re already seeing in the npm community with regards to malicious packages.
The ability to install software to a non-system location is useful, but that’s really not something that Homebrew itself really recommends doing on macOS because it breaks a lot of things. It’s really only designed for a single user machine with the regular user being an admin, which is likely true for the majority of its authors, but for those who don’t fit into this you need to resort to a bunch of hacks to make it work.
I agree that Homebrew very aggressively focuses only on the common case (newest version, few/no options). I think it's the right choice, as Homebrew is never the only way to install something. It would be bad if RPM had made the same design tradeoff, though.
Some packages (my favorite example is youtube-dl) are useless if they're not up-to-date. And sometimes the new version has a feature that's really important to you.
I'm using it for ripgrep and node, for instance. ripgrep isn't available in apt, and the node version in apt is incredibly outdated.
There's a reason most software these days tells you to curl an installer and pipe it to bash, and that's because distro package managers never have the latest version.
Here's ripgrep's apt installation instructions:
curl -LO https://github.com/BurntSushi/ripgrep/releases/download/0.10.0/ripgrep_0.10.0_amd64.deb
sudo dpkg -i ripgrep_0.10.0_amd64.deb
Linuxbrew is just so much easier:
brew install ripgrepI am using Arch - seems pretty up to date:
[gerdesj@jglaptop ~]$ aurman -Ss ripgrep
community/ripgrep 0.10.0-2
A search tool that combines the usability of ag with the raw speed of grep
In case you're suggesting Linuxbrew is unnecessary (I don't think you are, but just in case), there's definitely something way more convenient about just using Linuxbrew to install everything, than to track down what software is best installed from what repository.
Gentoo, Red Hat, Fedora, Ubuntu, Debian, Mandrake
So I've had plenty of exposure to three major package management systems and a bunch of distro-managed repos, from the perspective of a desktop user (I've used Linux on the server plenty, too, but that's less directly relevant). I've poked around in a few others in a desktop context—Slackware, Arch, Nix, probably more that I'm forgetting.
I also used Macports for over a year.
Homebrew's the most pleasant overall solution for managing user-facing desktop software that I've used, by a long shot.
I used to manually compile things like Node.js and ripgrep from source to get up-to-date versions, but these days I just use Linuxbrew.
I'd rather say Vim 8.2 is the future of Vim.
I never understood the appeal for terminals. Often (Microsoft's Powershell is a notable exception) the syntax is full of incomprehensible abbreviations, the syntax is wildly inconsistent, the syntax contains hard to remember acronyms...
No, for me, terminals and most textbased interfaces will never be as usable as GUIs.
Terminals might not have discoverability, but in terms of sheer power they wildly outmatch GUIs for many tasks.
I suspect if all technical users simply stopped considering text based ui acceptable, we'd actually have less quality software overall. There are too many programmers like myself, who can make decent programmatic interfaces, but simply can't put together a usable web-interface to save their life.
Graphical user interfaces are a caveman interface. You go to the market, see what's on offer, point to it and grunt. That's fine as long as you see what you want. But you'll never do anything that you can't already see.
It's not easy, though. Nobody pretends that it is. But learning to read and write wasn't easy either and you managed that. What if our education systems didn't enforce that? How would you ever know the power you're missing out on?
A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared looking to most commandline scripts. It's an incomprehensible mess people only can start to grok after years of experience with the particualr commandline tool.
And how is this different for GUIs? Location / icons / description / ... depends entirely on the application. Some will have hotkey handles, some won't. Same app on a different system will look differently. (Possibly with different layout) Creating a discoverable GUI takes as much will and attention as a good set of CLI options.
I would spend far less time at my computer (would only use it for work) if it only had a CLI, but I would never, never use a GUI (beyond text editors, of course) for most of the grunt work, the CLI is simply faster and, and this is the most important issue, almost everything you do with it can be automated.
I couldn't even begin to imagine having to navigate the endless dialogues in IDEs to configure every little thing I would do in the command line, I'd give up programming altogether.
For full TUI applications I'd agree, there are usually worse at discover-ability, they are used because the make up for it in other ways like speed and learn-ability.
As an example of composability... Say you have an api that returns products, but you want to find out how many have the word aliens: curl # gets the api responses grep # searches input wc # counts input. jq # parse and query json
Streaming those together:
curl api.myapi.com/products | jq .name | grep 'aliens' | wc -l
Most of the commands are also mnemonic -r is usually reverse, -R recurse, -a all.
I recently in 5 minutes took the API response from one api and constructed sql queries into a test db for test data using roughly the above method. Another fun, trolling type command, a product manager that wanted daily updates got a scrum.sh that ran on cron and posted summary of what people did on slack.
I don't know how you can work effectively as a software engineer without knowing something about it.
When I first read the author's rationale for tmux it rubbed me the wrong way, because the main feature they dismiss as cruft- the ability to use it as a terminal emulator for a serial port - is something I still find myself using from time to time.
Is tmux really so much nicer than screen it's worth learning minicom?
a clearly-defined client-server model: windows are independent entities which
may be attached simultaneously to multiple sessions and viewed from multiple
clients (terminals), as well as moved freely between sessions within the same
tmux server;
a consistent, well-documented command interface, with the same syntax whether used interactively, as a key binding, or from the shell;
easily scriptable from the shell;
multiple paste buffers;
choice of vi or emacs key layouts;
an option to limit the window size;
a more usable status line syntax, with the ability to display the first line of output of a specific command;
a cleaner, modern, easily extended, BSD-licensed codebase.
i think screen still has some features that tmux doesn't, and vice versa, but I don't have a very strong affinity for either one. They even have similar keybindings. Give them the same prefix key and statusline/statusline color and if I'm not paying close attention, I might not realize which one I'm using.
I would contribute:
xmlstarlet Manipulate xml documents http://xmlstar.sourceforge.net/
jq Manipulate json documents https://stedolan.github.io/jq/
screen Terminal multiplexer (like tmux) https://www.gnu.org/software/screen/
imagemagick Manipulate images https://www.imagemagick.org/
ffmpeg Manipulate video https://www.ffmpeg.org/
gifski Create high-quality gifs https://gif.ski/
I’m still happy that macs shipped with tcsh as default for a while.
But I switched to bash when I stopped carrying enough to switch the default shell.
Maybe I’ll switch to fish. I do love its snarky tagline.
I really miss TotalTerminal. I've been forced to switch to iTerm, the only other way I can find to get a hotkey terminal, but it's an extremely noticeable difference to switch from the overall fastest terminal to the overall slowest:
Also recent versions include a metal renderer[3] (not sure if it's enabled by default) which might be even faster, I have been running it for some time but have not noticed much difference.
Another reason why it might be hard to notice is also because when one is using ssh you anyways have the network latency so might be one is simply trained not to react to latency in terminals as much.
The problem this solves is that the ecosystem of unix tools is so massive it's impossible to wrap your head around it. Most of us just pick our tools and end up at a local optimum. But with that sort of thing seeing the way other people have solved a problem is very useful.
I still think this would be so useful but the privacy situation is very sketchy. If I could come up with a solution to that I might try to build it.
was disappoint.
# unix
wc -w
# powershell
Measure-Object -WordSome of this JavaScript stuff is amazingly ridiculous.
Can be slower than an IDE