Ask HN: Is it still possible to live in a terminal?
In college I did a month long experiment where I only used my computer's terminal emulator to do all my work. I wrote my code/notes in Vim, browsed the web with elinks, and wrote my emails using mutt. It was a great learning experience.
Recently I looked into doing this again and ran into a bunch of issues:
- My company uses Slack's enterprise auth, and all the CLI slack clients I could find haven't been updated in years and no longer work.
- The web is using more javascript than in the past.
- Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best. Email servers are starting to use more complete auth mechanisms that don't work well with mutt.
It seems like the terminal world is slowly getting abandoned in favor of proprietary GUI apps. Anyone still living inside the terminal? Links to tools for Slack are appreciated.
271 comments
[ 4.8 ms ] story [ 285 ms ] threadI've tried to do the same thing: going completely text mode. For me, it was disastrous -- it was a big distraction for me at work, at two jobs. I even left a good job partially so that I could try to go text-mode rather than click my way through lots of GUIs. It was something of an obsession. Now I look back and sigh.
Checking my email or chatting though, why bother? The company pays for outlook and slack, I’d just be making my life pointlessly difficult.
Running a bunch of Electron apps to handle basic things slows you down and takes an unnecessary amount of system resources.
Most users can’t automate GUIs to create workflows, assuming the apps and the platform being used even support that.
Scripting CLI tools has existed since the dawn of Unix.
Yes, and that happens regardless. I can turn off notifications and choose when to look at email or Slack or whatever. I can have those apps on my iPad screen and ignore it or put it in focus mode. If you're talking about switching applications that's just a keystroke whether I'm in screen/tmux or in MacOS.
> Running a bunch of Electron apps to handle basic things slows you down and takes an unnecessary amount of system resources.
All of the native apps I use work faster than I do, I don't think they slow me down. System resources have come a long way since the early days of Unix you refer to. None of my devices struggle with low resources. I mainly work on remote servers so that's where I compile and test code and so on, and those machines don't have GUIs or apps hogging up resources.
>Most users can’t automate GUIs to create workflows, assuming the apps and the platform being used even support that.
Sure, and even fewer users can do anything at the command line.
> Scripting CLI tools has existed since the dawn of Unix.
I remember. That happened about four years into my career as a programmer. I didn't start to see Unix in the wild for a few more years. Scripting CLI tools pre-date Unix but they sure got nicer when Unix took over.
I'm happy to use the command line for almost everything I do in terms of programming. But some of what I do to keep my customers happy involves communicating with them, reading stuff they send, etc. I can't force my customers to stop sending PDFs or HTML emails or links to Zoom calls, nor would I want to. And I'm not going to live with 1970s technology in imitation of Richard Stallman, because however great the terminal and Unix CLI can work for so many things, they aren't the best tool for everything.
> It seems like the terminal world is slowly getting abandoned in favor of proprietary GUI apps.
Eh, I'm seeing quite the opposite trend. I see people doing stuff that'd consider using a terminal to be straight up inappropriate for (e.g. displaying line graphs).
And your troubles with Slack is most likely down to it being proprietary garbage.
Although, if you are going to live in Emacs there might be enough terminal there without actually running it in a terminal.
Sure you can get away with it but vim plugin is no where close to what you can do in Idea. Not even in the same orbit.
https://github.com/wee-slack/wee-slack is decent.
> - The web is using more javascript than in the past.
cli browsers are probably the only truly unrealistic thing. An idea that I've been kicking around for a while is to build a simple CLI "browser" that uses PhantomJS or similar under the hood to request, load, and render the page into an image, convert the image to sixel (https://en.wikipedia.org/wiki/Sixel) and display it that way (or use any of the various terminal emulator-specific features (KiTTY has https://sw.kovidgoyal.net/kitty/graphics-protocol/ for example)). Probably pretty clunky, but it's doable if you're in the mood to write something purely for fun.
> - Mutt doesn't handle multiple email accounts natively for work/personal. The solutions are hacks at best. Email servers are starting to use more complete auth mechanisms that don't work well with mutt.
I don't think they're hacks. You can define exactly how you want it to work. That's a feature, not a bug. Sure, it takes a little bit of work to set up but you can use https://github.com/cweagans/dotfiles/tree/master/.config/mut... as a starting point if you'd like.
Some glitches for sure and I couldn't actually draw in Excalidraw, but I obviously wasn't expecting to.
neovim - text editor
aerc - email
nzbget - usenet
irssi - chat
mpv - audio
still hoping for gemini to take over for a full terminal experience.
Personally I'm all in favor of having more open APIs and third party clients, but would never want to intentionally constrain myself to a TTY that is half a century old.
- Multiple accounts: I have a per-account config file with the relevant specifics (https://github.com/wfleming/dotfiles/tree/arch-linux/home/co...) and use folder hooks to apply those depending on which mailbox I'm viewing (https://github.com/wfleming/dotfiles/blob/arch-linux/home/co...). (Plus a keybinding in each account file to make flipping to the next account easy.)
- Non-standard auth:
For web & Slack, I sympathize and have toyed with CLI alternatives in the past, but I'm come to terms with the the fact that it's just not that feasible for the most part. Personally, I spend as much time in the terminal as I can, but I've given up on fighting against the tide for everything. The only native apps I usually have open are Firefox, Slack, and Spotify, and that's acceptable to me since it ends up meaning I still spend most of my day in a terminal.Unless you're an absolute terminal power user that can masterfully navigate tmux, vim or whatever tools you use, I don't think it's a good use of time. There certainly are things where the terminal is the right tools, use it in those situations. Just ask yourself if you're artificially limiting yourself, simply because you think the cool kids use the terminal.
Rather. 99% of what I use tmux for is both: not what I would consider "power user" skills; what I think terminal emulators like kitty or iTerm2 will mimick anyway; and reflects how e.g. VSCode arranges its open files.
I find it convenient to have a session of tabs for a particular task/project, and to switch between the tabs depending on what I want to do.
That said, I rarely make use of split panes (nor a tiled window manager). YMMV, but I almost always want whatever I'm looking at to be fullscreen.
Zellij at least shows the keyboard shortcuts.
If you're not doing business, using the terminal works fine. Up until you have to deal with health insurance or your power bill or your taxes or bank.
Unfortunately the world now revolves around [gui] web browsers. We brought this technologically retarded hellscape on ourselves and we deserve it.
You largely can restrict yourself to phone calls and postal mail. Aside from ordering from Amazon, my dad largely does. (Albeit in part because my brother and I will do various things for him he can't figure out how to do with just a phone call or letter.) But it's increasingly difficult for a lot of things and is, at a minimum, less convenient.
And, as you say, in business you generally don't really have the option to basically refuse to use a computer for many purposes.
This seems backwards. Limiting yourself to CLI tools do retard your abilities, modern GUI apps do not.
CLI respect of Emacs yes, is limited and limiting, but modern GUIs are FAR more limited and limiting. Can you integrate them? No. Let's say you want in a single view a set of mails, financial transactions, notes etc. You can arrange something in a CLI, you can do it in org-mode, you can't do it in the most advanced ERP monster.
Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.
I'd agree that some GUIs are bad, but the same could be said about some TUIs.
On a terminal, I can run a terminal based editor who typically can run code from inside the text buffer. In Emacs I can do much more in both terminal and X11. That's is.
My org-mode notes links anything, meaning mails (searches, specific messages, threads), financial transactions (ledger), elisp code, for instance to act on notes themselves like an `* Online retails orders` heading with a "click here to add a new one" or to change the Emacs/EXWM graphic, for instance to present something, org-ql queries on my notes etc. In pure CLI (not TUI) I can at least cat and process programs output, in modern GUIs I can't.
A simple showcase: https://youtu.be/B6jfrrwR10k
GUI apps can and sometimes do provide interfaces for programmatic use.
And some terminal applications fail to follow conventional Unix patterns.
If you limit the capabilities of a GUI interface to only what is possible without code changes, then you must do the same for CLI applications.
Emacs is all code. Most CLI-only applications cannot be modified other than the flags you pass in; you are instead forced to pipe from one application to another.
If you limit the capabilities of GUI applications to the realm of existing software (i.e. your monster ERP reference) then we must also limit the capabilities of CLI tools to what exists, and I know (for having looked far and wide) that I have needs which are not available via terminal-only programs; the only existing set of available software that I need with a comprehensive set of features is in a GUI-only application.
They quickly drop such idea introducing GUIs, who fail to offer composability and scripting, and they derailed hitting their own design limits. Modern GUIs are the monster emerged form such ashes who happen to be worst than the problem it try to solve. The issue in the example comparison in my previous post is that at least in CLIs you can combine/compose a bit, with modern GUIs you can't. Write a script is easy, at least FAR easier than change an ERP.
>Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.
I don't see this as a bad thing. I want someone responsible for the product to figure out the best way to use it via a focused set of controls and inputs. Some people fail at this, others are amazing.
In CLIs you need a way to query in text all such elements, you are limited by the limited and limiting Amazon WebUI who do not offer anything cat-able, even not anymore a manual *sv export. Not much different is the situation on your bank side where if you are lucky you just get manual ofx/qif export.
In a classic CLI world you wold have a remote service who can be queried ssh-in it and locally process the output. In modern Emacs you can do the same in a modern 2D DOCUMENT-BASED GUIs. You just need a bit of math to mach items to bank transactions, nothing more than 20 SLoC. With the WebUI paradigms you need perhaps a WebVM extension with around 5-10k SLoC to achieve something similar...
It sounds like you want APIs for all of your services. That’s fair. But I don’t think the vast, vast majority of people have use cases as you describe so the ROI on providing something and maintaining it is too low.
In any case, in today’s world, you can programmatically scrape the page of the results and crawl further pages if necessary. It wouldn’t be 5-10K lines to output a list of names and prices.
The modern web seems pretty great to me. Why do you feel that way?
Google reader was nice, a day Google kill it, GitHub seems to be nice for some cohort of users, a day a political move between some countries makes your account locked, a day your ebook reader+service cease to exists with all books you never own but being convinced of the contrary, a day your smart vacuum cleaner stop to work because an AWS service have issues etc.
That's how pretty it is. Pretty to capture you, ugly once you discover you are trapped and than it's too late.
Oh, sure in mere tech terms you might run webapps locally, they are still NOT AT ALL pretty behind sugar-eye graphics, since integrate things, bend things is a nightmare that demand a gazillion SLoC for anything, while on classic CLI or better systems like Emacs you can do it in a snap. Not only: anything you'll learn on classic systems is valuable normally for a lifetime and more, anything you learn for the modern web might be valid for few years but generally last far less and no, you can't advance, you can only remain afloat keep learning the new crap on and on.
My point is:
- modern TUIs, called by most CLIs, compared to modern GUIs (widget based GUIs and WebUIs) are more powerful because AT LEAST they allow limited easy user extensibility and composability (scripts and unix IPCs);
- classic GUIs, in the sense of document UIs, like Emacs, like old Xerox Tioga etc, on contrary can be called 2D CLIs in modern lingo and they are FAR superior both of TUIs and modern GUIs because they are "graphical" and they are even more extensible and composable than TUIs.
That's is. Modern developers regularly push toward classic GUIs without knowing them, think for instance how popular Notebook UIs have became. WebUI themselves as a "more like documents" widgets-based GUIs. Still are are far behind classic document UIs.
* Accessibility - I can't change presentation to make things easier for me to consume
* Inspectability - I can't search, index, etc. Information is hidden behind js driven interfaces that only present bits at a time.
* Uniformity - I don't want to deal with a deluge of clever interfaces. I want the data only, and I want control over how I will present the data to myself.
* Buggy - All these custom JS driven interfaces means a never ending deluge of weird interaction bugs, most of which we just ignore. Pages are needlessly slow or error prone.
A quote I once heard about the modern web browser: "I want this program to do everything my computer already does."
Imagine a simple hypertext markup language which tells a program how to render the text, link to different text or sites and perhaps paint some images on a screen. Seems pretty strait forward. Now make that program into a worse computer. This is what makes many people nauseous when they attempt to build "modern web" things.
I heard a great comparison of game dev to web dev: "You write programs to reach goals or a finish line. game dev feels like you're building and fine tuning a race car. Web dev feels like you're running a marathon in the rain and everyone is throwing garbage at you while booing."
> Unfortunately the world now revolves around [gui] web browsers. We brought this technologically retarded hellscape on ourselves and we deserve it.
As bad as the web is, I certainly don't miss the days when I had to go to a physical office, wait minutes, sometimes hours, in a line and talk to somebody that may or may not help me, depending on how their day was going. Thanks but no thanks.
This seems like rose colored glasses, maybe there was a very small period of time where there was a wide variety of things you could do in a terminal, but for business purposes it was mostly native GUI’s which suffer from the same problems as the web if not worse (maybe only better because they were harder to make so there were a lot less of them)
Web sites that require JS to function (and there are many) is a bigger deal.
Same with pictures.
It's much more realistic to run a graphical environment and use a regular browser. Just disable JS by default and put a reasonable ad blocker. Then whitelist sites where you really need JS to work, like your Jenkins host :)
A reasonable PDF viewer is also not such a resource hog, same with picture viewers when you need to display pictures. Say, Firefox does a reasonable job of being both if you don't want to install dedicated software.
You can make a graphical environment which is snappy, low-distraction, and very usable. (That was definitely already possible 20 years ago, when my Linux desktop was my main working machine, and ran quite adequately on a tiny fraction of today's laptop resources.)
Perhaps it is time to upgrade :)
Personally, I use Firefox for browsing, PyCharm for coding, mpv/qimgv for media, and do pretty much everything else in the terminal. Terminal tools are incredibly versatile and composable in a way GUIs really can't match - for instance, I built a script that gets all the RAW files from my camera, converts them to jpg with darktable-cli, and optimizes them for filesize maintaining the same visual quality with jpeg-recompress, great for when I don't particularly care about editing each picture of a long hike. Next step will be to also push them to Google Drive, but I haven't gotten around to that yet. Similarly, the gopro-like camera I use for recording racing footage produces files with some weird filenames and terrible encoding which makes them enormous, so another script pulls the files, renames them to the date/time taken, and uses ffmpeg to transcode them to hevc, which saves several GB. Could I do this all from GUIs? Probably, but it'd involve a lot of hunting for files, dragging/dropping, and context switching between different programs. It's a lot more convenient to do it all in one short command.
There's also some amazing tools which just don't make much sense or would be quite contrived in GUI form. fd and fclones come to mind. AI is starting to be packaged as CLI tools, and it'll open up even more possibilities. Separate hiking pictures into their own directory? Sure! Find lecture videos mentioning a specific subject? No problem, this one doesn't mention the specific keyword you were looking for but it's also relevant at X timestamp!
I love streamlining my ZSHell and ViM experiences by tooling around and have produced some nice scripts and functions which are both living documentation and useful to share.
However, I wouldn't expect my team to maintain shell scripts as they're a bit esoteric.
I quickly navigate around and search my files, use version control, switch projects, run services, and open sites in my browser using terminal and Vim commands.
I have to switch away for debugging though.
For local graphics programs, that also provides a memory-mapped framebuffer which makes basic graphics a doddle. Beyond that, text-mode browsing has been too hard work for years (and so by extension email too). While it's very possible to 'cheat' by setting X to render to a framebuffer (either directly or in the background) the whole reason to use the text-only console is to focus on code without computer-borne interruptions.
Even on my graphical computer, it's basically terminals windows and a browser. Any piece of software that interrupts the flow is either configured to not do so, or discarded PDQ.
Terminals FTW.
My work mbp M1 was having a delay writing text in external monitor
While all the rest, including vidéo, was display without delay.
I had to tweak some driver settings ( of the base , not my graphic card )
[1] https://apps.apple.com/us/app/is-it-snappy/id1219667593?plat...
In my blissful ignorance I could produce just as much effective code on a VNC machine competing with a 1080p Netflix stream on a rural DSL line as I could on a local machine in TTY mode.
The brain is really amazing at what it can adapt to, when I'm typing in a laggy situation it's like "see" the output of what I've typed before it's on the screen and end up being comfortable doing stuff like fixing a typo before it's even been reflected on the screen
However, I've never been tolerant of lag - having a time gap between doing something and having a response just adds to mental workload, it's friction between me and the machine (especially pronounced with IDE's that try to 'help' by taking a second or two to come up with a suggestion, by which time it'll have been left in the dust).
Some of the kernel changes that are happening may well make it possible to have simple high-speed framebuffers that can be used for text consoles in the future, so there's still hope.