Posted
by
CmdrTaco
on Thursday May 19, 2011 @12:26PM
from the now-that's-cool dept.

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.

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.

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.

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.

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.

Not so much that I don't have to look at it, as that it lends itself very well to scripting and automation... automation is good because it removes human error from it. The tools were modular enough that you just build what you needed as you went.

Once it's automated, you don't need to look at it I guess. But, certain kinds of chaining of operations based on the output of the previous

I also think he's onto something great. I've written scripts to add color to my console and found out after doing it for every program that you can handle that all in a few files. What he's done though, is done that for text and everything else. It looks very promising and I would be willing to give it a go when it's ready.

It's also speedier than the full blown mouse-driven GUI. This retains that one. Also ls/grep for navigating is sometimes better/sometimes worse than folder with icons for navigating. This seems to allow you to mix the two. I think the idea is very nice and can probably be tweaked to make it a viable default CLI.

So, you'd like someone to write a natural language shell where you can describe what you'd like to happen, possibly badly, and the shell would magically know what you mean and do the right thing?

I can imagine such a system either completely failing to do what you wanted, or completely getting it wrong and messing things up... so far, we're not so good at writing natural languages to tell computers how to do things.

It actually really is hard to just ignore the "to" and assume that you meant to type "move" (

why not offer an 'easy' path for those who don't have the shortened commands memorized?

Because you would be encumbering every one with a verbose syntax. After just a few times you'll feel it quite easy to remember that 'move' is 'mv'.

Once you learn the short way to do it you don't want to spend the extra effort in the long command. You may think it only takes one second to type, but you forget how many thousands of times you'll be using the same command again in the future.

How do you plan to i18n that thing than? It's ok for English, and even English might lack form in some phrases. Shell has its own language, and it's not a natural language. Whatever tongue you have, you can learn this language, but if you add natural languages into the equation, then you create a big chaos, since you need to implement syntax differently for vast majority of nations. Otherwise while it wouldn't boggle your mind, it would boggle mind of someone else.

"Sure mv is shorter. But why not offer an 'easy' path for those who don't have the shortened commands memorized? Is it really so hard to ignore the "to". It helps people interact with the computer more naturally and it takes an extra 1 second to type. It takes me more than a second to remember mv.

But what if your two files are named "move" and "to"? Then you'd have:

There was a bunch of related research done at Bell Labs
(around the same time that UNIX was coming out of the research organization)
about command line interfaces.
The conclusion was that there were two largely incompatible demands.
Beginners wanted verbose languages and menus from which they could pick options.
Experts
(eg, those who had to use the system for hours every day to do their job)
wanted minimalist interfaces that used as few keystrokes as possible.

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

Some people (like me) prefer it because they can type known commands faster than they can navigate a series of menus. This would be a great addition to currently available terminals for folks like me. I would enjoy the extended graphical capabilities while still being able to type commands.

Note I said 'addition' - I sure as heck want my old-school terminal around at times. The densi

I think the whole point from the author is to value all these pixels on his screen. That is the rational behind his article. Personnally, I just don't care wasting pixels on my screen as long as the job is done efficiently, what the command line most often does just fine with great flexibility and many options for those with enough knowledge of the Unix shell and all the powertools coming with it.

So, my recommendation to this guy would be to buy himself a cheap dumb ASCII terminal and stop whining about w

Other advantages are that the CLI works well over serial lines and SSH, especially low bandwidth and/or high latency connections (you can cut and paste a set of commands and just wait for them to return). Graphic interfaces suck really bad over low bandwidth/high latency (mouse jitter, did I click where I meant to click? did it register the click?). Plus the whole automation bit.

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.

Let me get this straight. He doesn't like wasting pixels. So, he re-imagines a time tested tool that uses MORE pixels to display the same data. Now it does display non-text in the terminal, but why? If you already have a GUI (which you must for this CLI) why not "xdg-open FILENAME" instead of "cat FILENAME"? And it wastes CPU cycles with a pointless java abstraction when it could run on the bare metal.

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.

If you read carefully, it runs on WebKit, but uses OS X to show it off. They've already got it working in a browser, some enterprising soul will just need to generate a small WebKit component to run it on another OS.

Trolling Apple users is always fun. But actually, yeah, I agree that it's a neat perspective and something I would maybe try out, but never something I would use day to day. I'm an old fuddy duddy cli purist that way. Give me putty and some text configuration files over the "Windows, Icons, Mouse Pointer" interface any day.

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 call it a mess of in-band-signaling. Simple example, how many files do you see here:

$ lstest test test

That are two files, not three, one is called "test test". The "data" contains no actual information to tell you that, that information got lost while converting it to plain text. With an advanced shell those wouldn't just be letters on the screen, but actually objects that you can click with your mouse, pipe into other applications, pipe into a file and do other things with it, while still have the she

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.

Or instead of implementing a new language on Linux, how about doing something like a ruby or python shell, with a linux-specific library?

I mean, if you really want to hide all the information in an unbrowseable, non-human-readable object space instead of via a filesystem (where you can at least poke around manually,) there are ways to do so with existing technologies (since it's nothing new on Linux, but shiny new on Windows.)

I'm trying to figure out what precisely is wrong with the "everything is a file" philosophy. Seems to me that it's still around here after all these years and still works well, that it's probably doing something right.

Seems to me that it's still around here after all these years and still works well

That argument doesn't work though. I assume most people here think Windows doesn't "work well." Well, it's still around here after all these years, too...;)

"Everything is a file" may be fine. Who is to say something better can't be made? Maybe everything-is-an-object allows for something better... that doesn't mean everything-is-a-file is wrong. Just maybe it can be improved or a new paradigm can be used.

The argument works, Windows for a long time wasn't as good as the competition and it was very clear to anybody that had used anything else. The only people who thought that it worked well were individuals who didn't actually have to fix it. I remember times when the CDROM would inexplicably disappear or the monitor resolution could only be changed via a registry tweak which would have to be applied every time the computer loaded. Fixing those sorts of problems shouldn't even be necessary. Consequently, I ha

Agreed... PowerShell is how a consistent command line interface should be done. Piping objects it's a joy instead of dealing with spacing and grep-everything...You can even have them being human readable for all those object-scared-people out there. Or hey, lets implement the same thing in python or ruby. Lets begin from 0. If you want all to be a file, so lets be it but at least that the commands have options and structures consistent between them. I hate all those arcane command line options that are not

I tried Powershell a few times, but it seems like if you're not already up to your nose in.NET it is pretty hard to use and wildly verbose. It also seems like it was a little painful on the commandline, more of a scripting language than a shell. I felt like I would need an IDE with autocomplete to really get anywhere in it.

The same thing that happens when the text format output by one program isn't understood by the text input format of a second.

What, I use another tool from the toolkit to filter the text into what I need? That's second nature and very easy once you take the time to learn what is available and how to use it. Kind of like with every other tool on a computer aimed at experts and power users.

Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'

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. With plain text you can see the data structure at a glance, you don't need to get some separate documentation that may be wrong, not up to date, or not even exist.

Plain text is output to the screen and input from the keyboard. Any program that writes text to the console can send data to any program that reads text from the keyboar

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.

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.

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?

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 ha

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

I'll continue this because powershell cmdlets have a general standard.

The whole verb-objectype syntax is pretty cool...but not really needed in the linux community, but what is cool is that they all behave the same way.

Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

Every linux command works a little differently. Wouldn't it be nice if ever command had a --getCMDLineOptionsJSON that returned JSON that bash could use to auto complete...powershell's "tab" will autocomplete --arguments.... At the very least it would nice if they all implemented --version

I agree that that would be cool, though I consider this fundamentally different. But I don't think we're going to see a useful PowerShell for UNIX simply because in UNIX the only thing you can rely on is files. There is no inherent object model underneath everything that you can tie everything together with. On Windows, particularly since reinventing everything with.NET, there is usually an object model underneath, so it makes sense to reimagine the shell from an OO perspective (not too OO though, or it wo

. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

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?

"Coolness" aside, what can be done with these objects that cannot be done with the files? As in, what end result can be achieved, I don't care about syntax.

With PowerShell those objects are.NET or COM objects. Just about every application on Windows is built upon one of these object models. This means that PowerShell can directly use the same building blocks which make up the applications. The applications become scriptable by default without the need to create CLI specific tools to manipulate the objects. Word, Excel etc. are all built this way and lends themselves to "automation" through the object model.

But if we moved to this model, how would I give tips on climagic [twitter.com]? I'd start having to post links to screen shots. I kid. Sounds like this guy is trying to turn the command line into the multilayer net with protocols between the programs.

Especially, when you can simply `open` it on a Mac (opens in Preview.app) or `display` it on Linux (using ImageMagick). I just tried it, by catting a PDF file and that turned out to be rather annoying, because it broke scrolling in the terminal window.

Some of the features are nice, for example the filename completion (way better than pressing tab). But it's missing automation, so basically it's useless.

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.

If by "od" you mean the od command, trying to od anything involves piping it to od. When I cat a PNG I usually type ^C pretty quickly; if I want to see the bytes I'll pipe it to, err, umm, od.

But, yes, there are places where variable-width fonts are suboptimal, even in pure GUI apps; Wireshark would have to do a bit more work to ensure, for example, that the entries for bitfields within a byte/word/etc. line up when using a variable-width font. In a world with variable-width fonts in the terminal emulato

Just being devil's advocate here, but did you actually read the article? Only the view intereprets the bytes which makes sense. If you pass it over a pipe, bytes are sent. I think that is what you meant, because no one actually like cat'ing a PNG in their terminal to see a bunch of garbage that may even break the terminal until you reset it. Or maybe that is a very obscure use case you have?

He separates view from data. Which is okay. Not something I particlarily like or find it useful, being a unix greybear

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.

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.

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.

I don't understand why there is such a push to use grids to display sorted lists. Unity, Gnome 3, Android, Windows Explorer, iOS, MacOSX, etc. (even posix CLI commands such as ls): all of them have default settings to take a list of elements and then break the list up into meaningless rows and display a grid. I find it far too easy to miss important elements in these grids and I observe this behavior in others. Why are grids so damn popular?

This is absolutely correct. It is easier to find an object in a 1d list than a 2d matrix. With a list, you start at the top and move down. You are guaranteed to find your item. With a matrix, you have to reposition your eyes frequently.

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.

This seems to be completely the wrong crowd for this development (it is hugely upvoted on Reddit, though), but one reason this may be an improvement is simply that it can combine the speed of writing a command-line program with the visual appeal of a web or GUI application. Speaking personally, there are many times I write a command line program simply because I don't want to invest the time and effort in a GUI program and a web app just isn't appropriate for the task. With this system, I could just output

The reason terminals are so useful is because they have greater usable information density than really any other interface. The article desperately misses this in its lead about the 2.3 megapixels of display space, and the presumed potential information content. But a terminal has quite a lot of information in it! Far more information--from a human usability POV--than the oversized icons this TermKit uses to adorn every small bit of textual information.

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?

I still use it for my windows stuff.. but i'm sure there's a lot of stuff it can't do. It still gets updated though. I'm a few version behind because, in case this was not yet obvious, I resist change:)

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.

xdg-open opens a file or URL in the user's preferred application. If a URL is provided the URL will be opened in the user's preferred web browser. If a file is provided the file will be opened in the preferred application for files of that type. xdg-open supports file, ftp, http and https URLs.

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.:)

If you actually read the article, you would know that this is implemented in HTML on top of a small NodeJS HTTP server. There's nothing stopping the backend from being made into an SSL-authenticating web service, and then you can have TermKit shells on remote systems without the remote system having to run a GUI.

I think if you want VT-100 support in this program, you're not the target audience, or you're not seeing the possibilities.

Well then it doesn't live up to its billing, does it? I get the distinct impression this is being touted as a "replacement for the tired, old CLI", but if you're on a server, embedded, or other platform where x simply doesn't make sense you'll still be using a real shell.

This is a terminal emulator app, not a "CLI replacement".

But anyway, having used powershell I don't really see the big deal. People go on lengthy diatribes all the time about "the CLI is dead, you're so 1980s" but in reality the CLI is

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.

but it's doomed because adding yet another layer of abstraction for users to learn is not the way CLI geeks like to work, and everyone else just wants pointy-clicky-shiny and would rather die of festering boils than try to remember the string of text to type in.

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

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

I don't think you could keep the old command names, they'd have to be remade. Probably a program called view would be better suited for displaying the intended content in various ways (including reformatting if you want using style configuration) that also has a flag for raw data view or a separate program for that.

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.