dtach VS nushell

ssh from your favourite terminal to your workstation works fine. (I spent two COVID years working that way.) If you use multiple terminals, look up ssh multiplexing to improve performance a bit. If you want to keep remote sessions alive without mucking up your preferred terminal, try dtach.

Not the same, but I really dig using vim (neovim) as my terminal multiplexer. Vim has tools for managing windows, splits, all the things, and it felt redundant having two separate tools.

The one thing I needed was a way to attach/detach it, and have it survive across ssh disconnects. I struggled for a while trying to use things like reptyr or others. Eventually I remembered/rediscovered dtach, which is a very thin very simple proxy, as opposed to a full on terminal emulator / multiplexer. https://github.com/crigler/dtach

Not really, and for what TRAMP + vterm doesn't cover such as unexpected disconnects, there's dtach and detached.el.

GNU Screen, tmux and dtach (with convenient Emacs interface) all serve to limit that problem.

> What's an opinion you have that most people don't agree with?

> Haha. I specialize in having opinions people don’t agree with :) In kitty, the most controversial is probably that terminal multiplexers are the devils’ gift to mankind.

I cannot agree strongly enough that the virtualized rendering done by programs like screen & tmux is a curse. Trying to get truecolor tmux+ssh+tmux+vim working in truecolor mode is a disaster. Terminal-multiplexers emulate a screen and then render their buffered session to whomever is attached, and it's a frustrating, bad, lossy process. Often the original session and what attaches don't match, and there's not much one can really do. I am not a terminal expert but the situation seems awful, & is one of the highest elder crafts of computing, far more subtle & deranged than one could ever imagine.

Kitty tries to re-build a lot of these terminal multiplexer functionalities itself. It has tabs, it has splits. Generally kitty is a pretty do-all terminal system. Afaik there's not really any way presently to solve the root of these mismatch problems, which is basically that programs generally don't reevaluate their TERM environment variable, even though these environs are technically editable at runtime (by the process, or outsiders).

Kovid (Kitty author) talks about being a vim user. I too am a vim user. In fact, one of my favorite techniques has been to just live inside vim, to use it's terminal emulator, to get ok (i'm still pretty not good) at using it's splits and windows to lay stuff out. The one missing agent for me was that I wanted a way to be able to detach my vim session & come back latter. I spent considerable time trying reptyr & other ways to reattach processes. After much failure at getting vim to detach/reattach, to persist across sessions, I eventually re-encountered a program dtach[1] I'd run into years ago, which works great. Unlike tmux and screen, it's not a terminal emulator. It's just a dumb pipe that a program can render into, and a way to reattach to that pipe again latter. It can run in detached mode so that if your session exits, the program stays open. This way, I can just open vim & have my entire workspace inside vim, with whatever terminals I need, and detach/reattach the vim session at my leisure.

[1] https://github.com/crigler/dtach

So now whenever you execute that command, it will update the channel with the current price. You can then run it on a loop, crontab, whatever you want. One of my favorite things to do is to use while $true loops, and applications like dtach.

i prefer to use dtach for that if I only need this feature

The first method is through downloading the pre-built binaries. With this method, you don't need to install anything other than Nushell's dependencies. Once you've downloaded the binaries, add them to your system's environment path to run it directly in your terminal.

I rather nushell for this purpose, it's more fun to write and easier to read.

https://www.nushell.sh/

These are just three small examples of what this shell written in Rust allows. The features are many and many more, but I'll leave it up to you to discover and enjoy them; I'm currently playing around with it and it's giving me a lot of satisfaction and immediacy, now it has a fixed place among the tools I use when working! The project is Open Source, so if you want to contribute, I invite you, as always, to do so, I leave you the link to the repo here!

Any thoughts on fish as compared to nushell [0]? It's similar to PowerShell in its philosophy and is also written in Rust.

[0] https://github.com/nushell/nushell

> In PowerShell, structured output is the default and it seems to work very well.

PowerShell goes a step beyond JSON, by supporting actual mutable objects. So instead of just passing through structured data, you effectively pass around opaque objects that allow you to go back to earlier pipeline stages, and invoke methods, if I understand correctly: https://learn.microsoft.com/en-us/powershell/module/microsof....

I'm rather fond of wrappers like jc and libxo, and experimental shells like https://www.nushell.sh/. These still focus on passing data, not objects with executable methods. On some level, I find this comfortable: Structured data still feels pretty Unix-like, if that makes sense? If I want actual objects, then it's probably time to fire up Python or Ruby.

Knowing when to switch from a shell script to a full-fledged programming language is important, even if your shell is basically awesome and has good programming features.

Maybe if the "popular" shells, but http://www.nushell.sh/ is looking better and better

Yeah agreed, especially now that PowerShell is available cross-platform.

Nushell[1] also seems like a promising alternative, but I haven’t had a chance to play with it yet.

[1]: https://www.nushell.sh/

I also discovered an existing discussion[1] related to this topic which includes a link[2] to a "helper to call nushell nuon/json/yaml commands from bash/fish/zsh" and a comment[3] that the current nushell dev focus is "on getting the experience inside nushell right and [we] probably won't be able to dedicate design time to get the interface of native Nu commands with an outside POSIX shell right and stable.".

[0] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

[1] "Expose some commands to external world #6554": https://github.com/nushell/nushell/issues/6554

[2] https://github.com/cruel-intentions/devshell-files/blob/mast...

[3] https://github.com/nushell/nushell/issues/6554#issuecomment-...