Trying to explain how “easy” it is to configure your terminal really just made me think that it’s kind of hard and that I still sometimes get confused.
A lot of these things are simple once you understand them but completely impenetrable if you don’t already know what’s going on. I learned most of it by just idling in the #emacs channel and hearing people ask about their problems over a period of 20 years.
Usually there is a complete lack of affordances to go from “this is doing something different from what I want” towards the direction of a fix, because shells don’t let you drill down and view source, and the terminology you need to use to search for the problem is unfamiliar and unguessable. Shells are very powerful but this lack of drill-down-ability and transparency is a really big problem.
A really common problem is that of having your $PATH customizations not getting picked up. If you don’t understand the difference between a terminal, a shell, and a login session, it seems completely bizarre, but once you have the framework in place it’s very simple to understand why it doesn’t work: someone adds a directory to their $PATH by editing ~/.bashrc and they test it out in bash and it works fine. They open up Emacs from a GUI (not from bash) and suddenly the $PATH setting is gone! But they open bash from within Emacs, and it’s back again! What’s going on?!? The problem of course is that Emacs is not bash and cannot read the .bashrc file; if you want your path to change for more than just bash you have to put it in ~/.profile instead. But when you think of bash as “the thing that runs all your programs” you can’t understand why bashrc changes aren’t being picked up.
Then you bruteforce it later by sourcing bashrc from .profile, and it seemingly works great. Then two years later you’re initializing something twice, but not always, and you don’t know why.
And then there’s not-emacs-but-other-thing that you may run via dmenu from your window manager and it either reads ~/.profile when it does that or only on login and you wonder why nothing works unless you reboot (or log in again)…
On most of my environments, I’ve had this solved by hand for ages. But it just bit me when I set up 32-bit Debian on a netbook recently. The system profile and bashrc put /usr/local/bin in front of /usr/bin in the path, so far so good, but ~/.local/bin doesn’t get put in front of those until the user’s .bashrc. The login screen’s XFCE session setup script doesn’t source the user’s bashrc, so ~/.local/bin is first in my path in a shell in xfce-terminal, but not for XFCE’s panel launchers or menu. Which means that if I start Emacs from the menu, it’s the system’s Emacs 28 and not my absurdly optimized local build of Emacs 30 that took 8 hours to build on this little netbook…
I find bash’s tab completion very frustrating, if there’s more than one match then you can’t tab through them
Tab completion is a fascinating area with I think two broad schools of preference. I think I am personally in the other school: I find it very frustrating when a completion mechanism reacts differently depending on how many times I’ve pressed tab, or presents a “visual” interface to navigate, preferring instead to type in additional characters and press tab again until hitting another ambiguity.
I think this is mostly because I prefer that when I push a button the system ends up at rest in a state I can predict without necessarily needing to stop, read the screen state, figure out what to do next visually and in a different mode (picking from a menu instead of typing more characters). It’s a bit like preferring to have a pair of idempotent buttons, “on” and “off”, rather than a state dependent “toggle on/off” button.
I think this is mostly because I prefer that when I push a button the system ends up at rest in a state I can predict without necessarily needing to stop
That’s part of it but it also just seems reckless to randomly pick one of the options and go with it! Like I frequently use tab completion in cases where I think there’s only one completion, and then I press enter immediately, before I go to read that the completion gave me the answer I expected it to. This can be pretty dangerous in some contexts.
The version is tab completion that I have (I believe this is the fish shell default setup) is that if I click tab and there are ambiguous options, nothing happens in the command I’m typing, but I see all the possibilities as suggestions highlighted underneath the prompt. Then if I hit tab again, the first one of those will be selected, then the second, etc. I can also navigate through the list with arrow keys.
This feels like the best of all worlds to me, because there’s no sense of arbitrarily choosing one option out of potentially many, and I can easily see what my options are. But at the same time, I can also start tabbing earlier and see suggestions. In the extreme, I can use tab completion as a kind of poor man’s file explorer where at every level I can hit tab to see what the options are, then select that with the arrow keys and continue.
Every time I have to use bash I forget how tedious it can be with these sorts of things.
It’s POSIX enough that most commands will work as expected with no translation. And if it doesn’t work, you can always do bash -c '<command I pasted from the internet>', or even just run bash and paste the command in directly.
I used to run into more issues, but in recent years I’ve barely ever had any issues. Partly that’s Fish improving its compatibility, but I feel like part of it is people becoming more aware of Fish as an option. Meanwhile, I have colleagues who are really impressed by how well I’ve set up my shell, when it’s pretty much just stock Fish (I don’t think I’ve even changed the theme or disabled the stock welcome message on my current work laptop).
I stopped writing shell code last year (my go-to is now Rust, eve for quick n dirty scripts) and a few weeks ago I realized that that meant that I really had no need for POSIX shell syntax and semantics anymore, and decided to try Fish. Now I’ve got a nice improvement in the area I actually use terminals for: interacting with programs and files.
My big problem with bash tab completion is it is hard to see what’s next. So say I do fo<tab> and it lists foo, food, foe. OK, my options are really o or e. But now imagine I do “big long command with last arg here” and then it expands to ““big long command with last arg here_sadadhuwy3476832ygd” and i hit tab again. It spits out like 80 options with no column alignment with that random same uuid prefix line noise and it isn’t even obvious what the common prefix is anymore, much less what the actual options to proceed are.
In my own implementation of getline, I have it try to column align it and highlight the prefix, making it a bit more obvious what it is… can bash do that too?
Fish and helix are amazing “zero config” tools that work out of the box. I wish I had a clean brain with no muscle memory so I could just use these two and never touch a config again. So much of what I need for a shell and editor is already baked in with zero dependencies, it’s great.
I have been rewiring my brain to learn helix lately and it really isn’t too bad. The hardest part is that the order of things is flipped around, so ct” in vi-alikes is t”c in helix.
Multicursors are so nice though, there are so many functions that I used to rely on plugins for (like Tabularize) that helix can just do by default. Also built in LSP-support means not having to futz with that, which at least so far has been really nice.
I used Fish for a while, but when I joined a company that relies heavily on network file systems, I found Fish has poor performance due to predictive stat’ing. It wasn’t configurable, so I stopped using Fish.
I’m back on plain bash, and only configure it to have infinite history, and hook into fzf.
clipboard integration between vim and my operating system so that when I copy in Firefox, I can just press p in vim to paste (text editor, maybe the OS/terminal emulator too)
Maybe I’m crazy, but I actually prefer having two different “clipboards” between my OS and editor.
I set up a copy and paste command as a shell snippet that connects over SSH port proxies to client copy/paste, and associated kakoune commands so that yanking to the client clipboard is a distinct command from normal copy. (It’s set up to work through stain and stdout which is great for preserving formatting of files and longer-than-a-screen things)
It sounds ornate, but it’s actually one line on each side. If anyone’s interested I’ll post it here next time I’m at my laptop.
Escape delay: in default tmux, escape <wait under 500ms> is interpreted as ctrl. I’ve taught people twice my age with 30+ YOE how to fix this and it’s like watching someone wake up after cataract surgery.
Flow control: Did you know bash has ctrl-S to do the reverse of ctrl-R? Oh, yeah, add this line to your bashrc to make it not freeze your terminal.
Terminfo: i like a fancy new terminal as much as the next person, but can we stop making them special? I dont have a solution to this, and i do mostly ssh-based development and it drives me nuts.
Has anyone ever actually gotten mosh to work right?
tmux 3.5 fixed this (“Reduce default escape-time to 10 milliseconds.”)
Terminfo: i like a fancy new terminal as much as the next person, but can we stop making them special? I dont have a solution to this, and i do mostly ssh-based development and it drives me nuts.
A solution is to query for terminfo capabilities via XTGETTCAP, which is independent of $TERM and works across SSH. Supported by at least foot, kitty and xterm.
Escape delay: in default tmux, escape <wait under 500ms> is interpreted as ctrl. I’ve taught people twice my age with 30+ YOE how to fix this and it’s like watching someone wake up after cataract surgery.
That’s what everyone tells me, but every time I’ve tried it it sucks obviously and immediately. Most recently (couple weeks ago) it freezes when I invoke bat.
I suspect it’s cause it’s way pickier than is practical about client/server binary match. I’m always running to (inclusive or) from some wacky distro where I have to build it from source or homebrew.
I’ve never tried very hard cause IME when something pratfalls 30 seconds into using it different ways 6 times out of 6 over as many years, there is no light at the end of the tunnel.
This is my opinion, but, I don’t want my terminal session to provide many niceties. I might be less productive due to it, yet I would rather be comfortable in most environments than hit the wall when my thermonuclear shell history and tab completion can’t come with me.
Perhaps this helps me when I find myself reaching for elaborate shell commands to be documented and organized in scripts rather than a very powerful ctrl+r fuzzy matcher.
For the longest time I would stick to things which worked in sh, and options to commands that were as universal as possible between Linux and various UNIX variants. Things that worked in vanilla vi, etc. because I didn’t want to have to learn too many gnu-isms basically.
Now that I no longer regularly use Irix, Dynix/ptx, HP-UX, AIX, DRS/NX and Solaris, I find myself using a lot more gnu-isms. And that’s fine, it’s Linux all the way.
I do still stick to plain bash though, for the same reasons. Ubiquity is a fine thing to aim for.
Many of these are personal preferences. Prompts, colors and keybinding obviously, wanting to use the scroll wheel or arrow keys, how much one prioritizes shell history etc.
Out of these only bracketed paste and 24 bit color support is where I am likely to agree with the author on our preferences and priorities.
And I disagree with you both about 24-bit colour support, which is grist to your mill :-)
Sometimes when I want a Quake-style terminal I just chvt into a virtual terminal with 16 colours, and it’s fine. It’s not modern though, so in a sense the author is correct.
I guess I only really need 24 bit for one thing: Emacs. I display my Emacs sessions on terminals as well as X11 and it’s distracting if the color schemes don’t match.
One thing that annoys me that no one else seems to care about (probably because I don’t really use terminals that often) is I can’t simply click somewhere to place the caret. I just want the terminal to behave exactly the same as any normal editor on my OSes (windows and mac) but I always have to do a bunch of config (except with windows terminal, thankfully) to make simple things like ctrl+backspace/delete/arrows work and I’ve not really found a way to make cursors act the same.
A bonus would be multi-cursor like vscode/sublime but that seems like a hard bargain!
Does anyone know if this exists for terminals like windows terminal or iterm2?
A terminal emulator is essentially a weird, fairly standardized GUI framework for shells and the other terminal programs that they run — but it’s a GUI framework that provides primitives for defining buttons or text input fields or other widgets but doesn’t define any widgets itself. Even the old-fashioned urxvt supports mouse clicks, but it’s up to the shell (or the program that it’s running, if any) to interpret and act on the mouse click.
I just want the terminal to behave exactly the same as any normal editor
What is your normal editor? Does it provide a terminal emulator or similar? For example, GNU Emacs provides a few terminal emulators or similar, at least one of which, EShell, is not a terminal emulator but a shell that implements its own GUI using Emacs as its framework — and Emacs handles mouse clicks like Emacs handles mouse clicks.
Edit: I run GNU Emacs as a GUI program, not in a terminal emulator.
Ah so the terminal doesn’t actually know/care/control the actual caret? I didn’t know this, that explains why it’s not standard behaviour.
As for normal editor, I meant editors like the one I’m typing in now, essentially any text input on my computer like sublime text, vscode, <textarea>, basically places where all the primitives I’m used to for manipulating text has an expected behaviour: move the caret around, ctrl+arrows to move it by words, ctrl+backspace to delete words, cmd+backspace on mac to delete the whole line, etc.
so if I’m understanding this right, this is basically just the ghosts of the 1970s still making things awkward today 😅
I did try and write a shell once and ran into a lot of ancient “teletypewriter” things which made it a monumental task (then nushell came out and solved everything I wanted to solve anyway)
I suppose that my “perfect” terminal would essentially be a terminal and a shell as a single app that understands all the typical (at least, typical to me) text editing things as well as do the things a shell would do… food for thought, but I guess it’ll never happen due to backwards compatibility with all the old stuff.
Ah so the terminal doesn’t actually know/care/control the actual caret?
I guess I would say the terminal emulator knows but does not control. If you click at some position in the line where your shell is taking input, a terminal emulator with mouse support tells the shell that you clicked at that position, and the shell could update its internal notion of where the text insertion point is and tell the terminal emulator to move the visible caret to the new insertion point, but I don’t think typical shells implement that. In contrast, for example, Vim implements that.
a terminal and a shell as a single app that understands all the typical (at least, typical to me) text editing things as well as do the things a shell would do
EShell is this, for example. You mention VS Code; that might have something similar to EShell.
I guess it’ll never happen due to backwards compatibility with all the old stuff.
EShell, for example, indeed is not compatible with, for example, Bash, but such a shell certainly could be. EShell can be run in a terminal emulator, as Emacs can be run in a terminal emulator.
I can’t be bothered much anymore. “everything affects everything else” rings painfully true:
changing prompt →terminal title gets messed up → spend hours trying to trace through the 20 different /etc/ files to find how its set because no one documents escape codes for terminals
git branch → doubles the amount of time it takes to access slow mounts → spend hours in a rabbit hole of how to work out if I’m on a local FS or not before running some command as part of prompt
And then, there are other aspects that are scary as all gosh, like tab completion for python automatically running files in the current directory (so don’t tab complete in your Downloads folder!). And then finding out bash_completion is massive, un-auditable in turn. Just ended up disabling all programmatic completions for now.
And then you type in sudo -i/pkexec/ssh and its all gone.
I do want to go into using fish or ysh though, partially just to start relatively clean on completion scripts
The main thing I have a hard time with is that I want to be able to open URLs that are displayed in my terminal using the keyboard instead of clicking on them with the mouse. I have been able to find a total of zero terminal emulators that support this out of the box, and one (urxvt) that makes it easy to add with a small amount of configuration. (I think there might be some that exist, but for my own purposes I won’t use it unless it’s packaged in Debian apt.)
Anyone know if there’s something like that I’m missing? I don’t love urxvt but having to use the mouse for URLs is a deal-killer for me.
Wezterm supports this with the quick select mode. By default there are only keybindings setup to copy and insert URLs, but the documentation already contains the necessary Lua snippet needed for opening them directly.
How up to date are the “modern” tools, and how soon do you usually get them on Debian? I’m on fedora which already pushes close to the bleeding edge. And for a while now I’m just used to tools being in flatpak, so I get a really up to date working environment. E.g. I’m using wezterm for quite a while now.
I remember from… Centos or Ubuntu LTS r something, that it is usually significantly slower, at least it used to be. Not just getting the shiny new tools in the repos, but sometimes it even took quite long for already packaged tools to get updated from upstream. It’s frustrating to know that the bug you reported was fixed months ago but you can’t update it from the repos.
How does Debian fare there? I’m adding out of curiosity, I don’t intend to switch from Fedora for my workhorse machine any time soon.
How up to date are the “modern” tools, and how soon do you usually get them on Debian?
TBH I’m not even sure what this question means. Maybe that in and of itself is the answer to your question.
I used to build things from source a fair bit, but nowadays I pretty much only find myself doing that for programs that I’m planning to make contributions to myself. Everything else comes from Debian’s apt sources, except Signal which I wish I didn’t have to use, but realistically the alternatives are all so much worse.
Foot has a visual mode where you see all the links highlighted with a shortcut to press to open one. It’s definitely my favorite version of the problem you are describing
Thanks; this looks promising. I think I tried this on my previous machine and it wouldn’t even boot because it needed a more recent OpenGL version, but it runs on my current one.
I use it all the time not in vi mode, maybe the docs are outdated? And yeah they are pretty sparse, I think you’re better off looking at the default config file.
Not out of the box but st with the externalpipe patch can do it in a very flexible way since you pipe the whole terminal pane into the program or script of your choice. It’s possible to do the same on the tmux side too. Or anything else that can pipe the whole pane into an external command, for example xterm with a custom printer command. The patch link has some examples for the URL extraction.
Before I answer your question, I should warn that Nushell does not describe itself as production ready yet. I use it locally for my own personal productivity only. It feels pretty polished to me, but I take the authors at their word. I would not advocate for using it in server environments or any other business critical system until they say it’s baked.
Now, on to your question, I’m not entirely sure what you mean by “interactive.” I suspect you mean TUIs, in which case, mostly not. I use a test runner with interactive commands, but apart from that, I’m mostly running one-line commands and occasionally using pipes to query structured data (e.g. from JSON) or writing one-off scripts to automate repetitive, error-prone tasks. If you mean leaving processes running indefinitely to be periodically checked in on, yes, I do that, although I generally shut them down at the end of the day. I haven’t needed a multiplexer for a couple of years now. According to the docs, pueue and tmux are supported if you need that sort of thing, but I haven’t tried either in nushell yet.
Not the original asker, but I would have asked the same question, so I’ll expand. I honestly like nushell and have used it for extensive scripting work, but I have not had luck switching to it as my daily driver in the terminal. Compared to fish, I miss much of the tab completion (e.g. type “git com”, hit tab, and get “git commit”) and other little touches in the terminal that aren’t connected to the language.
The interactive question comes up because I do use nushell, but only in fixed scripts and not interactively. Those nushell scripts are called from my fish shell. I know that I’m not the only person in this position. Honestly, I would like to cut out the middleman and run nu full time and I’ve spoken with other devs in the same position, but the actual shell interpreter just has too many papercuts at the moment. If you’re using nushell full time in the terminal, then I’m hoping you might have some guidance on handling those papercuts.
It sounds like you’re taking @cflewis’ use of the word “interactive” to mean using it as one’s default shell, in which case my answer is yes. Nushell became my daily driver about two or three months ago. I stand by my description of my own experience of Nushell as being “pretty polished.” I have experienced a few paper cuts, but nowhere near enough to discourage me. I can put my paper cuts into three buckets:
Fundamental differences between Nushell and POSIX: This is where most of them come from. But once I learn the Nushell way of doing a thing, I generally prefer it. (If I didn’t feel this way, I wouldn’t still be using it.) This in turn creates a mental rift between using the ecosystem of familiar, POSIX-based tools and coming to grips with less familiar tools that I have nevertheless come to prefer. So, for example, whereas I used to use curl and jq, I now use the built-in http command (which can automatically parse various formats including JSON) and the various built-in ways of navigating and querying structured data, respectively.
Add-on features: I’ve never used Fish, but it sounds like there are some features like completion integrations that come with it out-of-the-box. Nushell treats these sorts of things as add-ons. For example, you can use fish completions in Nushell(!) I picked carapace for completions for the simple and uncritical reason that it was the first one on Nushell’s list. It’s been fine. I slightly prefer bash-style completions, which, based on your description, I suspect you do as well, but not enough to fuss with it any further.
Design choices I fundamentally disagree with. There aren’t many of these, but there are a couple. I don’t particularly like history-based suggestions/completions, which, as far as I can tell, you can’t disable. For me, they are usually wrong (different directory or other context) and therefore distracting. I don’t want to see completions until I ask for them; that’s what ^R and the Tab key are for. Also, I miss my block-style cursor. Whatever you set your cursor style to in whatever terminal emulator you use, Nushell overrides it with a beam style cursor. I suspect this is related to the history-based completions because you can see Nushell’s history-based suggestions as you type, which only makes sense with a beam cursor.
Your post has inspired me to give it another try. Carapace should solve 80% of my complaints and the history based suggestions were something I had found “missing” the last time I’d tried it. Thank you for inspiring me to take another look - I hadn’t realized how far it had progressed.
There’s a lot of lifting you can do by installing modern drop in replacements of the standard tools, eza for ls, bat for cat being my two “must do first” installs onto a new box. My Fish config aliases them to their original counterparts and then I’m good to go.
Then of course you have just tools that are strictly better but not drop-in compatible like sd for sed, rg or ag for grep etc.
Regarding 24-bit color in a terminal: I am just as happy without it, as long as I don’t have 8-bit color. If you only have 16 colors, you can (usually) set them so that each one looks nice, and they look nice together. If you have 24-bit color, then your apps are responsible for their own theming, and it’s usually fine. But if you have 256 colors, you are just screwed. Apps will try to theme themselves, but fail horribly, while your delightful 16 color terminal themes are just ignored.
Somehow, for reasons I don’t fully understand, 24-bit color terminal support may randomly work or not, and if it doesn’t, it invariably falls back to 256 colors rather than 16 and everything is terrible.
I also need and expect terminal programs to work correctly on a monochrome terminal, maybe with bright/dim, but possibly not. This is becoming increasingly difficult to guarantee.
A long-lived tmux session I can reconnect to + mosh mean my session is there when I want it. Relatedly, nice to have a VPN with easy reconnection–there’s Tailscale free for personal use and WARP at work. I have mouse mode on in tmux which makes accessing its scrollback easier.
I don’t have enough time with these two to say for sure they’re Good Things, but I’ve recently picked up:
atuin, without sync, so no history gets lost with multiple shells running. It also puts up a fancy UI for reverse-incremental-search, but that’s mattered less than just reliably keeping history
ble to proactively offer history and file completions within bash.
Being in pure bash it isn’t so snappy as to be transparent; I disabled highlighting (bleopt highlight_syntax= in ~/.blerc) which at least felt like it helped
For basically aesthetic reasons I toned down some of its other visuals using ble-face auto_complete="fg=242,bg=235" and bleopt exec_errexit_mark=$'\e[91m[err %d]\e[m'
Some folks at work said that, for them, it was hard to make an a different shell stick; too many one-liners, etc. built up assuming bash. Not having to change is part of what’s nice about ble. Your situation could vary depending on what you do generally and the maturity and nature of your dev env specifically.
Meanwhile I do not (always) use a modern/fancy editor; I’m one of the how-many-can-there-possibly-be users of joe which I would not recommend to others. Work recently picked up ruff as an autoformatter, which is maybe especially nice to have when the editor isn’t clever.
A lot of these things are simple once you understand them but completely impenetrable if you don’t already know what’s going on. I learned most of it by just idling in the
#emacschannel and hearing people ask about their problems over a period of 20 years.Usually there is a complete lack of affordances to go from “this is doing something different from what I want” towards the direction of a fix, because shells don’t let you drill down and view source, and the terminology you need to use to search for the problem is unfamiliar and unguessable. Shells are very powerful but this lack of drill-down-ability and transparency is a really big problem.
A really common problem is that of having your
$PATHcustomizations not getting picked up. If you don’t understand the difference between a terminal, a shell, and a login session, it seems completely bizarre, but once you have the framework in place it’s very simple to understand why it doesn’t work: someone adds a directory to their$PATHby editing~/.bashrcand they test it out in bash and it works fine. They open up Emacs from a GUI (not from bash) and suddenly the$PATHsetting is gone! But they open bash from within Emacs, and it’s back again! What’s going on?!? The problem of course is that Emacs is not bash and cannot read the.bashrcfile; if you want your path to change for more than just bash you have to put it in~/.profileinstead. But when you think of bash as “the thing that runs all your programs” you can’t understand why bashrc changes aren’t being picked up.Then you bruteforce it later by sourcing bashrc from .profile, and it seemingly works great. Then two years later you’re initializing something twice, but not always, and you don’t know why.
https://github.com/purcell/exec-path-from-shell works great for setting PATH up in GUI Emacs
It does work, but it’s a hacky workaround. It’s better to fix the root cause of the problem and set your PATH in a non-shell-specific way.
And then there’s not-emacs-but-other-thing that you may run via
dmenufrom your window manager and it either reads~/.profilewhen it does that or only on login and you wonder why nothing works unless you reboot (or log in again)…On most of my environments, I’ve had this solved by hand for ages. But it just bit me when I set up 32-bit Debian on a netbook recently. The system profile and bashrc put /usr/local/bin in front of /usr/bin in the path, so far so good, but ~/.local/bin doesn’t get put in front of those until the user’s .bashrc. The login screen’s XFCE session setup script doesn’t source the user’s bashrc, so ~/.local/bin is first in my path in a shell in xfce-terminal, but not for XFCE’s panel launchers or menu. Which means that if I start Emacs from the menu, it’s the system’s Emacs 28 and not my absurdly optimized local build of Emacs 30 that took 8 hours to build on this little netbook…
Tab completion is a fascinating area with I think two broad schools of preference. I think I am personally in the other school: I find it very frustrating when a completion mechanism reacts differently depending on how many times I’ve pressed tab, or presents a “visual” interface to navigate, preferring instead to type in additional characters and press tab again until hitting another ambiguity.
I think this is mostly because I prefer that when I push a button the system ends up at rest in a state I can predict without necessarily needing to stop, read the screen state, figure out what to do next visually and in a different mode (picking from a menu instead of typing more characters). It’s a bit like preferring to have a pair of idempotent buttons, “on” and “off”, rather than a state dependent “toggle on/off” button.
That’s part of it but it also just seems reckless to randomly pick one of the options and go with it! Like I frequently use tab completion in cases where I think there’s only one completion, and then I press enter immediately, before I go to read that the completion gave me the answer I expected it to. This can be pretty dangerous in some contexts.
The version is tab completion that I have (I believe this is the fish shell default setup) is that if I click tab and there are ambiguous options, nothing happens in the command I’m typing, but I see all the possibilities as suggestions highlighted underneath the prompt. Then if I hit tab again, the first one of those will be selected, then the second, etc. I can also navigate through the list with arrow keys.
This feels like the best of all worlds to me, because there’s no sense of arbitrarily choosing one option out of potentially many, and I can easily see what my options are. But at the same time, I can also start tabbing earlier and see suggestions. In the extreme, I can use tab completion as a kind of poor man’s file explorer where at every level I can hit tab to see what the options are, then select that with the arrow keys and continue.
Every time I have to use bash I forget how tedious it can be with these sorts of things.
Fish gets so much hate & I don’t know why when the defaults are sane & require little to no configuration
It’s not POSIX, and beyond that there’s a lot of assumptions in tutorial and documentation that everyone is running exactly bash.
Kind of the same reason why QWERTY still dominates.
It’s POSIX enough that most commands will work as expected with no translation. And if it doesn’t work, you can always do
bash -c '<command I pasted from the internet>', or even just run bash and paste the command in directly.I used to run into more issues, but in recent years I’ve barely ever had any issues. Partly that’s Fish improving its compatibility, but I feel like part of it is people becoming more aware of Fish as an option. Meanwhile, I have colleagues who are really impressed by how well I’ve set up my shell, when it’s pretty much just stock Fish (I don’t think I’ve even changed the theme or disabled the stock welcome message on my current work laptop).
This is true, but Bashisms are wildly pervasive & incompatible, but rarely does anyone bat an eye.
I stopped writing shell code last year (my go-to is now Rust, eve for quick n dirty scripts) and a few weeks ago I realized that that meant that I really had no need for POSIX shell syntax and semantics anymore, and decided to try Fish. Now I’ve got a nice improvement in the area I actually use terminals for: interacting with programs and files.
My big problem with bash tab completion is it is hard to see what’s next. So say I do
fo<tab>and it lists foo, food, foe. OK, my options are really o or e. But now imagine I do “big long command with last arg here” and then it expands to ““big long command with last arg here_sadadhuwy3476832ygd” and i hit tab again. It spits out like 80 options with no column alignment with that random same uuid prefix line noise and it isn’t even obvious what the common prefix is anymore, much less what the actual options to proceed are.In my own implementation of getline, I have it try to column align it and highlight the prefix, making it a bit more obvious what it is… can bash do that too?
My
~/.inputrcincludes:In my home directory, typing
ls tes<tab><tab><tab>gives me:bash shows everything after pressing tab 3 times (as opposed to 2 for zsh and 1 for fish)
To be clear, the first
<tab>completestestotest.and then you have to press tab twice to get the (potentially very long) list of completions.Fish and helix are amazing “zero config” tools that work out of the box. I wish I had a clean brain with no muscle memory so I could just use these two and never touch a config again. So much of what I need for a shell and editor is already baked in with zero dependencies, it’s great.
I have been rewiring my brain to learn helix lately and it really isn’t too bad. The hardest part is that the order of things is flipped around, so
ct”in vi-alikes ist”cin helix.Multicursors are so nice though, there are so many functions that I used to rely on plugins for (like Tabularize) that helix can just do by default. Also built in LSP-support means not having to futz with that, which at least so far has been really nice.
I used Fish for a while, but when I joined a company that relies heavily on network file systems, I found Fish has poor performance due to predictive stat’ing. It wasn’t configurable, so I stopped using Fish.
I’m back on plain bash, and only configure it to have infinite history, and hook into fzf.
Maybe I’m crazy, but I actually prefer having two different “clipboards” between my OS and editor.
Similarly, I like that I have several available “clipboards” in my editor, some of which are linked to X (
"+pand"*p).Yeah that should be a sine qua non for anyone who even occasionally handles confidential data! I hate that it’s not the default in all systems.
I set up a copy and paste command as a shell snippet that connects over SSH port proxies to client copy/paste, and associated kakoune commands so that yanking to the client clipboard is a distinct command from normal copy. (It’s set up to work through stain and stdout which is great for preserving formatting of files and longer-than-a-screen things)
It sounds ornate, but it’s actually one line on each side. If anyone’s interested I’ll post it here next time I’m at my laptop.
I do too but I do enjoy being able to copy from in my case helix to my system as well as to the helix clipboard.
Adding to the pile:
Escape delay: in default tmux, escape <wait under 500ms> is interpreted as ctrl. I’ve taught people twice my age with 30+ YOE how to fix this and it’s like watching someone wake up after cataract surgery.
Flow control: Did you know bash has ctrl-S to do the reverse of ctrl-R? Oh, yeah, add this line to your bashrc to make it not freeze your terminal.
Terminfo: i like a fancy new terminal as much as the next person, but can we stop making them special? I dont have a solution to this, and i do mostly ssh-based development and it drives me nuts.
Has anyone ever actually gotten mosh to work right?
tmux 3.5 fixed this (“Reduce default escape-time to 10 milliseconds.”)
A solution is to query for terminfo capabilities via XTGETTCAP, which is independent of $TERM and works across SSH. Supported by at least foot, kitty and xterm.
This just changed my life. I’ve been putzing around with a free EC2 instance using helix through tmux, and frustrated that escape takes a few mashes to take. This also led me down a rabbit hole starting with this interesting post: https://unix.stackexchange.com/questions/608142/whats-the-effect-of-escape-time-in-tmux
mosh worked fine for me without much messing around, as I recall.
That’s what everyone tells me, but every time I’ve tried it it sucks obviously and immediately. Most recently (couple weeks ago) it freezes when I invoke
bat.I suspect it’s cause it’s way pickier than is practical about client/server binary match. I’m always running to (inclusive or) from some wacky distro where I have to build it from source or homebrew.
I’ve never tried very hard cause IME when something pratfalls 30 seconds into using it different ways 6 times out of 6 over as many years, there is no light at the end of the tunnel.
I used screen/tmux for a while, but grew tired of issues relating to how they both intercept keypresses.
Now I use dtach(1) for persistence, and SSH multiplexing and my window manager for comfortably having multiple windows.
This is my opinion, but, I don’t want my terminal session to provide many niceties. I might be less productive due to it, yet I would rather be comfortable in most environments than hit the wall when my thermonuclear shell history and tab completion can’t come with me.
Perhaps this helps me when I find myself reaching for elaborate shell commands to be documented and organized in scripts rather than a very powerful
ctrl+rfuzzy matcher.For the longest time I would stick to things which worked in sh, and options to commands that were as universal as possible between Linux and various UNIX variants. Things that worked in vanilla vi, etc. because I didn’t want to have to learn too many gnu-isms basically.
Now that I no longer regularly use Irix, Dynix/ptx, HP-UX, AIX, DRS/NX and Solaris, I find myself using a lot more gnu-isms. And that’s fine, it’s Linux all the way.
I do still stick to plain bash though, for the same reasons. Ubiquity is a fine thing to aim for.
Many of these are personal preferences. Prompts, colors and keybinding obviously, wanting to use the scroll wheel or arrow keys, how much one prioritizes shell history etc.
Out of these only bracketed paste and 24 bit color support is where I am likely to agree with the author on our preferences and priorities.
And I disagree with you both about 24-bit colour support, which is grist to your mill :-)
Sometimes when I want a Quake-style terminal I just chvt into a virtual terminal with 16 colours, and it’s fine. It’s not modern though, so in a sense the author is correct.
I guess I only really need 24 bit for one thing: Emacs. I display my Emacs sessions on terminals as well as X11 and it’s distracting if the color schemes don’t match.
One thing that annoys me that no one else seems to care about (probably because I don’t really use terminals that often) is I can’t simply click somewhere to place the caret. I just want the terminal to behave exactly the same as any normal editor on my OSes (windows and mac) but I always have to do a bunch of config (except with windows terminal, thankfully) to make simple things like ctrl+backspace/delete/arrows work and I’ve not really found a way to make cursors act the same.
A bonus would be multi-cursor like vscode/sublime but that seems like a hard bargain!
Does anyone know if this exists for terminals like windows terminal or iterm2?
A terminal emulator is essentially a weird, fairly standardized GUI framework for shells and the other terminal programs that they run — but it’s a GUI framework that provides primitives for defining buttons or text input fields or other widgets but doesn’t define any widgets itself. Even the old-fashioned
urxvtsupports mouse clicks, but it’s up to the shell (or the program that it’s running, if any) to interpret and act on the mouse click.What is your normal editor? Does it provide a terminal emulator or similar? For example, GNU Emacs provides a few terminal emulators or similar, at least one of which, EShell, is not a terminal emulator but a shell that implements its own GUI using Emacs as its framework — and Emacs handles mouse clicks like Emacs handles mouse clicks.
Edit: I run GNU Emacs as a GUI program, not in a terminal emulator.
Ah so the terminal doesn’t actually know/care/control the actual caret? I didn’t know this, that explains why it’s not standard behaviour.
As for normal editor, I meant editors like the one I’m typing in now, essentially any text input on my computer like sublime text, vscode, <textarea>, basically places where all the primitives I’m used to for manipulating text has an expected behaviour: move the caret around, ctrl+arrows to move it by words, ctrl+backspace to delete words, cmd+backspace on mac to delete the whole line, etc.
so if I’m understanding this right, this is basically just the ghosts of the 1970s still making things awkward today 😅
I did try and write a shell once and ran into a lot of ancient “teletypewriter” things which made it a monumental task (then nushell came out and solved everything I wanted to solve anyway)
I suppose that my “perfect” terminal would essentially be a terminal and a shell as a single app that understands all the typical (at least, typical to me) text editing things as well as do the things a shell would do… food for thought, but I guess it’ll never happen due to backwards compatibility with all the old stuff.
thanks for clarifying though!
I guess I would say the terminal emulator knows but does not control. If you click at some position in the line where your shell is taking input, a terminal emulator with mouse support tells the shell that you clicked at that position, and the shell could update its internal notion of where the text insertion point is and tell the terminal emulator to move the visible caret to the new insertion point, but I don’t think typical shells implement that. In contrast, for example, Vim implements that.
EShell is this, for example. You mention VS Code; that might have something similar to EShell.
EShell, for example, indeed is not compatible with, for example, Bash, but such a shell certainly could be. EShell can be run in a terminal emulator, as Emacs can be run in a terminal emulator.
I can’t be bothered much anymore. “everything affects everything else” rings painfully true:
/etc/files to find how its set because no one documents escape codes for terminalsAnd then, there are other aspects that are scary as all gosh, like tab completion for python automatically running files in the current directory (so don’t tab complete in your Downloads folder!). And then finding out bash_completion is massive, un-auditable in turn. Just ended up disabling all programmatic completions for now.
And then you type in
sudo -i/pkexec/sshand its all gone.I do want to go into using
fishoryshthough, partially just to start relatively clean on completion scriptsThe main thing I have a hard time with is that I want to be able to open URLs that are displayed in my terminal using the keyboard instead of clicking on them with the mouse. I have been able to find a total of zero terminal emulators that support this out of the box, and one (urxvt) that makes it easy to add with a small amount of configuration. (I think there might be some that exist, but for my own purposes I won’t use it unless it’s packaged in Debian
apt.)Anyone know if there’s something like that I’m missing? I don’t love
urxvtbut having to use the mouse for URLs is a deal-killer for me.Wezterm supports this with the quick select mode. By default there are only keybindings setup to copy and insert URLs, but the documentation already contains the necessary Lua snippet needed for opening them directly.
Yeah, I really like the look of Wezterm. I will probably switch to it once it gets packaged for Debian, but that will probably take a while.
How up to date are the “modern” tools, and how soon do you usually get them on Debian? I’m on fedora which already pushes close to the bleeding edge. And for a while now I’m just used to tools being in flatpak, so I get a really up to date working environment. E.g. I’m using wezterm for quite a while now.
I remember from… Centos or Ubuntu LTS r something, that it is usually significantly slower, at least it used to be. Not just getting the shiny new tools in the repos, but sometimes it even took quite long for already packaged tools to get updated from upstream. It’s frustrating to know that the bug you reported was fixed months ago but you can’t update it from the repos.
How does Debian fare there? I’m adding out of curiosity, I don’t intend to switch from Fedora for my workhorse machine any time soon.
I usually find what I want in https://backports.debian.org/ or sometimes upstream’s own package repository (eg for llvm)
TBH I’m not even sure what this question means. Maybe that in and of itself is the answer to your question.
I used to build things from source a fair bit, but nowadays I pretty much only find myself doing that for programs that I’m planning to make contributions to myself. Everything else comes from Debian’s apt sources, except Signal which I wish I didn’t have to use, but realistically the alternatives are all so much worse.
Foot has a visual mode where you see all the links highlighted with a shortcut to press to open one. It’s definitely my favorite version of the problem you are describing
Hm; yeah, looks neat but it unfortunately doesn’t work with my window manager. (exwm)
Alacritty has that too and works on X11 as well; the default shortcut is ctrl+shift+o.
Thanks; this looks promising. I think I tried this on my previous machine and it wouldn’t even boot because it needed a more recent OpenGL version, but it runs on my current one.
However, ctrl-shift-o doesn’t do anything, and the docs seem to imply that opening URLs with the keyboard is just a feature of vi mode: https://github.com/alacritty/alacritty/blob/master/docs/features.md The documentation seems … pretty sparse.
I use it all the time not in vi mode, maybe the docs are outdated? And yeah they are pretty sparse, I think you’re better off looking at the default config file.
Maybe you’re running an older version, before 0.14 it used to be ctrl+shift+u https://alacritty.org/changelog_0_14_0.html
That was it, thanks! I will give this a try. I like the hinting system; reminds me of conkeror and surfingkeys.
Not out of the box but st with the externalpipe patch can do it in a very flexible way since you pipe the whole terminal pane into the program or script of your choice. It’s possible to do the same on the tmux side too. Or anything else that can pipe the whole pane into an external command, for example xterm with a custom printer command. The patch link has some examples for the URL extraction.
I was reading it and I thought “if fish doesn’t support this stuff, why bother…” and then I read that fish has pretty much all of it built-in.
My idea of modern is very different:
I don’t use a terminal-based editor, which eliminates a whole class of requirements on Evans’ list for me.
Are you using nushell interactively?
Before I answer your question, I should warn that Nushell does not describe itself as production ready yet. I use it locally for my own personal productivity only. It feels pretty polished to me, but I take the authors at their word. I would not advocate for using it in server environments or any other business critical system until they say it’s baked.
Now, on to your question, I’m not entirely sure what you mean by “interactive.” I suspect you mean TUIs, in which case, mostly not. I use a test runner with interactive commands, but apart from that, I’m mostly running one-line commands and occasionally using pipes to query structured data (e.g. from JSON) or writing one-off scripts to automate repetitive, error-prone tasks. If you mean leaving processes running indefinitely to be periodically checked in on, yes, I do that, although I generally shut them down at the end of the day. I haven’t needed a multiplexer for a couple of years now. According to the docs, pueue and tmux are supported if you need that sort of thing, but I haven’t tried either in nushell yet.
Why do you ask?
Not the original asker, but I would have asked the same question, so I’ll expand. I honestly like
nushelland have used it for extensive scripting work, but I have not had luck switching to it as my daily driver in the terminal. Compared to fish, I miss much of the tab completion (e.g. type “git com”, hit tab, and get “git commit”) and other little touches in the terminal that aren’t connected to the language.The interactive question comes up because I do use nushell, but only in fixed scripts and not interactively. Those nushell scripts are called from my fish shell. I know that I’m not the only person in this position. Honestly, I would like to cut out the middleman and run nu full time and I’ve spoken with other devs in the same position, but the actual shell interpreter just has too many papercuts at the moment. If you’re using nushell full time in the terminal, then I’m hoping you might have some guidance on handling those papercuts.
It sounds like you’re taking @cflewis’ use of the word “interactive” to mean using it as one’s default shell, in which case my answer is yes. Nushell became my daily driver about two or three months ago. I stand by my description of my own experience of Nushell as being “pretty polished.” I have experienced a few paper cuts, but nowhere near enough to discourage me. I can put my paper cuts into three buckets:
curlandjq, I now use the built-inhttpcommand (which can automatically parse various formats including JSON) and the various built-in ways of navigating and querying structured data, respectively.^Rand the Tab key are for. Also, I miss my block-style cursor. Whatever you set your cursor style to in whatever terminal emulator you use, Nushell overrides it with a beam style cursor. I suspect this is related to the history-based completions because you can see Nushell’s history-based suggestions as you type, which only makes sense with a beam cursor.What are your paper cuts?
Your post has inspired me to give it another try. Carapace should solve 80% of my complaints and the history based suggestions were something I had found “missing” the last time I’d tried it. Thank you for inspiring me to take another look - I hadn’t realized how far it had progressed.
There’s a lot of lifting you can do by installing modern drop in replacements of the standard tools, eza for ls, bat for cat being my two “must do first” installs onto a new box. My Fish config aliases them to their original counterparts and then I’m good to go.
Then of course you have just tools that are strictly better but not drop-in compatible like sd for sed, rg or ag for grep etc.
Regarding 24-bit color in a terminal: I am just as happy without it, as long as I don’t have 8-bit color. If you only have 16 colors, you can (usually) set them so that each one looks nice, and they look nice together. If you have 24-bit color, then your apps are responsible for their own theming, and it’s usually fine. But if you have 256 colors, you are just screwed. Apps will try to theme themselves, but fail horribly, while your delightful 16 color terminal themes are just ignored.
Somehow, for reasons I don’t fully understand, 24-bit color terminal support may randomly work or not, and if it doesn’t, it invariably falls back to 256 colors rather than 16 and everything is terrible.
I also need and expect terminal programs to work correctly on a monochrome terminal, maybe with bright/dim, but possibly not. This is becoming increasingly difficult to guarantee.
A long-lived tmux session I can reconnect to + mosh mean my session is there when I want it. Relatedly, nice to have a VPN with easy reconnection–there’s Tailscale free for personal use and WARP at work. I have mouse mode on in tmux which makes accessing its scrollback easier.
I don’t have enough time with these two to say for sure they’re Good Things, but I’ve recently picked up:
bleopt highlight_syntax=in~/.blerc) which at least felt like it helpedble-face auto_complete="fg=242,bg=235"andbleopt exec_errexit_mark=$'\e[91m[err %d]\e[m'Some folks at work said that, for them, it was hard to make an a different shell stick; too many one-liners, etc. built up assuming bash. Not having to change is part of what’s nice about ble. Your situation could vary depending on what you do generally and the maturity and nature of your dev env specifically.
Meanwhile I do not (always) use a modern/fancy editor; I’m one of the how-many-can-there-possibly-be users of joe which I would not recommend to others. Work recently picked up ruff as an autoformatter, which is maybe especially nice to have when the editor isn’t clever.
[Comment removed by author]