2 ms·
I've spent sometime thinking about this. My too much coffee hot take is that you'd want to separate the presentation layer out and provide much structured ways
by EthanHeilman 4y ago
I've spent sometime thinking about this. My too much coffee hot take is that you'd want to separate the presentation layer out and provide much structured ways of interfacing with the processes. It would look something like this:
You'd have your high level CLI which would call programs, those programs would provide:
1. input and output in form of JSON services. This would function like a modern pipe functionality,
2. a CLI UI which talked to those services. This CLI can swapped out for another at the callers digression,
3. a built in debugging and code reading system similar to developers console in modern web browsers,
4. and hooks for intercepting calls made outside the program either to the OS or the dynamic libraries like LD_PRELOAD
In some sense it would replace the terminal with a web browser like CLI. Unlike a web browser you'd be able to mix and match CLI UIs and pipe processes together.
I'm not convinced that is a good idea. The beauty of terminals and the power of being about do stuff like process substitution largely comes from the use of simple abstractions. Would a JSON based pipe be less or more powerful than pipes as they are today? I suppose you could always use a utility to strip the JSON and turn it into the newline text streams that the commandline today is so good at manipulating.