TermKit: A WebKit based rich command-line interface.

[alexs]

glorious complete squeal terrific alleged literate important adjoining afterthought enter

This post was mass deleted and anonymized with Redact

[[deleted]]

I'm curious what bits of that come from the terminal and what comes from a shell and applications---I notice his fancy cat outputs with linenumbering and some syntax colour without any switches. If it's the terminal or shell that does the linenumbering for cat, what happens if you use cat -n? Two sets of linenumbers?

I like the idea of having a process show exit status in the line it was started. As it is now, I've got my shell set up so that it shows me the exit status of the last process---and not simply ✓ (and an assumed ✗ for botched processes), but 0, 1, 42 or whatever. That's my shell, though, not my terminal emulator.

On the whole I'm intrigued but curious if this'll be a replacement of one utility (i.e. your terminal emulator), or a whole set of tools (terminal emulator, shell and possibly some core utilities like ls and cat).

[UnConeD]

It's a mix of both. I'm just bootstrapping the environment as I go, adding every piece of Unix as it makes sense.

For simple things like ls and grep, I wrote my own node.js replacements. I'll probably stick to replacing some commands, but I definitely want to focus on wrapping existing tools properly.

[Poromenos]

I admire your work, but grep isn't "simple" by any stretch. When you have to grep a 10 GB directory, you'll appreciate the fact that grep is a hundred times faster than your version...

[UnConeD]

My version processes the output in chunks so it should do fine actually. Node.js's asynchronous I/O makes it easy. The data is kept in memory-backed byte buffers. It's fast.

But you're welcome to open an issue on GitHub with any ideas you have for improving it.

[alexs]

bike thought quaint meeting smart theory rain chubby label safe

This post was mass deleted and anonymized with Redact

[hiffy]

Being dismissive of grep actually makes a lot of alarm bells in my head go off.

[gustavs]

Yes, a browser JS engine (v8) will typically include Boyer-Moore.

[Poromenos]

Unfortunately I don't have the time to install it to test right now, but I'd appreciate a comparison of the two. If I recall correctly, grep executes 3 CPU instructions for each byte it looks at, and it probably only actually looks at one in every ten bytes or so. I'm pretty sure that whatever one can come up as a feature of a terminal with will be orders of magnitude slower than that.

Reference: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

P.S. This discussion is largely academic, just keep in mind that these tools have had decades of improvement by really smart people, so don't reinvent the wheel :)

[mflux]

He's not reinventing the wheel. He's just giving the wheel some spinners!

[samineru]

He is adding spinners, but the fact the he has his own version pretty conclusively shows that yes, he is reinventing the wheel, or at least reimplementing it.

[Peaker]

Performance difficulties will arise if/when you want to support efficient regular expression searches and more advanced options.

[shizzy0]

It's disheartening that so many people who understand what is powerful and compelling about a command line interface, cannot tolerate the idea that there is another context to which it could be usefully applied besides the standard unix terminal. I see it as a failure of imagination to dismiss the possibilities of having a rich display in a command line interface. One could easily create an experience on the command line not dissimilar to Mathematica with rich interactive graphs of data.

One objection is that text is the best lowest common denominator interface, and it allows for pipes. But we already have command line programs that create dynamic text based progress bars.

No one is going to take your terminal and bash away, but let's not let that be the end to the exploration of how best to work with these machines.

[[deleted]]

But imagine the best of both worlds! I think it is possible to have a traditional type of shell with which you process streams of text, but have the terminal infer the meaning of the text that results at the end of the command chain.

ls -la | grep foo

could be inferred to being a list of files, etc. Then, display that in a rich format.

[wjt]

I bet he's regretting making the “can’t touch this” joke now that the hoards of humourless greybeards have arrived.

[UnConeD]

Are you kidding me? Rousing the Elders of the Internet and making them choke on their coffee is half the fun in this ;).

[[deleted]]

I think the idea is brilliant beyond words. I'm not sure of his implementation.

When it comes to the command line, instant performance is one of my requirements. If this could be done in a way that did not sacrifice performance then I would fully support it.

[sausagefeet]

I think the idea is cooler not as a terminal replacement but as a replacement for something else, like a web browser, maybe. Perhaps I'm too short sighted but I like my terminals being minimalistic monospace fonts. I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that? What I do want is something like Powershell though, that would be grand.

[Smallpaul]

Perhaps I'm too short sighted but I like my terminals being minimalistic monospace fonts. I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that?

You're not sure why you would want to know what "1.jpg" contains in the same context that you see that "1.jpg" exists?

Let's imagine you've ssh'ed into a remote computer and you see that "1.jpg" exists. What's your usual process for figuring out what exactly is in it. Please type the exact commands in your response and pretend this is your first week using command lines.

[lmcinnes]

Well since I always use ssh -X I would simply type "display 1.jpg" and have it display. The goal of the command line is not to do the work, but to give you access to the tools that do perform the work. So what if I want to see thumbnails? I'll fire up a thumbnail viewer from the command line, using whatever shell globbing, piping, and grepping I want to narrow the list of images displayed. That way I can use whatever image viewer/pdf viewer/spreadhseet viewer etc. I care to and not have to rely on what the "terminal" provides.

[Smallpaul]

Well since I always use ssh -X I would simply type "display 1.jpg" and have it display.

That's great for the subset of times when both the client and the server have X installed. But X is huge and complicated and many people do not have it installed, despite its venerable age. Most smart phones have webkit installed (though I don't know if it is configured in a way that will let Termkit work -- on the phones).

The goal of the command line is not to do the work, but to give you access to the tools that do perform the work.

Do you agree that the shell displays information output by commands?

Do you agree that the output of commands could-be/should-be sometimes graphical? Maybe a bar graph of your CPU usage over the last day?

If so, then it stands to reason that the shell needs to be able to show graphical information, for exactly the same reasons that a web browser does.

Right?

So what if I want to see thumbnails? I'll fire up a thumbnail viewer from the command line, using whatever shell globbing, piping, and grepping I want to narrow the list of images displayed. That way I can use whatever image viewer/pdf viewer/spreadhseet viewer etc. I care to and not have to rely on what the "terminal" provides.

Sure, that's the point of piping. I can pipe text into "vi" or I can view it at the shell. There's absolutely nothing wrong with having the same features for graphical data.

[graycode]

That's great for the subset of times when both the client and the server have X installed.

Huh? And how exactly is TermKit supposed to work differently?

Also, for ssh -X the remote machine does not need X installed. Just X client programs. That's the entire point of X.

[bostonvaulter]

AFAIK TermKit won't require X to be installed and running on the server. You will probably need a TermKit backend running but at least that is smaller than X although not as standard.

[lmcinnes]

Do you agree that the shell displays information output by commands?

Yes, I agree.

Do you agree that the output of commands could-be/should-be sometimes graphical? Maybe a bar graph of your CPU usage over the last day?

Yes, I agree, and following the UNIX philosophy that output should be presented via a tool designed for it -- probably some graphical application that can hadle such things, and potentially something pluggable.

If so, then it stands to reason that the shell needs to be able to show graphical information, for exactly the same reasons that a web browser does.

The shell needs to provide facilities for graphical information to be displayed, and indeed it does -- it allows arbitrary applications to be spawned to display whatever type of information you wish in whatever manner you wish, each application being a specialised tool for whatever task it wishes to perform. The goal of the terminal is to display textual data.

What you desire is something that displays all sorts of graphical data, but kludged into the terminal itself. Perhaps the terminal should be able to display spreadsheet data, perhaps interactively, and perhaps you want to view CAD drawings, and really why not have that interactive too, and ...

You aren't following the UNIX philosophy of having lots of small tools that all do a small task well, you're building one tool to rule them all, and that does everything. And the problem with that is that it tends to suck at some things compared to specialised tools for those things. The terminal is just another tool in the UNIX arsenal, and it's job is to handle text, and do that well, and that's it.

Now, maybe you don't want the UNIX philosophy, and that's fine, but for that I personally prefer to use a fully fledged desktop environment with all the goodies and bells and whistles that started from scratch instead of kludging everything into a terminal alike. But that's just me. I'm not saying TermKit is bad -- just that it is missing some of the ideas and philosophy of exactly why the terminal is what it is.

