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
Addendum: I think I figured it out. After reading the instructions more carefully I assume there are client and server portions, and it's the client portion that is mac-only, and that a WebKit browser should work there. The server portion is pure node.js stuff and the node.js runtime is cross-platform.
This looks cool when everything works, but what happens when you try to `cat` a JSON file with a syntax error? Terminal is already lowest common denominator. If you want a better/easier/user-friendlier way, they're out there, but it seems like doing it in the terminal layer is wrong.
Implicit Evaluation with PHP
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?
Also, the purpose of "cat" is to concatenate files, not display; it just happens to output to STDOUT so that it can be used as part of an efficient tool chain workflow. By consequence, using "cat" on a single file will output its contents to the terminal. This is a useful side-effect, but not its main function.
-dZ.
Carol vs. Ghost
The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.
Not true. Objects can be rendered on the terminal as well. PowerShell does this all the time. For some object types a certain format/method has been registered, but for all other types PowerShell just falls back to default rendering - which is to render the properties. You don't need *any* specific program to write objects in PowerShell. Never. One distinct advantage of this is that you can actually *choose* exactly how you want the objects written without relying on each and every little CLI tool to include a whole battery of output options.
ls|ft lists files/dirs in a table (ft is alias for Format-Table): Each property in its own column.
ls|fl lists files/dirs in a list (fl being an alias for Format-List): Each property on its own line.
ls|fw lists files/dirs in "wide" format (fw is an alias for Format-Wide): Multiple columns with just the name.
The cool thing is that ps|fl works similar: It lists processes with properties on separate lines.
you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.
PowerShell builds upon .NET, COM and WMI, which are all models which supports discoverable objects. One of the first cmdlets a powersheller learns is the gm cmdlet. gm is an alias for Get-Member. This cmdlet reflects and documents the types with properties, methods, events etc of the objects piped to it on the command line. No need for external out-of-date documentation.
This means development and testing is simple, you do it one module at a time, type the input and watch the output. And you can very easily combine different programs in a way that no one tried before.
Well, that is the same way with PowerShell. Even though the pipeline streams objects, the output from the last command of a pipeline is rendered on the terminal using the default or registered format (or you can control the format). But PowerShell takes it a few steps further, e.g. defining common infrastructure for transactions as well as risk control such as executing all cmdlets in simulated "whatif" or "confirm" mode in a unified way and based on context so that cmdlets executing within a script will inherit the mode from the script invocation. The fact that *all* cmdlets support the -WhatIf parameter lets you try out even potentially state-changing scripts and cmdlets before actually executing them.
I don't think powershell offers any advantage over the way Unix has been working for forty years.
Frankly, based on the above it doesn't seem like you know enough about PowerShell to pass that judgement. And having worked for forty years doesn't mean that it cannot be improved. 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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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?"