mxtty
murex
mxtty | murex | |
---|---|---|
2 | 55 | |
9 | 1,378 | |
- | - | |
8.9 | 9.6 | |
15 days ago | 10 days ago | |
Go | Go | |
GNU General Public License v3.0 only | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mxtty
-
Why does the `reset` command include a delay?
> TERM is already used for determining color support.
It's one of many ways to determine colour support. And arguably the worst of all of the ways too.
- $TERM
This isn't intended to contain colour information, yet that's how it's often abused. Meaning a lot of applications are broken in non-xterm terminals if they happen to use the $TERM variable correctly
- ANSI code: CSI 22 c (Send Device Attributes, ANSI color)
This is the correct way to check for a device capability. But it requires more effort and knowledge of terminals than your average developer has. So is rarely supported by console applications.
- $COLORTERM
This is the modern day equivalent to the device capability API. But also isn't used often
- $COLORFGBG
This was the original env var intended to be used like $COLORTERM, but fell out of favour because, well, nobody bothered to read any docs.
- $FORCE_COLOR
This is an often used standard. Christ only knows why this one exists when we already have 3 other env vars being used this way. Another example of nobody bothering to read any docs
- $NO_COLOR
This is intended to do the opposite of the others and tell applications not to use colour. However even this is often ignored.
----
That's 6 different ways to check whether to colour output or not. Only one actual standard method and everything is only partially supported (if at all) in applications. Hence why applications then need a `--color` flag, which even that differs in support and syntax across different command line tools. And the "default" method you described, $TERM, actually breaks applications on alternative terminal emulators and hardware terminals -- that is unless they decide to announce themselves as `xterm` and in that case that environmental variable becomes entirely useless.
----
> Not sure what terminals do without color support with color escape codes.
They ignore them.
ANSI escape codes are a pain in the arse to parse but there is at least a documented standard way to parse them. Anything that is a CSI (Control Sequence Introducer) sequence, and that includes SGR (Select Graphic Rendition) parameters like colour codes, start with `{ESC}[` and terminate with a character in the range of 0x40 to 0x7E. It's actually a little more complicated than that[1] but that's the gist of it.
So you know what to print and what to ignore.
There are other escape sequences too, the other big one being OSC (Operating System Command) and they're terminated `{ESC}\`, which is usually referred to as ST (String Terminator). That is unless you're xterm, and then you terminate OSC sequences with either ST or BELL (char 0x07).
A lot of this makes more sense if you look at code rather than documentation. So I've made an effort to ensure my own terminal emulator's source code is as self-documenting as possible:
https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...
[1] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_...
-
The New Terminal (Beta) Is Now in JetBrains IDEs
The problem with a lot of these tools is that they fight with the shell to provide the UX enhancements (the comments in this thread are littered with people commenting that this new terminal breaks basic feature X, Y or Z. Really what they should be doing is working with the existing command line primitives as a hook for their UX enhancements.
I know those existing primitives are 50 years old and suck in a great many ways. But the alternative is having a terminal that only works some of the time.
This is field I'm actively experimenting in too. And have already had some degree of success despite the project being only a couple of months old: https://github.com/lmorg/mxtty
My point is this: any refinements to the terminal interface shouldn't break support for terminal applications. But all to often (this term included) form is now prioritised over function.
murex
-
Show HN: a Rust Based CLI tool 'imgcatr' for displaying images
This is how murex works too https://github.com/lmorg/murex/blob/master/config/defaults/p...
- Xonsh: Python-powered, cross-platform, Unix-gazing shell
-
The Bun Shell
I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays)
Mutex does this by having these utilities named slightly different to their POSIX counterparts. So you can use all of the existing CLI tools completely but additionally have a bunch of new stuff too.
Far too many alt shells these days try to replace coreutils and that just creates friction in my opinion.
1. https://murex.rocks
-
Jaq – A jq clone focused on correctness, speed, and simplicity
This is exactly what Murex shell does. It has lots of builtin tools for querying structured data (of varying formats) but also supports POSIX pipes for using existing tools like `jq` et al seamlessly too.
https://murex.rocks
- Murex rocks v5 is out
-
The Case for Nushell
Stable is a problem because a lot of these shells don’t offer any guarantees for breaking changes.
My own shell, https://github.com/lmorg/murex is committed to backwards compatibility but even here, there are occasional changes made that might break backwards compatibility. Though I do push back on such changes as much as possible, to the extent that most of my scripts from 5 years ago still run unmodified.
- Murex
- FLaNK Stack Weekly for 20 June 2023
- Show HN: A smarter Unix shell and scripting environment
-
Nushell.sh ls – where size > 10mb – –sort-by modified
This is similar to how my shell works. It still just passes bytes around but additionally passes information about how those bytes could be interpreted. A schema if you will. So it works as cleanly with POSIX / GNU / et al tools as it does with fancy JSON, YAML, CSV and other document formats.
It basically sits somewhere between Powershell and Bash: typed pipelines like Powershell but without sacrificing familiarity with all the CLI commands you already use day in and day out.
https://github.com/lmorg/murex
As an aside, I’m about to drop a massive update in the next few days that will make the shell even more intuitive to use.
What are some alternatives?
elvish - Powerful scripting language & Versatile interactive shell
nushell - A new type of shell
tidy-viewer - 📺(tv) Tidy Viewer is a cross-platform CLI csv pretty printer that uses column styling to maximize viewer enjoyment.
fx - Terminal JSON viewer & processor
jc - CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell.
zsh-history-substring-search - 🐠 ZSH port of Fish history search (up arrow)
LIPS - Scheme based powerful lisp interpreter in JavaScript
ShellCheck - ShellCheck, a static analysis tool for shell scripts
oil - Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
ngs - Next Generation Shell (NGS)
nnn - n³ The unorthodox terminal file manager