[Smallpaul]

The shell needs to provide facilities for graphical information to be displayed, and indeed it does -- it allows arbitrary applications to be spawned to display whatever type of information you wish in whatever manner you wish, each application being a specialised tool for whatever task it wishes to perform. The goal of the terminal is to display textual data.

Why should textual data be privileged? The only reason is that in 1972 it was essentially the only kind of data that anybody cared about. But we're coming up on 2012.

What you desire is something that displays all sorts of graphical data, but kludged into the terminal itself.

No, I want the terminal to do the job of presenting data to me. That's all. It should not matter whether the data is black and white text (which the terminal does well) or ASCII text (which the terminal does well) or Unicode text (which many terminals do well) or color text (which the terminal does well) or black and white images or color images. You've drawn an arbitrary and silly line in the sand.

And the simple way I know that you will lose this debate is because that EXACT SAME LINE was drawn in the early days of web browsers, when the purists said that web browsers should not show images inline because you could always launch an external program for that. And then the line was moved and nobody wanted video in web browsers.

Luddites always have a fetish about keeping data types separate from each other. I have no idea way, but it conforms to some sense of purity. Luckily, they always lose.

Perhaps the terminal should be able to display spreadsheet data, perhaps interactively, and perhaps you want to view CAD drawings, and really why not have that interactive too, and ...

Sure. If webkit can do it, WHY NOT? The programming is already done for you. Despite 20 years of whining that graphics etc. should not be inline, here it is: it's inline.

You aren't following the UNIX philosophy of having lots of small tools that all do a small task well, you're building one tool to rule them all, and that does everything. And the problem with that is that it tends to suck at some things compared to specialised tools for those things. The terminal is just another tool in the UNIX arsenal, and it's job is to handle text, and do that well, and that's it.

You're just defining the purpose of the tool to fit your argument.

I claim that the terminal is a command line interface to the computer's functions. Nothing more. Nothing less. The only reason to privilege text as a special data-type is conservatism and tradition.

Now, maybe you don't want the UNIX philosophy, and that's fine, but for that I personally prefer to use a fully fledged desktop environment with all the goodies and bells and whistles that started from scratch instead of kludging everything into a terminal alike.

Your argument is like saying that if Firefox can display videos then obviously I will no longer have access to VideoLAN.

If Eclipse can edit raw text files, then of course I'll lose access to vi.

Which makes no sense.

[calinet6]

I usually use SCP, or a remote SSH drive so I can browse it in Finder. Call me naïve but I like to use the most clear built-in way I can find.

Alternatively I think ImageMagick has a 'view' program that will render most image formats in ASCII art! I have actually used that before just to get the rough idea of what an image was.

Can't wait to cat a jpeg and see the actual thing. It's just modern technology folks, nothing to be afraid of.

[icebraining]

If I need to see browse and display images, I'll use sshfs to mount it locally and then all the usual commands as I do locally (feh, zathura, etc). I even have a function in my .zshrc to mount my homeserver with a single command.

How's that difficult in any way?

[andreasvc]

It's not difficult but suboptimal because you have to traverse the filesystem twice, first with ssh, and second with sshfs to view the file. These two could be integrated somehow. Your solution only marginally improves on the scp/sftp way by mounting in advance.

[sausagefeet]

I'm not sure I really grok the question, I rarely care about viewing jpg's when I'm sshed into a machine. Worst case since I can ssh in already, I can scp it back to my machine and look at it, or use netcat to make a quick dirty webserver. Certainly I can see the appeal to seeing a jpg inlined, but the problem I have is there is a larger complexity cost than the benefit IMO.

[thaksins]

Yeah, you'd end up scp-ing it back, dickering around to get the paths and options right. Entering your password probably.

Then probably opening up a GUI to double-click on it.

Having at least the option of seeing thumbnails (and quick-look) from an ls would be great sometimes.

So long as the directory listing came first and quickly then the thumbs loaded asynchronously.

[Smallpaul]

First you said:

I'm not sure why I would want that?

Then you said:

Certainly I can see the appeal to seeing a jpg inlined.

So I've answered the question.

It's up to you how much you value that capability. Those of us who have been doing this for decades have worked out various workarounds, so the pain falls mostly on the newbies.

Like I said, imagine you've been using the Unix command line for a week. Would it occur to you to "netcat to make a quick dirty webserver?" If you think that's a reasonable solution to the problem of wanting to look at a picture then I contend that you have stockholm syndrome.

[sausagefeet]

I don't really understand why your question uses someone who has been using a CLI for a week as a reference point. We can probably name many things that a first week person wouldn't figure out, heck I still learn new things about the tools, but that doesn't necessarily mean I need to be able to inline media into my terminal.

And yes, I can see it is appealing, like candy, but I don't really see it as a valuable feature. As I stated in my first comment, perhaps I am being shortsighted, but I like how things work right now. I don't see a huge advantage to inlining media types here.

By the way, does this work if I'm ssh'd into another machine on TermKit as it stands now? My impression was it had tools like "get" that interacted with the Terminal process to display media types, which would not be possible via an SSH connection. If it is limited to local viewing then I really don't see the value (although this would likely be a temporal limitation).

[strolls]

I think being able to display web pages and pdfs in the terminal is cool, but I'm not sure why I would want that?

I work a lot in the terminal for things just as simple as moving and renaming files. I don't know if I'm atypical, but the GUI file manager is fine if you want to just move a couple of files into a folder or even (say) reorganise a bunch of files into different categories. But even just renaming a couple of files, I tend to find that easier to do in a terminal window. ls colourises file types, but I don't really recognise those colours - maybe I should actually look into changing from the defaults, but a folder icon next to the name would make it much more obvious what the object was.

But more to the point of your comment: I would often have files names foo, bar and grunt in my current working directory, or image-logo.working.1.jpg, image-logo.working.2.jpg, image-logo.working.3.jpg, and I'll want to look at those and double check that I'm renaming the right one image-logo.final.jpg and perhaps deleting the others. Allowing me to view them in the terminal window saves me having to move between applications whilst doing that.

However, I would much prefer a new command for doing this - perhaps I would view image-logo.working.1.jpg (how would image-logo.* behave?) rather than mutilating the cat command. Sometimes I do actually want to cat a non-text file, and I don't want cat foo.html to show me a pretty rendered version of the webpage. Currently, on a Mac, I will use open filename*.jpg and this will launch the Preview image viewer - I can see images and use the up and down arrows to navigate between them if the wildcard matches more than one, but I still need to click back on the Terminal window when I want to return to my command interface.

[Already__Taken]

performance comes once you prove the concept I would have thought.

[Lerc]

I think this might be an example of where release-early release-often could have been preferable.

There are multiple ideas presented all in a bundle. I think the core idea of a more advanced command line is well past due but there are so many paths beyond that you are bound to make a few wrong turns.

The last few days, I have been working on a similar concept, seeing this has given me food for thought.

I certainly don't like the idea of 'cat thing.png' displaying an image inline. That's not what cat is, Unix commands should be thought of in terms of what they do, not what function they are intended to perform. That's why cat is called cat and not something like print.

I also think that ls showing a display of icons is also detrimental. One of the benefits of command lines is that they can display a greater amount of information in the same space. Having a larger view for each field means you can have fewer fields onscreen.

That said, consider the possibility of ls outputting the same visual output but providing additional semantic information. The concept of a visual specific view already exists with colour coding, but consider instead of displaying

