Imagining the CLI For the Modern Machine 317
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.
Advantages of CLI (Score:4, Insightful)
The big pros of a command line:
-Very low resource usage
-Automation via scripts
I thought the whole point of a command line was that you didn't have to look at it while it was doing its automated thing. If you need interactivity, the GUI can handle that. It seems to me like this new interface will suck up too many resources doing something that admins won't be staring at.
But it's worth a shot. ;)
WHOOOOSH! (Score:3, Insightful)
"You can cat a PNG and have it just work."
Uh, no, Doctor Disorthogonality, you broke it. When I cat a PNG I want to see the bytes, not a picture. If I want to see the picture I'll firefox or gimp the PNG, then it will just work.
And fixed-width fonts for data are ideal. Using a variable-width font and trying to od anything is a freaking nightmare.
Re:Meh. (Score:4, Insightful)
The kind of person that loves-vim-long-time is probably not looking for a graphic-enhanced shell, either.
Re:PowerShell (Score:4, Insightful)
I'm not always grepping for filenames. In fact, that's one of the least frequent things I grep for: I can do ls *blah* just fine. But maybe I don't want to fuck around with some syntax I'll only use once every four years, I just want all the files modified in 1997: ls -l | grep 1997. Yeah, that's not suitable for usage in a script, but it's easy, so if I'm not looking for a general, reusable, bullet-proof "solution" and am just looking for output, it's quick as hell.
The examples, while pretty, are ridiculous. If I want to display an image, I can open it in my GUI. If it's actually a common enough operation, I'll write a quick script so I can make it pop up by typing something: showimage blah.png. This, like powershell, forgets that CLIs are user interfaces, and tries to force a bunch of "correctness" that we don't need on us. If it needs to handle weird filenames with newlines and shit in them--here's the critical part that the author is missing--I'll use something stronger than bash. You don't need to use the same interpreter as your scripting language as you do to hack around in a CLI. As for piping from HTTP? Uh, sure, that's neat, but I've literally never needed to do it outside of a script, where the consideration is correctness rather than being easy to remember and quick to type. For regular usage, downloading a file is a wget away.
And why do we need an entirely new UI to fix things like -r and -R? Couldn't you just fix them independently with a small, testable, revertable-if-it-causes-problems patch? Maybe I'm just an old codger, but I don't get this. If you want to separate data handling from UI, separate them, don't try to mash them together into some abortion that's good at neither. Additional standard file descriptors for data exchange? Great, go nuts. Additional standard file descriptors for user frontends? Love it. Re-purposing FD{0,1,2}? You must be high.
Re:cat crap (Score:5, Insightful)
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.
Re:Close, but no Cigar... (Score:4, Insightful)
Piping objects it's a joy instead of dealing with spacing and grep-everything...
I like grepping. Its regular expression syntax gets me exactly what I need everytime and since I actually took the time to learn how to use it, it's like second nature.
I hate all those arcane command line options
They may be arcane to you that doesn't mean they are arcane to somebody else. PowerShell is extremely verbose compared to Bash. That seems pretty arcane to me.
("ps aux" and "ps -aux")
Kind of a silly quibble there.
Re:Everything is an INCOMPATIBLE object (Score:5, Insightful)
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.
Re:Advantages of CLI (Score:1, Insightful)
At least pretend to read the article. He's not putting "pictures in the pipe". Its structured text (JSON) that has a data and view components. At least try to come up with something other than the most obvious dismissal in the shortest amount of time possible.
Re:Close, but no Cigar... (Score:5, Insightful)
It is pointing out the obvious that a file is kind of object, with a certain defined behavior, strong namespaces and associated methods?
Systems like Plan9 [bell-labs.com], where everything literally is a file make the painfully obvious. The only changes would be to make file properties be just more files that appear to live bellow the filename as if it were a directory and get rid of completely foreign namespaces like the network interfaces.
There is some extra syntatic sugar with object systems. The 'object' systems use dot delimited dereferencing for system enforced sub-classing - runtime resolution of the thingy being talked about. The file system's path separators are only meaningful on the filesystem meta-level for object...er...file isolation. Otherwise we are dithering over path separators to namespaces: /path/to/thingy instead of container.subelement.thingy.
Of course, PowerShell has the advantage of an actual design and uniform implementation. Even the traditional Unix utilities produce completely unique output formats that often require regular expressions to pull out meaningful data or at least massage the pipe. This is a possible consequence of unregulated organic growth.
Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output. Instead make STDOUT,STDERR (FD 1 and FD 2) machine-only and FD 3 and 4 be used for human-consumable output. This could be much more flexible. (Of course, like most standards, nobody would have used it in the sake of rolling the next great thing.)
But this highlights that trivially parsable output combined with pure file semantics gives you the benefits pure 'object' environments like Powershell gives to users. So it appears the inconsistency between terminal applications is the real issue, not some mythical object-ness that Powershell proponents claim files don't have. And TermKit's plugins / adapters "fix" that.
After all, what are programing languages but syntactic sugar in our heads, mere mental layers on top of high and low voltages running through some hardware?