Re:TermKit: A Rich Graphical Terminal (2011)
by georgia_peach on Wednesday March 02, 2022 @01:46PM
(#30531112)
There's already a growing body of tools that choose JSON as their serialization format, and it all works well enough--even though most shells and terminals are oblivious to it. If the dependency is inconsequential, there you go--use JSON.
Outside of optimizing-away a pipe (built-ins vs processes), I'm not sure if the shell even needs to figure into this.
Several of the newer terminals already support base64 png/gif/jpeg escape codes (ex: https://iterm2.com/documentation-images.html). Get the different projects on-board for a new escape code to handle a full-blown MIME blob (make it work just like image, but w/ mandatory mime type prefix), then everything would be covered.
The boundaries of concern between process/shell/terminal were fairly well-drawn to begin with. Some form of mandatory interchange more structured than "get a byte, get a byte, get a byte, byte, byte" is just going to end up as another VM ghetto like emacs. I like emacs, but one is enough.
there are many ways to implement such an idea, and PowerShell is only one of those ways. I think PowerShell did it well, and I recognize that there could be better ways.
separate the idea from the implementation.
> ...I might not want to commit to another dependency just to output a little text.
how complex of a dependency do you think that would be? "number of dependencies" is not a valuable metric; "complexity added by dependencies" is definitely valuable, so consider that, instead. a dependency which allows textual output, if it somehow weren't already in the pipeline, would be very small indeed, and would add almost zero complexity to the project.
and I don't think individual applications are the right place to add this, anyway. the terminal/shell should know what to do if the object you pass to STDOUT is self-describing.