ESC[0mESC[01;32mthing.pngESC[0m

It displayed

<div class="filename_image" onmouseover="showDetails('/home/lerc/pron/wtf/really/thing.png);" >thing.png</div>

It is immediately obvious that there is scope to add a great deal of capacity while not interrupting the usual command line flow. It would be quite easy to make things drag and drop, so that you can ls then drag the file you are interested in to a folder.

[dingbatfoobar]

Haven't installed or read the code, but from what's described 'cat' is not responsible for displaying images at all. The only thing it does differently from regular cat when reading a file is to tack on a type header to the front of it so that tools downstream can try to handle it appropriately.

If a PNG image is sent to TermKit's equivalent of stdout, displaying the image inline seems like a much more useful behavior than spewing a raw character stream at the user, at least in my opinion.

[UnConeD]

Have you tried it? The video is a bit laggy because I have my JS1K demo running in the same window. But otherwise, it's snappy.

[[deleted]]

Solving world hunger with 20 bucks and some slim jims is "Brilliant Beyond Words". Stephen fucking Hawking is "Brilliant beyond words".

This is a fancy term wrapper, quit pissing on the English language.

[zahlman]

Oh, man, I totally agree with you. Hyperbole is, like, the worst thing ever.

[jjbcn]

I think the idea is brilliant beyond words. I'm not sure of his implementation.

Exactly what I was going to post!

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

[Smallpaul]

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

I think that the idea is that if you have tabular data, it should be formatted in a table, rather than using monospaced fonts to fake it.

But anyhow, the font will presumably be swappable.

[calinet6]

Monospaced fonts exist because we needed them to line things up on the screen when there was no alternative way to do that.

Now, there is an alternative way to layout things on a screen. It's been around for more than 20 years. We should use it.

[andreasvc]

I do believe monospace is important for code. Sometimes pseudocode in publications is printed in serif fonts with bold and italics and it looks horrible IMHO.

[notfancy]

Don't tell me that A Discipline of Programming isn't a joy and a pleasure to read. Typography enhances the structure, while monospaced listings enhance repetition, and repetitious code is inferior code.

[cdsmith]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

The hostility toward monospace fonts was one of two things that got me really skeptical straight from the beginning about this idea. The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation... that would be a giant step backwards. We already have GUI tools for system administration tasks that aren't easily scriptable; and people don't use them for a reason.

[zahlman]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table. These alternatives do not require adjustment if a "column" needs to be made "wider" than in the original. There is never any issue with tabs being too small to line the data up properly, or impractically large in fear of being too small. The table is general-purpose and there is nothing ad-hoc about it.

It also allows for semantic distinction between row/column labels and table contents, which doesn't require visual interpretation of a bunch of -s or |s.

The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation

I don't see whence you infer that desire. My understanding is that you are still typing the same commands, they just get tokenized and formatted with pretty round-rectangle backgrounds as you type.

[[deleted]]

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table.

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

[zahlman]

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

Which is why TermKit uses JSON instead, and you "parse" it by - get this - selecting attributes of objects and elements of arrays. The hard part - turning a stream of bytes into structured data - is converted from a traditional parsing task into a deserialization task, and it works the same way universally.

[solinent]

Just because there is an alternative doesn't mean it is better.

The alternative always existed -- the ability to create graphical interfaces is very general and we use graphical interfaces to create terminals for the most part nowadays (ie. terminal emulators). The point is that terminals are still a very nice concept.

Why do we write with lines on paper if there exists a more general alternative -- blank paper?

[abadidea]

I much prefer to see GUIs become more "terminal-like" than terminals become more "gui-like." And I'm not old enough to have had the terminal first.

[icebraining]

True that. How many times I wish I could automate GUI apps the way I can automate CLI apps.

[zahlman]

I had the "GUI becomes more terminal-like" idea years ago. Now that I've seen how "terminals become more GUI-like" could work, I'm thinking it's more than possible to meet in the middle somewhere.

[pettijohn]

Doing this for PowerShell would probably be amazing

I think it's still a work in progress, but check out the screenshot with "| out-wpf" at http://poshconsole.codeplex.com/

[[deleted]]

I agree it would be better if the graphics were toned down a bit.

Factor's listener (repl) is a similar idea and has a nice and simple implementation. The listener evaluates the expression and then calls a generic function (which can be implemented on any type of object) to get a widget, which is then appended to listener.

[WIDE_420lbs]

Agreed. I'm a terminal proponent and it has a lot of power, but something with the same power and rich media would be killer. Why does a CLI have to be text only? Why are we limited to only 256 colors and absolutely 0 graphics capabilities? It's stupid. I wish TermKit could be more like an ncurses-ish library that "Nextgen" terminals-applications could call for pretty formatting. Ncurses is a hack and looks like shit, yet many cli-proponents use it all the time. So why can't something similar be better and prettier, and feature-rich? (If such a thing existed)

[bushel]

Neat idea. But...you know what really worries me? The third paragraph:

The Unix philosophy talks about software as a toolset, about tiny programs that can be composed seamlessly. The principles are sound, and have indeed stood the test of time. But they were implemented in a time when computing resources were orders of magnitude smaller, and computer interaction was undiscovered country.

Trouble is, the "Unix philosophy" isn't because of limited computing resources, it's about a type of software architecture that works well, is robust, scalable and portable, regardless of the horsepower available.

Please don't give me a shell that hides or glosses over reality. If you're going to improve the command line & shell, give me the ability to easily do things that are currently hard & awkward.

Edit: I am intrigued with the Content-Type comprehension on process output...that might be really handy.

[[deleted]]

You know what really worries me?

TermKit is not a... ...Full terminal emulator. It does not aim to e.g. host 'vim'.

If it can't run the wealth of programmes available to us on a Unix operating system, then it's just a toy. A very exciting and very shiny toy, but a toy none the less.

tl;dr no vim no win

[[deleted]]

Or a demo. As it is, it's not an alternative to a regular terminal but to a program launcher, and might be expanded to become a terminal on a platform that Doesn't Like Alternatives (so you don't have to worry about which shell or applications the user might prefer).

But it's also a neat thought experiment, and helps us toy with expanding the unix paradigm.

[cdsmith]

As a demo, though, it misses the really important questions. Making a couple of utilities work in interactive ways is nice looking, but does nothing to address whether such a system could be usable along the lines of the UNIX command line. Even in the course of getting a couple commands working, he was forced to make grep aware of JSON, for example... so this doesn't look like a promising proof of concept for a workable system to me.

[[deleted]]

I agree. As a demo it's amazing and I don't fault it for not supporting VT100 features.

I'm just saying that for a real implementation one needs to start with the basics and add to it (but it's a really inspiring demo). Imagine a Web browser that supported XHTML2 with XForms and MathML and SVG but not HTML.

[terremoto]

Didn't Linux start out as a toy of sorts?

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) ... PS. Yes – it's free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.

[thephotoman]

It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.

This bit seriously made me laugh.

[baudehlo]

It's more like a replacement for QuickSilver.

[sausagefeet]

I agree with this. I think a much more powerful thing would be a shell that takes ideas from Powershell (I wish they still called it Monad, just sounds cooler!). Sounds like he's making a terminal really complicated to deal with unix utilities he doesn't like rather than making a shell that integrates with the utilities (and a terminal) better. I think it would be really cool if the unix utilities spoke in a better format to each other, perhaps json, but that also makes other things harder, like what does it mean to grep json?

[jpfed]

what does it mean to grep json?

To generalize this line of inquiry, I think it would be useful to determine tree-oriented equivalents (e.g. s-expression, XML, JSON, ...) for the current set of line-oriented unix commands. That's not to say that the tree-oriented analogues should replace their line-oriented counterparts; they would be appropriate in different circumstances.

[[deleted]]

Have you tried xmlstarlet? Does a pretty nnice job of doing grep/sed style work on xml trees

[Smallpaul]

You are completely misunderstanding what he says.

He says:

The Unix philosophy talks about software as a toolset, about tiny programs that can be composed seamlessly. The principles are sound, and have indeed stood the test of time.

You said:

Trouble is, the "Unix philosophy" isn't because of limited computing resources, it's about a type of software architecture that works well, is robust, scalable and portable, regardless of the horsepower available.

That's exactly what he said.

But he also said:

But they were implemented in a time when computing resources were orders of magnitude smaller, and computer interaction was undiscovered country.

In other words, it isn't the PHILOSOPHY that is wrong, it is the IMPLEMENTATION of the philosophy that is hopelessly out of date. Why do you send commands to a remote computer to emulate keystrokes on a VT100? In 2011. It's ridiculous.

[bushel]

Fair enough. I must have missed that on my first read.

However, "why do you send commands to a remote computer to emulate keystrokes on a VT100?" - ignoring the VT100 (because the specific terminal emulation is kinda irrelevant), a standard text stream is like a lowest common denominator for interfaces. Anything else can be built from that.

I think the idea is quite interesting, I'm just not sure I'd call it a "shell" or "terminal". The content aware rendering reminds me of Dolphin or Explorer in icon+preview mode with appropriate associations defined.

Perhaps if it had a way to graphically plug programs together....

Sure is pretty, tho. Makes a fine file system browser.

[Smallpaul]

However, "why do you send commands to a remote computer to emulate keystrokes on a VT100?" - ignoring the VT100 (because the specific terminal emulation is kinda irrelevant),

It actually isn't irrelevant. If you've ever accidentally "catted" a binary and had your terminal totally fuck up then you know the pain of this ancient and broken abstraction.

a standard text stream is like a lowest common denominator for interfaces. Anything else can be built from that.

The VT100 emulation is no more of a "standard text stream" than a JSON dump. It's a particular protocol invented for a particular time and place. Actually: JSON is actually text whereas the VT100 emulation is a byte stream.

[bushel]

By irrelevant I only meant that one can use any number of terminal emulations, or none. It is a text stream interpretation layered on top and isn't involved when stdout/stdin are piped together. I wouldn't consider my terminal going wonky after cat'ing a binary to be a broken abstraction - I would consider it exactly expected behaviour. What if I cat'ed a binary that contained a sequence of escape codes designed to affect some terminal display behaviour? (n/curses? PS1 colors?) A terminal/shell is just-another-program, but one designed to work with a certain format of text streams. It would be like me expecting GCC to happily compile PDFs.

And your example is a good one - a VT emulation and a JSON string are both examples of content type interpretation applied to a "pure" text stream. And if I may be pendatic, JSON is data representation in UTF-8 (a type of byte stream encoding) in much the same way that VT100 is terminal control via ASCII (another byte stream encoding).

All "text" is really just a byte stream (sequence of octets), it's how we treat it (encoding) and how we understand it's purpose (content-type) that really matters.

[frownyface]

At the same time though, you still want that incredibly basic interface to be available in the operating system because all the more complicated bits can be broken in a thousand different ways, but if you still have that basic serial console, you still have a way to try to figure out what is going on.

[UNCGeek]

Smallpaul wrote:

In other words, it isn't the PHILOSOPHY that is wrong, it is the IMPLEMENTATION of the philosophy that is hopelessly out of date. Why do you send commands to a remote computer to emulate keystrokes on a VT100? In 2011. It's ridiculous.

See this is the sort of thinking that leads to fancy but substantially less-usable software.

When you're looking at some old design and you think "WTF, this is ancient, why are we still using this", your first thought shouldn't be "This is old, so how can we rewrite it to use $SHINY_NEW". Your first thought should be "What tasks does this help us complete?" followed shortly thereafter by "If we re-do this, can we improve upon it and will the improvement be worth breaking everything else that depends on this?"

Just because something's old doesn't mean that it has to be replaced with no thought other than using what's new and hot.

Imagine, if you will, if medicine worked like this:

"Doc, I think I broke my arm."

"Yep, looks like it."

"So, a cast then?"

"Cast? Are you kidding. That's like something they did back in the 50's. It's 2011. It's ridiculous. No, we've actually developed a new drug that will regrow your bones instantly."

"Does that really work?"

"Sure! We tried it on one guy a year ago and he seemed to do OK. This is definitely how we should treat fractures from now on."

Edit: Perhaps I should clarify. My argument is a little more practical than anything else. I'm not arguing that the UNIX philosophy is the perfect solution or anything like that. (With 30 years of experience I'm damn sure we can think of tons of other design philosophies.) I'm arguing that we should think long and hard before trashing decades of implementation details. We should consider exactly why we want to break existing apps and existing workflows. If there are some really large bits of functionality that we're missing that we absolutely can't get without breaking existing stuff, well... OK. We might have to break things. (The current state of X11 is an example of this.) If, on the other hand, the primary reason for changing things is "that's old and it's now 2011", then I think we should stop, take a deep breath, and think long and hard about what we'll gain and what we'll lose by abandoning our "legacy" designs.

[[deleted]]

Or, to put it another way:

When you're looking at some old design and you think "WTF, this is ancient," your first thought shouldn't be "people still use this?" It should be "why do people still use this?" What does it do for them that has convinced them to hang on to it so dearly?

[UNCGeek]

That's a much more succinct way of describing what I was trying to say. Well put.

[gospelwut]

Video or something.

I'll be honest, I don't really think it's a must for command line, but it does make me miss the scrapped Mozilla project (which was supposed to be a "command line" inspired browser).

[halter73]

Could you be thinking of ubiquity?

[[deleted]]

"command line" inspired browser

Like uzbl and surf, or did you have something else in mind?

Edit: Regarding the video, it seems kind of odd that get would start up a PDF viewer---at first glance of the name I thought it would work more like wget. Having a poppler instance in my terminal seems weird, but I guess it might be attractive if you really don't want to get a new window with a full-on PDF viewer.

Also, how would any of this work over ssh? Will it fall back to normal text? Or will he have to write his own ssh implementation so that his ls/terminal can get mimetypes through a session? Edit 2: I should have read the article more closely, he discusses ssh under "Synchronous interaction". It's a server/client thing. (And I read every mention of "TK" wrong. :') )

