
Terminals Are Sexy - turrini
https://terminalsare.sexy/
======
black-tea
A pet peeve of mine is confusing the terms "terminal", "shell", "CLI" etc.
They are not interchangeable and the distinction is important to understand.

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

------
notafraudster
This is a lot to take in. Not sure if you're the author, OP, but in case the
author is reading: Where would you suggest someone starts? (Note: Don't answer
here! Use your answer to shape the organization of information on the site!)

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.

~~~
snazz
There are only so many adjectives in circulation.

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.

~~~
notafraudster
I don't know how someone reading the list would understand that "fish ... gets
rid of some of the dumb things [what things?] required for a POSIX-compatible
[?] shell, but [others] prefer zsh because it has every feature [what
features?] and the kitchen sink."

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.

------
crispinb
Human sexuality may be famously plastic, but this could be going a bit far.

~~~
coldtea
You'd be surprised

~~~
crispinb
Perhaps I should consider myself fortunate to have maintained a decent
foothold in the non-tech world.

------
edhelas
[http://linuxbrew.sh/](http://linuxbrew.sh/) but… why?

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.

~~~
selectodude
It's for people who don't have root access to a remote terminal (super
computer users, generally) but want more up to date packages.

~~~
Zarel
It's also useful for people who do have root access to a terminal, remote or
otherwise, but want more up-to-date packages.

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
    

There's no way I'm memorizing that. I'll have to google 'ripgrep' copy/paste
it from the readme each time.

Linuxbrew is just so much easier:

    
    
        brew install ripgrep

~~~
gerdesj
_and that 's because distro package managers never have the latest version._

I 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
    

Thanks for the heads up wrt search tools.

~~~
Zarel
Oh, yeah, I don't personally use Arch, but from what I hear, it isn't an Arch
problem at all. I was mostly talking about apt (Debian, Ubuntu, Mint, etc) and
yum (Fedora, CentOS, etc).

------
sergioro
"neovim - Literally the future of vim."

I'd rather say Vim 8.2 is the future of Vim.

~~~
throwawaylolx
Yeah, I find the list needlessly opinionated and not sure how it adds to e.g.
[https://www.google.com/search?q=awesome+cli](https://www.google.com/search?q=awesome+cli)

~~~
dickeytk
that's not editorializing, that is neovim's tagline:
[https://neovim.io/](https://neovim.io/)

------
sharpercoder
I _hate_ non-discoverable UI's. The first thing I do with any software, is
click through all possible menu's, windows, ribbons, whatever. After some
time, I usually get quite a grasp on what the software is capable of. The two
notable exceptions are textbased UI's (terminals, dsls, ...) and softwar
requiring domain specific knowledge (e.g. geomodeling software, specific 3D
modeling software, ...).

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.

~~~
black-tea
A command line interface lets you communicate to the computer using language.
Learning a language is something you can practise and get better at until you
find that you're able to communicate very complicated tasks that the original
authors of the programs had never even imagined.

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?

~~~
sharpercoder
But most commandline languages are inconsistent, have inconsistent
abbreviations, have inconsistent command parameter naming/defaults, contain
acronyms of incomprehensible words, have plain weird names, contain
inconsistent or outright incorrect documentation...

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.

~~~
viraptor
> But most commandline languages are inconsistent, have inconsistent
> abbreviations, have inconsistent command parameter naming/defaults, contain
> acronyms of incomprehensible words, have plain weird names, contain
> inconsistent or outright incorrect documentation...

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.

~~~
sharpercoder
With a language, it is far more important. In a gui I can just click around
and see. With tuis, I need to enter a command and hope it is the right syntax.

~~~
luord
IDK about you, but I find it writing a command and seeing the result is far,
far faster than clicking around.

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.

------
dannypgh
Every time I encounter a tmux recommendation it has me pondering whether it's
worth learning minicom.

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?

~~~
pmoriarty
You could also learn screen instead of minicom. screen supports communication
over serial.

~~~
dannypgh
Perhaps I was unclear: screen is what I use now (and have used for quite a
long time) and I haven't moved away from it because I actually use and value
the support of serial consoles.

------
FavouriteColour
I love this. Just reading the list make me happy.

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/
    

Oh I see I can make a pull request!

------
classichasclass
I guess I'm the last of the tcsh troglodytes. C-shell derivatives don't even
get mentioned in these things to say "don't use it" anymore.

~~~
jonathankoren
tcsh was the thing to use back in the days of multiuser systems and ytalk.
Knowing when your friends were logged, and command correction were killer.

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.

------
Zarel
It mentions TotalTerminal, which hasn't been properly supported since OS X
10.10, and outright doesn't work on versions of macOS newer than 10.12.

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:

[https://danluu.com/term-latency/](https://danluu.com/term-latency/)

~~~
somada141
Interesting read, never considered iTerm to be slow and I'm so grateful it
exists but maybe I'm not as hardcore a terminal user as I thought I was :).

~~~
gnyman
I'm not sure this is still the case or has been for some time. The maintainer
of iTerm2 commented on it here
[https://gitlab.com/gnachman/iterm2/issues/5922](https://gitlab.com/gnachman/iterm2/issues/5922)
and here
[https://news.ycombinator.com/item?id=14800195](https://news.ycombinator.com/item?id=14800195).

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.

[3] [https://gitlab.com/gnachman/iterm2/wikis/Metal-
Renderer](https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer)

~~~
Zarel
For me, the most noticeable delay is in opening the hotkey window. I have
animation disabled, and there's still a few hundred milliseconds between when
I press the hotkey, and when iTerm appears.

------
qwerty456127
Command-line interface can indeed be very convenient for many tasks,
nevertheless a properly designed GUI can always be made a way better than a
TUI so I can see no reason to stick with terminal-based editors given a
choice. And I wish people would stop dichotomizing command-line and GUI and
start integrating their capabilities to build something synergic. I.e. I'd
love to have a terminal featuring powerful inteligent pop-up autocompletion
and correction, visual shell command construction assistance, file choice
dialogue (so I could choose a file the GUI way and get its name pasted into
the command) etc.

------
realbarack
I had a product idea (maybe it is even a business idea) a while back to do
shell autocompletion based on an autocompletion engine which was trained
across multiple users. Kind of like a cloud-connected fzf.

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.

------
schaefer
came for some actual, physical (preferably sexy) terminals.

was disappoint.

~~~
fphhotchips
I was ready for an article on the latest in airport and train station
architecture. Was also disappoint.

------
partycoder
"lexis" is the same as

    
    
        # unix
        wc -w
    
        # powershell
        Measure-Object -Word

~~~
anothergoogler
Yea but it's written in JavaScript.

~~~
crehn
And has _51_ dependencies.

Some of this JavaScript stuff is amazingly ridiculous.

~~~
partycoder
npm itself has more dependencies.

[https://github.com/npm/cli/blob/latest/package.json](https://github.com/npm/cli/blob/latest/package.json)

------
cjohansson
eshell is a terminal emulator inside Emacs that is written in Elisp. It also
have support for ssh/ftp/sftp and more via tramp, highly recommend. You can
multiplex it and have powerline without much effort

~~~
edw
Yes but can you run Emacs inside it?

~~~
cjohansson
Not inside eshell but inside term and ansi-term that are more complete
terminal emulators inside Emacs. Though they lack tramp-support

------
purplezooey
Still no good terminal calendar program that can sync with o365.

------
partycoder
spacemacs and spacevim = slow

Can be slower than an IDE

