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.
This saddens me, I would so want Windows and Linux ports. There's a brief mention that it should work with a normal web browser, and it appears to use node.js, but I am unsure what exactly to do. I haven't done any coding with node.js.
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. ;)
RAM and bandwidth are cheap, why not add tons of bells and whistles? They may not make anything more functional, but they make it more fun, and that's what counts, right? Oh, it's only for Mac? Well that makes perfect sense.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
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?
"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.
The kind of person that loves-vim-long-time is probably not looking for a graphic-enhanced shell, either.
- oZ
// i am here.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
This has lead to "somewhat parseable text" being the default interchange format of choice. This seems like an okay choice, until you start to factor in the biggest lesson learned on the web: there is no such thing as plain text. Text is messy. Text-based formats lie at the basis of every SQL injection, XSS exploit and encoding error. And it's in text-parsing code where you'll likely find buffer overflows.
?
Thus says the guy who's implementing a HTML5 + CSS + JS client / server terminal wrapper. Hey, FYI, your whole TermKit stack is made of parsed text. Indeed, the only way to access your API is via parsed text. As if Webkit (that TermKit is build on) never has any "buffer overflows". Pffffft. Added complexity, more surface for bugs to appear, 'nuff said.
Also -- No thanks. I already have a window manager. I agree that occasionally mouse input is the right choice, and an environment that embraces both text terminal and GUI elements is neat, but I just couldn't stand to read any more of the Hypocritical remarks...
He talks about displaying objects and passing them around as JSON objects -- Yeah, JSON is a textual representation of an object that must be parsed to be displayed.
P.S. Only available on Mac? What the duce? It's just a HTML / CSS + JS interface -- If the guy had any brains you could just point any browser at it and he'd have saved the time of writing a complete client... unless... the goal is to take some elitist (noob) stance regarding UI.
More "Text is Sloppy" hypocrisy:
TermKit's input revolves around tokenfield.js, a new snappy widget with plenty of tricks. It can do auto-quoting, inline autocomplete, icon badges, and more. It avoids the escaping issue altogether, by always processing the command as tokens rather than text. Keys that trigger special behaviors (like a quote) can be pressed again to undo the behavior and just type one character.
The behaviors are encoded in a series of objects and regexp-based triggers, which transform and split tokens as they are typed.
Uhhhggg.
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
I think you have this all wrong. This is not a terminal emulator app, it is an attempt at creating a novel text-based user interface with a lot of the graphical niceties Mac OS X users are accustomed to. It preserves the REPL-style interaction method but replaces text output with HTML output, and replaces line-of-text input with token input.
The author is not on a mission to wean Unix-lovers like us from our Terminal.app, he's trying to make something like it for our friends who admire the power of Unix but aren't able to commit to it.
Graphics in the terminal as you describe is a fundamentally different thing from what's being attempted here. Yeah, we have Ncurses and we have svgalib, but what we do not have is a set of Unix fundamentals that return graphical output to the command line interface, interleaved with the text of the commands. To do so would probably be impossible; svgalib takes over the whole screen, for example, and with ncurses you are dealing with characters rather than pixels. Think of it more as WebKit interpreting command output as HTML. So while a fair amount of the coding effort so far has been in creating the server and desktop app, as time goes on much more effort is going to be spent on wrapping existing Unix utilities to have them return HTML this thing can use, or developing alternatives to the Unix standbys that are substantially different and more amenable to new users and this interface.
One capability the author talks about wanting is a way to highlight the command line arguments based on their relative safety or syntactic correctness. This will obviously require introducing a lot of additional information that just isn't there by itself, much like completion patterns for bash or zsh.
In short, I think you've completely misunderstood what's going on here, and that's why you're missing the point.
You missed the biggest pro of them all, central to the Unix philosophy: Composition of simple tools to do complex tasks.
With a GUI, you are bound to whatever the GUI designer has included, and basic features are replicated endlessly in different GUI:s. For example: If I want to process five files with some program in a command line, I can list them with ls or find, type them manually, or cat the list from a file, just to name a few ways. With a GUI, you often have only the Open File Dialog, built right into the processing program, and that's it. In that case, creating the list of files is not separated from processing them.
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*
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?"