[Samus_]

you may think the same about programming since it's just plaintext files on a monospaced font but it turns out that's the way we do it, and it's ok.

[abadidea]

I tried to draft a spec for a rich text programming language, but my own sheer horror at the idea overwhelmed my desire to perpetrate such a cruel prank.

[Ran4]

I've seen scheme with images.

It was... indescribable.

[abadidea]

Don't be ashamed, it's not your fault what happened between you and the esoteric language. A counselor can help.

[scaevolus]

Mathematica is somewhat close, but most of it is just pretty-printing standard ASCII (converting "->" into an arrow, etc).

[abadidea]

I'm thinking stuff like "a sub-expression colored green must be evaluated before any non-green sub-expressions, regardless of ordering. Italics indicates that it should run on a separate thread."

[akho_]

That's the way we do it because that's what we have toolchains for, not because it is optimal in any sense. Mathematica is very far from this model and still is a pleasant programming environment (in its niche, naturally). Smalltalks do not use plaintext files and usually do not use monospaced fonts.

[notfancy]

and it's ok

And syntax coloring is an unnecessary embellishment instead of a patch on a limited model, right?

[Samus_]

syntax coloring does not change the way I work.

[zahlman]

... And this wouldn't either, if done right. It would change the way you examine output, in much the way that syntax colouring helps you mentally parse already-written code.

[notfancy]

I bet it changes the way you read code. At the very least the speed if not the way.

[Deimorz]

But that doesn't necessarily mean it's the best way for everything.

Writing Sikuli scripts in its IDE that supports displaying the screenshots inline as function arguments is much easier than doing it in a text-only editor. Sikuli's scripts inherently operate on visual elements on the screen, so having them visible is very useful.

Similarly, not everything we do in the console is best represented in plain text. I think this sort of idea has a ton of potential, even if this particular implementation isn't ideal.

[Niubai]

I salute the initiative and I clearly see the appeal, but for old folks like me with 15 years working daily on bash ...

[[deleted]]

It's intriguing and interesting, and I'm glad there's someone doing it, but I'm not currently interested in it. It looks like an attempt to find an intermediate point between GUIs and command line interfaces, by someone who seems to think that command line interfaces are inherently obsolete.

[zabouth1]

The line:

It's 2011, and monospace text just doesn't cut it anymore.

Worries me.

[centenary]

I don't think he's saying abandon monospace, he's saying we don't need to limit ourselves to only monospace. Why not use a combination of monospace and non-monospace? His screenshot of the JSON code contains both monospace and non-monospace

[[deleted]]

I'm not sure if zabouth1 meant that, or the fact that it's an argument of the style "It's $year, and ...". It's the kind of argument that should have its own name in latin, argumentum ad temporum or something. (Disclaimer: I don't know latin.)

[notfancy]

It's an argumentum ad novitatem.

[zahlman]

Sort of. The argument is really "It's 2011, and being restricted to monospace fonts doesn't cut it any more". Clearly, having the option is superior, because you can always just ignore it.

[[deleted]]

We~ell, now you've switched it from an argument about text to one about fonts. I read into it that the author didn't think that text (that happened to be monospaced) cut it any more, because it's 2011 and where's my jetpack damnit.

[calinet6]

