Our great sponsors
-
Windows Terminal
The new Windows Terminal and the original Windows console host, all in the same place!
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
murex
A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)
One issue with windows command line I’ve run into recently is text rendering performance. Running cxxmatrix at a high resolution brings even a modestly powerful machine to its knees. cxxmatrix crashes alacritty, but I have found that running VcXsrv and urxvt from wsl yields much better cxxmatrix performance than when running from wsl.
Here is a related issue. There are many cousin issues.
This is something I've been working on with my shell, https://github.com/lmorg/murex
The problem isn't so much finding a way of passing metadata but how do you retain compatibility with existing GNU / UNIX tools? It would be easy to create an entirely new shell (like Powershell) that throws out backwards compatibility but that wouldn't be very practical on Linux/UNIX when so much of it is powered by old POSIX standards.
I addressed this by having a wrapper around pipes. Anything that connects out to a classic executable is a traditional POSIX byte stream with no type data sent. Anything sent to a command that is written to support my shell can make use of said meta data.
As for handling graphical components, that's a little easier. Many command line programs already alter their behaviour depending on whether STDOUT is a TTY or not. I take things a little further and have a media handler function, called `open`, that inlines stuff in a shell that can be (it will render images in the terminal) but if STDOUT is a TTY then it will pipe the image data instead.