Slashdot Mirror
Imagining the CLI For the Modern Machine
scc writes "TermKit is a re-think of the storied Unix terminal, where human views, input and data pipes are separated. Output viewers render any kind of data usefully. It may not be a new idea, but it's certainly a new take on it." I know you are quite comfortable in your shell of old, but this sort of thing sure gets my juices going. The best of both worlds.
I like some of this idea, but frankly, it doesn't go far enough. Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.
I would pay good money for a PowerShell implementation on Linux, and even more if Linux internals were exposed in the same way that WMI objects are on Windows.
And this is from a thirteen-year Linux veteran.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
But they can cat an image and see a picture of a cat with a caption! That is totally more usable! ;)
I can has xterm?
In practically any sane terminal emulator, you're not seeing the bytes, you're seeing a picture generated from these bytes by interpreting it as text with embedded control codes. This is merely an extension of that concept; instead of just "clear the screen" and "switch text colour to red" you also have "display the following PNG". Considering that there are tons of different sets of escape sequences in use, one more would hardly be a problem. Since the author suggests that the metadata identifying the data type (MIME-style) would be separate from the actual data, legacy programs would presumably just ignore the additional information and behave like they used to.
Objects can be rendered on the terminal as well
Rendering them is different from the object itself.
Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal
Again, rendering is not the object. I can have a list of different operation I need to do, passing things from one program to the other. If all I can see is the rendering of the last command I cannot see what is actually being passed from one command to the next one.
Developing is incremental. The power of Unix is that this simple fact is everywhere. I need to see all the processes:
ps aux
Which ones are owned by boris?
ps aux | egrep '^boris'
What are the process numbers and creation time?
ps aux | egrep '^boris' | awk '{print $2, $9}'
OK, sort that by process number
ps aux | egrep '^boris' | awk '{print $2, $9}' | sort -n
In Unix I build up my commands step by step. What I learn in one place can be used somewhere else. The same sort command I use for process numbers is the one I use for my phone book.
If I can't remember exactly how awk works I can test it by typing
echo "1 2 3 4 5 6 7 8 9 10 11" | awk '{print $2, $9}'
It would not work if 'echo' showed a representation on the terminal that is not exactly the same thing it pipes to 'awk'
I'll grant that PowerShell is a more natural fit for Windows given that so much of the OS and applications are exposed as objects.
That's a shortcoming of windows, not an advantage of powershell.
Every example you just posted requires you to actually examine the output of each of the commands, and apply brittle and convolted text parsing structures like grep and awk. All of if these break when the author alters the output text format. PowerShell has none of those limitations. If an author of ps adds a new property to each object, he does not need to be concerned with previous users of his cmdlet, because nobody is actually parsing his output. His output is strongly typed objects. If a previous user didn't consume his new property, it doesn't matter, they'll continue to not consume it.
Instead of building scripts based on brittle text parsing, they are built on a self documenting model that provides. There is no text parsing. That's extra work. Why do it?
I've often wanted to have a CLUI that works with my GUI. Imagine I'm in Photoshop, mousing or tablet-ing away, and I have a layer on my canvass. Rather than trying to remember where in the menu structure a bunch of commands are in order to manipulate that layer, I just bring up my CLUI and type something like "resize 50%, flip, gamma -20" Or how about in Word: "Find foo replace bar, insert header from page 2-", and so on?
Why are we forced to find commands in mouse-driven menu bars (of worse, "ribbons" and whatnot) when they could be available any time in the app you are using?
"And the meaning of words; when they cease to function; when will it start worrying you?"