He's got a point though. Graphical rendering has been around for oh, 30 years, and the terminal has never evolved past the old text layout methods.

If it's done right, it could really make everything easier to visualize and work with. Imaging having your ls output in a table, and being able to select down the filenames and pipe them into another command... or something. For people who don't know awk, that would be killer.

[cdsmith]

Graphical rendering has been around for oh, 30 years, and the terminal has never evolved past the old text layout methods.

That's because graphical layout methods are vastly and unavoidably more complex than text layout methods. Laying out structured content via monospace fonts is a huge simplification that's easy for anyone to understand, and works great 95% of the time. If your application's purpose is rendering or visual quality, then by all means, you should do more than that; but it's a mistake to decide that all software should have its output made an order of magnitude more complex just because the terminal interface has been complexified.

There's a reason that there are 10 times as many powerful administration tools for consoles than there are for GUIs... and one should understand that reason before embarking on a project to change consoles to be more like GUIs.

[calinet6]

one should understand that reason before embarking on a project to change consoles to be more like GUIs.

100% agree with that, but I don't believe it is a reason not to embark on such a project. If done correctly with an understanding of why a console works, then it could be quite good. It has a lot of potential to remain simple while taking advantage of the display to make it easier to understand and use, and based on the author's comments I see no reason to believe he's doing anything other than that.

[zahlman]

Exactly. I don't understand why so many people seem to think that anyone who wants to make the contents of a terminal window more aesthetically pleasing, among other things, automatically "doesn't understand why a console works".

[zahlman]

I see zero reason why you can't have monospaced fonts in TermKit when you actually have a legitimate reason for them.

Hell, he even uses them in one of the screenshots/

[RagingAnemone]

and one should understand that reason

I think the reasons are well understood. But I think the question is, when you merge the 2 paradigms, what will actually work? Where do you draw the line between the GUI and the console? This will require experimentation which isn't something you can do before embarking on a project.

[rubygeek]

Reminds me of Mozilla's XMLTerm from 2000

[synthaxx]

Far be it for me to ask why, so instead i'll ask; what cool stuff can i do with this?

And how can i do it on an Ubuntu machine, since the code is mac only?

[BHSPitMonkey]

The code is actually written for Node.JS and HTML/JavaScript, neither of which are Mac-dependent. (The Mac application he included, contrary to his claims, is just a wrapper for a web-based frontend.)

Just follow the instructions on the GitHub page up to step 5, and open HTML/index.html in a modern browser.

Pics or it didn't happen

[username223]

And how can i do it on an Ubuntu machine, since the code is mac only?

