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
Forgive me, but I just don't see the "usability" aspect. How is this more "usable" than what I have now? What the author calls "raw" data, I call data. To me, that is WAY more usable than what the author has posted.
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
The Simple solution in my opinion is to simply have the GUI windows, with a section at the side for terminal.
Whenever the user ls (or dir)'s from the terminal, the GUI changes. If you click on something in the GUI, the terminal automagically puts in the exact path to the object in the GUI.
Best of both worlds, might be fun to do.
Yup, first thing I thought of reading the summary.
Almost funny, Unixy types taking an idea from Windows. I bet that's a hard one to swallow.
"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.
No, there's plenty of copycat software in the *nix world.
:)
But back on topic, I think that to be taken seriously this has to be able to actually replace the console, which of course it can't as it runs in X. If it could do what he's shown with the framebuffer and no xserver it'd be more exciting, at least to me. Implement it as a real shell, so I can edit inittab and use on one or more ttys. I'd be impressed then.
Caveat Utilitor
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.
I like the simplicity of Xterm. It works well with SSH, can talk to endless serial devices (like console terminal login on headless stuff) and can run over a modem. All I need is twm and Xterm and I have a nice lightweight X desktop on a server for installing Oracle. There aren't a lot of dependencies so I can keep the software footprint small. Updates are faster and few.
Now in KDE on a desktop, something like Termkit might be more practical. Don't forget though, eye-candy comes at the expense of resources. You can't have all that bling without giving up cpu or ram. In the end, is the payoff worth it to be able to run a screensaver in your terminal?
All the work that went into the Compiz bling; it's cool but I just don't use it. The exploding windows are neat, I just don't see the point in having a desktop that contributes to my distractions.
boycott slashdot February 10th - 17th check out: altSlashdot.org
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
Except that in PowerShell all of the objects are reflective and automatically have a textual representation, even if one is not provided by the author.
Being reflective you can also see the data structure instantly, clearly defined by type, even if the author never wrote any documentation. Moreso, as all programs are similarly reflective, you can tell all parameters that it can accept as well as all data that it can return without documentation.
PowerShell programs are fully capable of streaming text as well as intermixing object streams with text streams.
As you can in PowerShell.
As you can in PowerShell, except that you don't have to concern yourself with additionally parsing and reformatting those text streams in order to allow them to be consumed. Moreso, as virtually all of the object models that exist within Windows is available within PowerShell as objects, including WMI, LDAP, COM and .NET, you can combine disparate libraries into a single command line treating all objects as equals and without having to write any additional plumbing code.
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.
TFirst, TermKit combines two different "re"-envisionings of the shell.
Some potential users might find one of those ideas useful (realizing that having command output intended to be parsed by humans or by other commands can result in output that's not as human-readable as you'd like and not as software-parseable as you'd like, a notion that also showed up on LinuXML/XMLTERM and, as noted elsewhere, in PowerShell) and another not (the moving beyond a text interface). The latter doesn't personally interest me; if I want to tweak something from the GUI, there's already GUI code for that - if I want to do command-line stuff, I don't need each command-line token looking like a GUI widget with icons attached to them, I don't need pipe bars looking like big blobs, etc..
Perhaps there's a market for the second part, but I'm not sure what it is. If it helps people who could usefully use a command line learn it, without getting in the way of people not frightened by the command line, then it might be worth the effort.
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*
view already exists - it's equivalent to 'vi -R'
Half of the power in Bash is the ability of the various commands to not only output to text but to take their input as common text from standard in or a file. Usually the text is passed around and filtered between several discrete commands before whatever it is you are doing is accomplished. In PowerShell, can text be passed around, piped, grepped, sorted, etc. as well as in Bash?
As I said, take a look at it. With three decades of use and development behind it, I'd expect Unix to have several tools which haven't been replicated for PS. Yet. But there's nothing can't be done (since everything also is text), and quite a number of things that can be done a great deal more easily and robustly, thanks to being one level of abstraction higher than raw text.
A good idea is a good idea, no matter its source.
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.
What does this have to do with PowerShell? PS uses an ordinary character grid terminal, same as bash. It processes binary data (.NET objects actually) instead of text, but all user interaction is limited to 16-color fixed-width text. No graphics, no IntelliSense. TermKit is designed around traditional Unix commands and seems to have much loftier usability goals--syntax highlighting for your commands, easier escaping, showing you relevant documentation automatically... I love it. This is what PS should have been.
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?"
No... so I could click somewhere on the command line and the cursor would move there.
Is it because you cannot tolerate the mere thought that somebody at Redmond actually came up with a cool innovation over the traditional shells?
I think it's more the arrogance and presumptuousness with which you PS boosters speak of its supposed superiority as if it is a forgone conclusion. We get it, you like it. It uses objects. Some people prefer the text stream and don't see the objects as superior. I know, what a concept, right? For people well versed in bash, grep, awk, cut, sed, etc. are very comfortable and efficient tools. You people remind me of the mono-ites that just can't bear the thought that someone doesn't see your pet project as the holy grail of computing.
The soylentnews experiment has been a dismal failure.
First of all, how exactly can an open source hobby project be "doomed"? Doomed to what, not receiving wide acclaim?
Secondly, it's a false dichotomy between users and you know it. What about all those people using LaunchBar and Quicksilver? They like typing commands and using a Mac, which is a combination you seem to think can't exist. LaunchBar's even commercial software! The truth is that there are lots of users who prefer the keyboard to the mouse but nevertheless find UNIX intimidating. There are also users who like UNIX but wish it were more graphical. Two of my closest friends are a designer and a small business owner, and they both have UNIX servers they have to occasionally do light administration on, and they would both much rather use this if they could. Logging in to a remote Linux box does not automatically open up Vim or Emacs for most people. Most of my compatriots would rather copy the file locally, edit it, and copy it back.
Opening the terminal does not make you an expert at it. There are plenty of people who agree that it is more productive yet still find it hard to use and don't have the time or patience to turn UNIX into their hobby. This program is a very interesting tool because it actually targets them, people who use UNIX without loving it or who simply haven't been corrupted into thinking that the only way is the UNIX way.
If you haven't yet, I hope you'll check out Plan 9 and see that even the authors of UNIX didn't see it with this much absurd reverence. There's no terminal in Plan 9, and the mouse plays a very big role in the interface, yet the very people who gave us shells, terminals, command line editing, "visual" editors and everything else you hold dear, did just fine without them and with having to actually click on things to get work done. The Plan 9 shell has no editing, no history, no curses interface. There's no vi clone, no pager. They were comfortable relying on the GUI to provide those features; they simply did not need all that stuff. It's quite an experience.
Translation: it's foreign to me and I don't want to learn it. There is nothing convoluted about any Unix command once you learn how to use it. Grep and awk are second nature to many people. That's a particularly weak and, quite frankly intellectually dishonest argument when presented to expers and power users like many people on Slashdot are.
I know them. I've been using Linux since the mid 90's. i write kernel drivers for fuck's sake. PowerShell commands are self discoverable. Man pages are auto generated from thedocumentation stored with the commands themselves. If anything is weak it's your argument that I don't know the commands.
The core utilities have been going strong for 30-40 years and most changes have only added features not taken old ones away. You have no idea what the future has in store for PS so that too is a weak argument.
Well, you just made my point for you. In that sentence you acknowledge that I'm right. Only a small set of core utilities have had non-altered output for the last 30 years. I'd like to point out that 'ps' at least has been altered a few times in the last decade. ifconfig, same. Replaced with 'ip'. So you admit, Unix utilties break when the author changes them.
My entire point about powershell was that you don't have to know what changes are in store in the future. Didn't I mention that? You can add properties without requiring downstream users to be concerned with it. That's the point I made. You missed it, I guess.
There is nothing PS can do that can't be accomplished by streams of text. The Unix model is very simple, every argument I've seen against it has amounted to little more than strawman bs,and unlike your flavor of the week utility, it will be here long after we are all long gone.
There's nothing that C can do that can't be accomplished in assembly. Really? This isn't even an argument. It's a basic fallacy.