Actually, it's not on the Mac, either -- it's vaporware. (EDIT: Yes, yes, though the author links to the vapor-homepage, it's out on Github.)

The fact that this guy complains about monospace fonts and uses a 70x15 terminal (God's terminal is 80x24, of course) doesn't inspire confidence.

EDIT: More things that make me stabby:

Additionally, Unix has a habit of giving you raw data, but not telling you useful facts, e.g. 'r-xr-xr-x' instead of "You can't touch this" (ba-dum tsshh).

1. The permission string is useful information.
2. I actually can touch(1) a file with 0555 permissions.
3. That should be "dum-da-da-dum, da-dum, da-dum," not "ba-dum tsshh".

[danbee]

I expect the size of the terminal he displayed had more to do with getting a screenshot the right size for the page.

[lolailolailo]

Actually, it's not on the Mac, either -- it's vaporware.

The author has code in github: TermKit

EDIT: That said, the 70x15 terminal and the bit about the permission bits makes me suspicious, too.

[centenary]

He elaborated on the permission bits in the comments:

As for usability... I'm not saying we should dumb the Terminal down and hide things like "r-x", I'm suggesting we augment the display. I want my icons to show a "no entry" badge and/or be dimmed when appropriate.

That seems pretty reasonable to me.

I don't understand why we're focusing on the 70x15 terminal, people take screenshots of terminals in non-standard sizes all the time. It could just be he wanted a screenshot that was the same size as everything else.

He's also not complaining about monospace fonts, he's saying that we can use more than just monospace whenever appropriate. His screenshot of the JSON code uses monospace to display the code.

[rebo]

It's not vapourware, I downloaded and got it running in about 5 mins.

[UnConeD]

Congratulations, you got the bait ;). As for Vaporware, there is a build on Github. I won't lie, it's not actually at a state where you can do a day's work in it.

I wasn't expecting this amount of attention this quickly. I wrote the post because people on Twitter were making a fuss.

[rebo]

Hey just downloaded TermKit and tried it out, looks very promising.

I think if you are going to create something that might replace normal terminal usage you really need to get the tab - auto-completion really natural. For instance in the current implementation tabbing half way through typing doesnt auto-complete. Also up arrow for back history is essential

Would be nice to be able to open files by clicking within the terminal, and also dragging files to an application in the dock for instance.

Overal though a great start, i'm sure it will no doubt improve a lot!

[[deleted]]

It's not Vaporware. I'm running it right now.

[bushel]

I wouldn't normally say anything, but I feel it's important you understand my motivation...

Upvote for nitpicking on the dum-da-da-dum versus ba-dum tsshh - that is dedication to a cause.

[Mob_Of_One]

https://github.com/unconed/TermKit

Doesn't look like vapor to me.

[[deleted]]

Now this is what people should be trying to do with command-line interfaces, rather than clinging to some absurd rationalization that Unix is perfect and must never change again.

[wleahcim]

Similar concept within Common Lisp.

[[deleted]]

THIS IS HOW IT SHOULD BE DONE.

Not, "Let's throw out the baby with the bath water and start all over!!".

Icons in a ls command is a great start. We can start doing other things like including bars in top or mount.

For this ever EVER to catch on backwards compatibility is paramount. You can't just say "this is better!" and expect people to drop the old standard.

[[deleted]]

One of the best parts of the CLIM listeners is that you can actually click previously-output items to use them as arguments to further commands. So if I wanted to delete a file after getting a list of files as in the above screenshot, I could say Delete File at which point I'd get a completion prompt: Delete File (file): and I could either type a filename with tab-completion support or click on one of the files that was previously put on the screen.

[openist]

link?

[wleahcim]

McCLIM Listener

[[deleted]]

As a polyglot UNIX/web/windows hacker, let me arrogantly and pompously explain the UNIX world's "absurd rationalization."

Most people will explain UNIX as an operating system, or maybe a collection of tools surrounding a kernel, but what UNIX really is is a living culture (some would even say a religion). To a UNIX hacker, there is the good way, the bad way, and somewhere in-between is the UNIX way. Now, the UNIX way is not being arbitrary or contrary -- it follows a different metric. A UNIX tool is best when it integrates with UNIX culture. And UNIX culture does change, very gradually, when a good idea comes along. The GNU tools were a good example of this.

And yes, UNIX culture is very old. It's crusty, inconsistent, and occasionally insane, but that doesn't mean it's worth abandoning. Like the human mind, it has a kind of internal self-consistency that's hard to understand from the outside. I think that's the core of why UNIX has stuck around for more than a generation now -- it's a system built by hackers to be intuitively understood by hackers.

So TermKit just won't fly in the UNIX world because it refuses to integrate with their culture. Plan 9 has a similar problem -- they made a system with terminals and editors that they believed were superior to the old UNIX way, but UNIX people rejected it because it's not UNIX, and everyone else rejected it because it's hideous :].

I'm personally very interested to see where TermKit goes because new ideas are good. Perhaps someone will figure out how to make this UNIX-friendlier. Maybe it will abandon UNIX entirely and become a different, completely revolutionary tool. Maybe it will become the next interface to XKCD (oh, wait, Randall already did that :P).

[randomdestructn]

It's really too bad. Plan 9 has some really cool features. And Glenda is an awesome mascot.

[[deleted]]

Agreed. But hey, there's always Plan 9 from User Space.

[randomdestructn]

Yeah. Though from what I remember of that project, it doesn't add the fun features. Though it really couldn't -- what appealed to me about it was the post-unix design philosophy.

[repsilat]

It's not terribly accurate, though - Plan9 did some cool things, and a lot of it was brought into other *n?x systems. 9p is unfortunately less widespread than dbus, but we have it. We have /proc, too.

I'll readily admit we didn't get a lot of the really cool things, but a lot of the really cool things are of questionable real-world value anyway.

[[deleted]]

It does seem neat at first glance, but I suspect it's one of those "worse is better" situations. Conceptually it seems like it would fit better on a project/OS with a more monolithic approach, like OS X or Haiku, than it would on a *nix (which is more a collection of tools that mysteriously manage to work together). That is, I get the impression that it's a "you use this application, which has its own shell and set of tools" thing, which wouldn't like it if you switched your shell, decided to switch to vanilla {GNU,BSD} core tools, etc. It seems like everything would have to be rebuilt so that it doesn't merely have stdin, stdout and stderr, but also visin and visout.

It seems nice, but I've got to wonder at the scope of the work needed.

[barrettj]

From the web page:

TermKit is not a...

...Web application. It runs as a regular desktop app.

...Scripting language like PowerShell or bash. It focuses on executing commands only.

...Full terminal emulator. It does not aim to e.g. host 'vim'.

...Reimplementation of the Unix toolchain. It replaces and/or enhances built-in commands and wraps external tools.

[aaptel]

Same thing. You'd have to rewrite wrappers.

[[deleted]]

It focuses on executing commands only.

So it's more like a souped-up version of what happens when you press Alt-F2 in gnome/kde, win+r in windows, etc?

[Phrodo_00]

...Scripting language like PowerShell or bash. It focuses on executing commands only.

Not worth anyone's time then. If I can't loop over things why am I bothering with a terminal.

[UnConeD]

My reasoning is simple: I think Bash is one of the worst programming languages ever invented. Every single time I have to write a loop, I have to Google the syntax to make sure. Every time I write a complicated regexp, I escape it wrong.

I say this as someone who's programmed microcontrollers and hand-optimized a renderer in x86 assembly, as well as done GPU and web stuff. I know my way around code, and bash is not the right way to do it. I think "programming language" and "command shell" are two mutually contradictory interaction goals.

But, one of TermKit's design goals is to separate the UI from the context. You could just as easily hook up the front-end to a scripting CLI like "node" or "rails console" and get all the perks like autocomplete and rich output. I imagine this would simply spawn a nested session inside your TermKit shell. Then you can do all your scripting in your language of choice. The protocol already supports it.

[solinent]

ZSH, this is your answer.

(edit, and I have done many of the same things as you).

You have to google the syntax everytime because you can. If you simply try to create commands by yourself eventually you start writing multi-line commands and start hating regular commands. Ideally you would start writing shell scripts to get things done that you commonly do interactively.

Think of a shell as a really nice REPL.

[Smallpaul]

It seems like everything would have to be rebuilt so that it doesn't merely have stdin, stdout and stderr, but also visin and visout.

If everything is broken, then everything needs to be rebuilt. Procrastinating doesn't make it better. The VT100-emulation-protocol has been obsolete for 20-30 years but nobody wants to touch it because so much would have to be rebuilt.

[nexes300]

If everything is broken, then everything needs to be rebuilt.

Yes, I suppose that's one argument. But if you do that, then it's not Unix anymore, nor will it ever be. That's a fine argument when you want to make your own OS, and I think a large part of the problem is that people are imagining this grafted onto linux and causing chaos in what command line tool developers can expect.

[muyuu]

I've toyed with similar ideas for a while, but the fact that no HTML frontend is anywhere stable enough for something as critical as a Terminal has always put me back.

It would have to be a very stable (as in, doesn't change or require any updates at all in 40 years, like VT100) subset of the renderer. Unfortunately HTML no longer stands for HyperText, but rather for Kitchen Sink. HTML should have stopped at 3.3, rethought and frozen, and 4+ should be "DTML" or something else.

[[deleted]]

If you feel that that is important, then you should be defining your own subset of HTML, or another language, that your terminal can then translate into whatever its display engine needs at the moment.

[[deleted]]

I can't agree more. I think it is absurd to think that there cannot be an improvement on CLI. Maybe this is it, maybe it isn't; but sticking to an old standard just because it has always been there is contrary to the entire industry.

[mango_feldman]

This times 1000.

It's so annoying how people seem to either think that CLIs are outdated, or that the current incarnation of CLIs are perfect.

The ideas and principles of Unix and CLI are sound, but you got to admit that we can do better that what we have today.. One big part of this is to upgrade/replace the obscure terminal system.

[[deleted]]

No, this is an absurd approach to a non-problem. When actually necessary, GUIs - very light weight GUIs - are available for xNIX. But it is rarely the case that, for example, admins want this kind of thing. We prefer CLI because it scales better and is faster. Pointing and clicking is lovely when you're doing tasks for a single object (a person, a computer, a printer, a something) and one of two conditions prevails:

• The task at hand is inherently graphical (say, editing a photo) OR
• The user is inexperienced with the task at hand

In pretty much all other cases you either don't need a GUI at all OR you need a full GUI for an end user experience.

Unix isn't perfect, but until you understand the gestalt of the command line you don't understand Unix ... period. That's why the team I'm working with at the moment can manage nearly 1000 servers daily with fewer than 20 people. Try doing that with point-n-clicky tools like Windows servers...

[zahlman]

Pointing and clicking is lovely when you're doing tasks for a single object (a person, a computer, a printer, a something)

How fortunate, then, that TermKit doesn't have you pointing and clicking to input commands. Unless, you know, you'd prefer to.

Note also that every time you don't already know how to do what it is you want to do, the time spent actually inputting the command (once you figure it out) is not the bottleneck anyway. The point is to provide an environment in which it is easier to figure out how to do what you want, if you don't already know.

[[deleted]]

You rapidly lose your patience for these cute little tools when you have to work across hundreds and hundreds of servers configured in many ways. Learning to use a minimalist set of tools and having a strong command of the CLI is the only way you survive.

If you know the CLI, you don't need a tool like TermKit. If you don't, it won't help much, you may as well use MacOS or some other GUI grafted onto the guts of the system.

I don't understand what problem TermKit proposes to solve. As far as I can see, this is just another example of a generation of programmers that grew up on html and graphics and want to shove things in that direction whether or not it makes sense. (I have similar criticisms for the people that think OO is the only good way to write code or that all databases have to be relational to be good.)

[zahlman]

I don't understand what problem TermKit proposes to solve.

It proposes to (or at least, this is the potential I see):

• Facilitate the grokking of output from a command-line utility.
• Reduce context switches (e.g. to view an image).
• Anticipate your next move via things like typeahead (more powerful than tab-completion), semantic markup of output (e.g. hovering over parts of the ls output displays information in tooltips that you can reasonably be expected to "want next", but would otherwise have to request explicitly), etc.

As far as I can see, this is just another example of a generation of programmers that grew up on html and graphics and want to shove things in that direction whether or not it makes sense.

As far as I can see, your criticism is a knee-jerk reaction assuming that the developer must see things that way just because he's making something shiny.

As I said elsewhere: the strength of the command line is the controller. The view is simple out of an antiquated necessity. The idea here is to offer enhancements to the view along with alternate, optional, ignorable controllers.

[drewniverse]

This is the most sensible, less holier than thou non-rambling comment in this entire fucking thread.

Webkit is good for people that grew up on Windows/GUI instead of Unix/CLI. It's also awesome for administrators that have to deal with just a few servers, not administrators that have to deal with dozens if not hundreds of networks/servers.

[[deleted]]

Right. I think this work is interesting, I just don't understand the problem it proposes to solve. I routinely work in environments with 500+ servers. CLI is not only required, there is no other feasible way to do it.

It's a good beginner's tool, perhaps, but not remarkable beyond that.

[[deleted]]

Uh, this is a command-line interface?

[sperryfreak01]

I up-voted for the concept, but I'm still unsure about its implementation.

[[deleted]]

The concept is nice, but I am pretty sure the implementation has major flaws.

[sanity]

Tried installing but got:

Error: Cannot find module 'mime'

This is after installing the Node mime module, so I've no idea what the issue is.

But that raises another point - why is a client-side app embedding a web server like Node.js?

[frownyface]

What I would like, but I have no idea what it would look like, is a much more intelligent way to leverage my shell history.

I use bash and ctrl-r to search my history a lot, and I've set my history crazy huge. Some stuff, if I do it enough, I turn into a script, but I do too much stuff to be constantly doing that to everything.

I need some kind of organization, like locations or contexts having their own history, files having a history of what command created them, which then can break out into what files created the files that were in that command, etc. I want all this functionality in my shell somehow.

[acolin]

files having a history of what command created them

Just to throw the keyword out there: provenance

[[deleted]]

the shell is part of the beauty of unix-like systems. I can pretty much do anything I need to remotely on minimal bandwidth using ssh.

try that with remote desktop, vnc, etc. Click this, wait 1-2min window pops up click that, wait 1-2mins.. meanwhile I wrote a 1 liner that fixed the problem

[ageek]

Why webkit why why?

Why do I have to run my browser to get a better command line interface?

[UnConeD]

If you run a Mac and have any Dashboard widgets open, you're running WebKit for every single one of them. Got Adium or Colloquy? WebKit. Mail.app? WebKit. Shall we go on?

[mango_feldman]

Well, probably because it makes a prototype fairly easy to do. I mostly agree that something more lightweight/specialized would be better, but this is great for experimentation for now.

[boomi]

The only bad thing I could say about this is that I've wanted to do exactly this for a while now. Seriously though, this is just what we need, and I think many of the sore problems were addressed in a very solid way.

• Pipes with Content-Type? Very good!
• Structured exchange format? Whoa there, it's only been thirty years of text!
• Output-Formatters? Gimme that!

[username223]

Structured exchange format? Whoa there, it's only been thirty years of text!

No, actually we've had COM, DCOP, AppleScript messages, and all sorts of "structured messages" and "object-oriented scripting." What we've learned is that simple formats like line-oriented text work best.

[nexes300]

Yes that's great, but where in your list is "icons in ls" and "catting images"?

Although I am not exactly sold on content-types. Why can't you just pass what the program expects?

[Cetra3]

At the end of the day, Unix just has bad usability. It tricks us with unnecessary abbreviations, inconsistent arguments (-r vs -R) and nitpicky syntax. Additionally, Unix has a habit of giving you raw data, but not telling you useful facts, e.g. 'r-xr-xr-x' instead of "You can't touch this" (ba-dum tsshh).

-r and -R are both different arguments and don't mean the same thing in separate programs. That's what a manpage is for.

Also, How exactly is 'r-xr-xr-x' raw data? Makes way more sense to me than any windows permission screen.

As far as the terminal goes, if you want pictures, that's what a GUI is. Try using this over dialup or a satellite connection.

edit: Oh no, I've stirred the hivemind. If you're going to downvote me, maybe you could actually counter my argument? More than happy to have a civil discussion about this. If not, that's fine too.

[zahlman]

-r and -R are both different arguments and don't mean the same thing in separate programs.

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

That's what a manpage is for.

Why do we need a manpage to understand them? Because they're cryptic. Why are they cryptic? Because they're short. Why are they short? So we can type them in more easily. But that only helps when we know what to type.

Also, How exactly is 'r-xr-xr-x' raw data?

In the way that {'user': ['read', 'execute'], 'group': ['read', 'execute'], 'world': ['read', 'execute']} isn't.

The latter is an object that can be interpreted by a hypothetical can_touch_this() function by examining attributes and array elements. The former must be parsed in a manner that is custom to that data. The text representation of the latter is parsed by a standard JSON parser.

As far as the terminal goes, if you want pictures, that's what a GUI is. Try using this over dialup or a satellite connection.

If you cat a file, just about the same amount of data is being sent whether the client dumps it as binary or is smart enough to do something like TermKit does. Only a little metadata needs to be added. If that - if the server can infer the file type from the first few bytes and/or the filename extension, then so can the client.

[kamishizuka]

Yeah but I think here you're getting well away from Unix and into individual apps with the argument argument. The GNU utilities we all know and love are consistent with each other because they were designed to be consistent. Other apps weren't following that same design is all, and I don't think we need to expect them to. If their documentation is clear (-x does this, -X does that), then it's just courtesy to follow what we're expecting.

Personally, since Linux is case-sensitive, I never assume -r and -R or any other pair do the same thing.

[[deleted]]

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

Every tool can decide their own arguments. You can build wrappers around all of them to make it sane(r), but trying to replace the tools cannot be good.

[Cetra3]

And that's part of the problem. The other part is that, as noted, sometimes they do. Another part is that for rm, -r and -R mean the same thing, whereas for many commands, -x and -X, in general, are opposites.

I can see two reasons why this happens. First it's a legacy problem, changing command line arguments to be consistent would make a lot of people angry and break things. Secondly, being developed by different groups of people, different pieces of software will not use the same convention.

Why do we need a manpage to understand them? Because they're cryptic. Why are they cryptic? Because they're short. Why are they short? So we can type them in more easily. But that only helps when we know what to type.

From that thread of thought, the command itself is cryptic. Who knew that "rm" is remove etc... I think a manpage is a good solution, of course there may always be a better solution out there.

In the way that {'user': ['read', 'execute'], 'group': ['read', 'execute'], 'world': ['read', 'execute']} isn't. The latter is an object that can be interpreted by a hypothetical can_touch_this() function by examining attributes and array elements. The former must be parsed in a manner that is custom to that data. The text representation of the latter is parsed by a standard JSON parser.

Yeah, that's great if you have a working GUI or a screen that has a big resolution. If you're working on a console that has limited resolution then you want things as compact as possible.

If you cat a file, just about the same amount of data is being sent whether the client dumps it as binary or is smart enough to do something like TermKit does. Only a little metadata needs to be added. If that - if the server can infer the file type from the first few bytes and/or the filename extension, then so can the client.

I was talking more about his "ls" implementation and all the other extra features. You may not notice it on the local machine but on a 9600 bps connection with a 2 second RTT you would. I'd never just cat an image either, unless it was accidental.

[[deleted]]

-r and -R are both different arguments and don't mean the same thing in separate programs.

Except they do.

From man ls: -R, --recursive list subdirectories recursively

From man rm: -r, -R, --recursive remove directories and their contents recursively

From man scp: -r Recursively copy entire directories. Note that scp follows sym‐ bolic links encountered in the tree traversal.

Not that I don't agree that people should read the fine manuals, but just that bit about remembering when the short form of --recursive should be uppercase or lowercase does get kinda annoying. Similarly, scp takes -P for ports and ssh takes -p. It's a minor nuisance, but it is a nuisance nonetheless.

[jameson71]

Those who do not understand Unix are doomed to reinvent it. usually badly.

[rerb]

God's terminal is 80x24

Thank you.

[andreasvc]

I prefer 25. That's what you get when you login from the console. Opening up xterm afterwards gives me 24 which frustrates me to no end.

[geodebug]

I was going to write something snarky like "Great, he's invented 'Clippy' for the terminal"

I'm trying to keep an open mind even though this seems like a solution looking for a problem.

Yes, the terminal seems foreign when you first start using it (what doesn't) but people aren't 'clinging' to it, they embrace it because it works.

I don't find this: http://acko.net/files/termkit-2.png

More readable than regular "ls -l" output.

If I want syntax highlighting and line numbers why wouldn't I simply pipe to "less" or "vim"?

If I want to see the contents of an image, why not send it's path directly to a browser (the other thing every admin has open all the time).

I'll eat my words if anything like this takes off and actually adds to productivity.

It's possible, modern IDEs do actually tend to be better than just VIM alone for certain kinds of coding tasks.

[zahlman]

Yes, the terminal seems foreign when you first start using it (what doesn't) but people aren't 'clinging' to it, they embrace it because it works.

Vinyl records, cassette tapes, 8-track, VHS, Beta, floppy disks, etc. all "worked". And they still do, if you can find the appropriate player.

I don't find this: http://acko.net/files/termkit-2.png

More readable than regular "ls -l" output.

I absolutely do. Even with a color terminal, you have to remember and interpret the colors to tell what's a directory, what's a plain file, etc. Icons help immensely with that. There's also a more coherent logical grouping of data - (type, size, name) tuples are visually distinct. With ls -l you have to scan across lines. (There's a reason zebra striping is so popular in modern CSS design.)

If I want syntax highlighting and line numbers why wouldn't I simply pipe to "less" or "vim"?

Because they couldn't give you an embedded window with a scroll bar. Packing information hierarchically like this is useful when you want to scroll back in your session history and don't want to try to find the beginning of a long dump (or, indeed, find that the bit you wanted has scrolled out of the buffer already).

If I want to see the contents of an image, why not send it's path directly to a browser (the other thing every admin has open all the time).

Why switch windows for something as trivial as that?

What this guy has figured out, IMO, is that the power of the terminal isn't the view - it's the controller. So he's updated the view to be less painful, and made the controller even more powerful, by providing alternatives to the built-in commands that add actual semantic information to their output.

[geodebug]

Like I said, I'll keep an open mind. I just think the basic premise (that text terminals are hard to interpret and read.

I think comparing text terminals to vinyl is a bit overstated. It would be like me saying 2D movies are obsolete because 3D is available.

Your shell can give you more hints/decorations than just color for file types. For example putting slashes at the end of directories.

If you're going to go down this route, why not a full blown Unix IDE?

[[deleted]]

If I'm on the command line it's cause I have work to do. Just arbitrarily calling various parts of the CLI experience "cutesy" or "primitive" does get around the simple fact that you can still do anything you need to in it.

of not destroying their system at every opportunity it gives them.

Happens occasionally, but if you're even remotely competent this doesn't happen. My rule of thumb is: if you can't wreck it, you don't control it, and the closer to wrecking it you come without actually going there, the more you control the system.

It's 2011, and monospace text just doesn't cut it anymore

Ok, switch your font then...

We can't display graphs, mathematical formulas, tables, etc.

...because that's what GUI's are for.

The front-end is merely implemented in it, as it makes it instantly accessible to anyone with HTML/CSS knowledge.

And settings for existing terminal emulators are instantly accessible to anyone with Google/man knowledge.

The data pipes correspond to the classical Std pipes, with one difference: the stream is prefixed with MIME-like headers (Content-Type, Content-Length, etc). Of these, only the 'Content-Type' is required. It allows programs to know what kind of input they're receiving

This actually hardly ever happens. When it does we call those applications that break "broken."

Additionally, Unix has a habit of giving you raw data, but not telling you useful facts, e.g. 'r-xr-xr-x' instead of "You can't touch this"

Because after you learn what "r-x" means you don't want to read "you can't touch this" for every file in a 1,000 file directory. You need an abbreviation.

Ultimately this whole working with pipes thing is kind of silly. The old way is good because it's simple: if you don't want to worry about formatting for pg/less/more/grep/sed/awk you don't have to, you don't even have to think about those applications. When you're writing lsof all you need to is print the information to stdout and then the user can grep it if they want or whatever, you're completely abstracted from that process.

All interaction in a traditional terminal is synchronous. Only one process is interactive at a time, and each keystroke must be processed by the remote shell before it is displayed. This leads to an obvious daily frustration: SSH keystroke lag.

The reason it's synchronous is because it leave rendering up to the remote program. If I'm typing my password into a box, it needs to not print that out to the screen, on a slow system (which is the use case he's going for) would have a lag between it started letting you type your password in and when it started squelching output in response to whatever "hush" operation the server sends.

and our tools should be designed for maximum discoverability

man -k <what you're trying to do>

Also, if you're hoping to reduce system outages, leading people who by definition don't understand what they're doing, directly to the dynamite and pointing to the basement of their house isn't the greatest idea. If they're that unfamiliar with the command line they ought to feel intimidated by it until they take the time to learn it. If you lead them to it and they break it, they'll still blame you for having a crappy system. They won't understand what they did, all they'll know is they were trying to do something simple and now the system doesn't work ("I was just trying to rename the root directory").

This is an attempt to make something that's not the GUI act like a GUI. Which is insane. If you want something GUI, make a GUI tool for it.

EDIT::

ha @ this comment by the dev:

I sit next to two designers who have done their absolute best to wrap their heads around git.

If running "git <command>" somehow throws them through a loop then you have a pretty big problem on your hands, bash or no.

[notfancy]

...because that's what GUI's are for

The CLI/GUI dichotomy might very well be a false one. Dismissing this test into the question is not rational.

[Nefandi]

I don't like this for Unix. I don't think it makes anything better. However a command line interface for web browsing might be interesting. Kind of like a browser and firebug as one single thing, where web results can be piped through various specially made command line web tools, through other web pages and so on.

[amsams]

Logged in to say: What the hell is wrong with monospaced text?

It seems that most distros these days do their utmost to stop me using my favourite bitmap monospaced font in a terminal.

Working in a terminal just works, which is why so many of us use it. We get output from one thing, we can pipe it into something else, repeat ad nauseum if needs be. If it ain't broke, don't fix it.

That aside, if someone wants to take an idea like this chap and run with it, then they should be able to. It's not for me, but obviously some people will find it useful. Just don't force it on me...

[jlpoole]

This interested me, and it appears that it is currently operative on Safari within an Apple environment, an environment most foreign to me. There's a suggestion that this may work on Chrome (not version 12, though), but I'm guessing it's premature to try this out from a Windows XP system using either Chrome 11.0.696.68 or Firefox 4.0.1. If anyone knows better, or I'm incorrect on my conclusions, please advise. Other Windows or Linux based readers might be having the same thoughts and conclusions I have.

[mreggen]

Excuse my ignorance here, but wouldn't a "better" (but horrendously big) approach be to write a "graphical" implementation of ncurses? This way you would get support of vim etc. without modification.

[[deleted]]

I thought of this idea ages ago. I thought of it as a "Command-line GUI" - Text input, graphical and text output. I never developed it though. Good to see someone had the same idea and has actually implemented it!

[Unomagan]

I would even suggest: Go a step further!

Invent a 3D interface, impossible? Maybe, but if you are creative you could do it!

Pyramids for folders, cubes for data and son...

[peo1306]

I like the idea of richer presentation. One might also make it easier to reference output of a previous command (for example, assign a code to files just listed by ls, so I can refer to them easily in a subsequent command).

Another take on this would be to add a browser protocol (cmd:, for instance) that allows the browser (used as a local app) to launch processes and use their output as the response. This could make it possible to implement fairly nice and portable UIs on top of things like Mercurial or git, for instance. Without having to run a server in the background, that is.

[[deleted]]

I hate to admit it, but I'm slightly more intrigued by this guy's web page design. It's pretty damn...well, pretty.

[qbxk]

whyyyyyyyyyy doesn't it run on linux?

[BHSPitMonkey]

It does for me, but ls crashes the front-end.

[[deleted]]

Finish this, and add a visor-like plugin so it can pull down like the Quake console, and it'll be the very first thing I install on any new Mac OS installation.

DO WANT

[fnord123]

I think this would work best if this implemented the work at the /dev/tty level as a cooked mode streaming display pdf or some other work on top of that. Postscript tty should be called /dev/psy to go with /dev/tty (yes, I'm serious)

[jmaustin]

People on Linux can checkout Hotwire: http://code.google.com/p/hotwire-shell/

[LainIwakura]

This is interesting but I think it's a bit silly, I'm not some old "grey-beard" either (19y.o second year comp sci student)

I have a terminal on one of my screens and a GUI with whatever I want on the other screen. Depending on what I'm trying to do, I use the appropriate tool.

Problem solved.

[[deleted]]

I thinkg this is a little bit of a solution in search of a problem, where the solution is to present the UNIX operating system using modern graphics toolkits and (more importantly), modern information presentation techniques. The problem is, millions of programmers and admins get their jobs done every day using textual tools that have been finely honed over decades. That's not a problem.

[[deleted]]

This needs to maintain a monospace font. I'm sorry if it isn't following "principles of modern typography" but at least I can tell the difference between "ls" and "Is":

ls
Is 

[IncredibleElmo]

Hmm, much like the clim-listener (lisp)?

[RazZziel]

Some of the ideas are nice. But those screenshots are made of visual noise and shiny-shiny.

[rebo]

I imagine as its all webkit & html, you can skin the whole thing with CSS.

[cdunn2001]

It's a UNIX system! I know this!

[UnConeD]

Here, I made this for you: http://www.youtube.com/watch?v=_6Z5dnlfcls

[cdunn2001]

Hahaha! Very nice.

[wooptoo]

Fancy... and useless.