|
|
Log in / Subscribe / Register

Announcing TermKit

[Posted May 18, 2011 by corbet]

Steven Wittens has written a lengthy weblog entry describing TermKit, a terminal emulator built on WebKit. "So while I agree that having a flexible toolbox is great, in my opinion, those pieces could be built a lot better. I don't want the computer equivalent of a screwdriver and a hammer, I want a tricorder and a laser saw. TermKit is my attempt at making these better tools and addresses a couple of major pain points. I see TermKit as an extension of what Apple did with OS X, in particular the system tools like Disk Utility and Activity Monitor. Tech stuff doesn't have to look like it comes from the Matrix." Source is available on Github.
to post comments

Announcing TermKit

Posted May 18, 2011 13:38 UTC (Wed) by prusnak (guest, #64538) [Link] (6 responses)

What is the connection to Linux? (Seems that sources are Mac OS X only ...)

Announcing TermKit

Posted May 18, 2011 13:52 UTC (Wed) by corbet (editor, #1) [Link] (5 responses)

I will confess I missed the OS X only aspect of it. I still think it's an interesting project; a port should be doable if it works out.

Announcing TermKit

Posted May 18, 2011 14:24 UTC (Wed) by njd27 (subscriber, #5770) [Link]

I *like* the current level of non-Linux stories that you cover. Please don't change!

Announcing TermKit

Posted May 18, 2011 14:25 UTC (Wed) by pj (subscriber, #4506) [Link] (2 responses)

There's a branch someone did to make it work with any webkit browser - which includes Chromium on Ubuntu.

Announcing TermKit

Posted May 19, 2011 18:09 UTC (Thu) by mikov (guest, #33179) [Link] (1 responses)

Where? I couldn't find it on Github.

Announcing TermKit

Posted May 20, 2011 17:30 UTC (Fri) by robinst (guest, #61173) [Link]

See this pull request (or Floby's repo):

https://github.com/unconed/TermKit/pull/6

Announcing TermKit

Posted May 18, 2011 22:36 UTC (Wed) by karim (subscriber, #114) [Link]

Totally relevant material. Thanks for posting this.

Announcing TermKit

Posted May 18, 2011 13:48 UTC (Wed) by miekg (subscriber, #4403) [Link] (1 responses)

But does it support 'set -o vi'? :-)

Announcing TermKit

Posted May 19, 2011 23:55 UTC (Thu) by baldridgeec (guest, #55283) [Link]

I think that's a shell option, not a termcap setting. So, yes, as long as you're using a shell that supports vi-mode (and uses that syntax to reach it.) :)

Announcing TermKit

Posted May 18, 2011 13:53 UTC (Wed) by rfunk (subscriber, #4054) [Link] (2 responses)

I have mixed feelings about this... there are a lot of good ideas here (some of which have been tried before), and maybe it could catch on. Maybe it's time to advance the state of the art in command-based computer interaction. But the discussion of pipes and standard I/O seems to miss the point entirely about the benefits of the Unix pipe model.

Announcing TermKit

Posted May 18, 2011 20:49 UTC (Wed) by elanthis (guest, #6227) [Link] (1 responses)

How so?

More importantly, are the benefits of the UNIX pipe model worth all the cons of the model?

Having been doing this some 15 years, I'm heavily inclined towards doing things the TermKit/PowerShell way. It's just better. And nothing says that the classic UNIX model doesn't still work (in fact, it quite explicitly does). It just functions at a reduced state due to its inadequacies.

Announcing TermKit

Posted May 18, 2011 23:07 UTC (Wed) by jonabbey (guest, #2736) [Link]

As nye said, it's all about the network effects. If you can get all these tools to converge on a structured schemata for pipeline communications, great. Not easy to do, though.

Right now it seems that things in Linuxland are divided between ASCII tooling at the command line, D-BUS at the system level, and XML, HTML, and JSON at the network level.

I can't think of any faction in our community working today with the power to unify and move past all that.

See also

Posted May 18, 2011 13:58 UTC (Wed) by epa (subscriber, #39769) [Link] (25 responses)

This was tried before as 'xmlterm' which was based on Mozilla. Shell commands could output plain text, or XML which would be formatted by the terminal. It was neat but never took off.

See also

Posted May 18, 2011 14:13 UTC (Wed) by pboddie (guest, #50784) [Link]

I've seen a few Python-based shells which do a lot of this kind of thing, some strictly for Python (so there's special rendering of Python objects), others for a shell command language. Hotwire is an example of the latter, but I'm sure there are others.

Of course, there is the argument that the graphical environment itself should be an extension of the shell - perhaps Plan 9 works on this principle - but the major desktop environments don't really follow this up.

See also

Posted May 18, 2011 14:28 UTC (Wed) by nye (guest, #51576) [Link] (23 responses)

Similarly MS Powershell is designed to allow piping objects around. It's powerful, fairly well designed, and generally cool but it suffers a crippling drawback shared by all of these attempts: it's entirely dependent on the network effect so to make full use of it requires that you change the world. The idea kind of reminds me of the failure of Plan 9 - it's better, but it's not obviously better *enough*, so the not-quite-as-good-but-not-too-bad solution wins.

See also

Posted May 18, 2011 15:13 UTC (Wed) by drag (guest, #31333) [Link] (16 responses)

I wouldn't mind having a terminal that is able to properly able to detect and parse data other then text.

Also having the ability to properly give arguments to a command instead of having your text directly interpreted by a shell seems handy.

It seems like you should be able to make a more intelligent terminal emulator without having to rewrite everything.

See also

Posted May 18, 2011 15:23 UTC (Wed) by njwhite (guest, #51848) [Link] (15 responses)

To me this just looks like the efforts of a web developer who has recently come into contact with unix and thinks "I could do better than that"...

> It seems like you should be able to make a more intelligent terminal
> emulator without having to rewrite everything.

What do you think would make a more intelligent terminal emulator? I've never really found many 'extra' features to be worthwhile at all, except x selection and scrollback.

See also

Posted May 18, 2011 15:51 UTC (Wed) by Tobu (subscriber, #24111) [Link] (7 responses)

Structured command output would be pretty neat. For example making it foldable.

At the moment I can use less with an alternative screen that gets wiped when I close it, less on the terminal, and raw command output to the terminal. The last two can wipe the scrollback buffer, the last isn't too convenient to navigate (search isn't standard, though screen and some terminal emulators provide it), the first lets the output disappear (though less can be used to save it somewhere), and the first two require extra typing. Picking one before running a command increases cognitive load a bit.

Fixing this would require some integration between shell and terminal. At the very least one escape that says "begin prompt" and one that says "end prompt"; maybe some deeper integration to prevent binary garbage from messing with terminal state as well.

See also

Posted May 18, 2011 16:12 UTC (Wed) by drag (guest, #31333) [Link] (6 responses)

Well if your 'terminal' actually a application for submitting commands and returning their output instead of just providing basic 'vt100' or 'xterm' style terminal then you wouldn't need any special 'begin prompt' or 'end prompt' type commands.

It would be:

1. take this command and argument list from user,
2. execute it,
3. return output from command to same window.

Just get rid of the whole 'xterm is a serial terminal emulator plus plus' type approach and have the terminal manage commands directly.

You'd be able still use bash and traditional command line tools, but it would be 'in the back end' of the 'terminal'.

See also

Posted May 18, 2011 16:55 UTC (Wed) by epa (subscriber, #39769) [Link]

What you describe is similar to M-x shell in Emacs, which I normally use instead of a terminal. I keep an ordinary terminal handy for running top(1) and other things that need to make the cursor jump around.

See also

Posted May 18, 2011 16:57 UTC (Wed) by Tobu (subscriber, #24111) [Link]

That would work better long term. We'd need an upgrade path for top, less, and curses applications. Maybe detect magic sequences and detach those to a new tab with full xterm emulation.

See also

Posted May 18, 2011 18:51 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses)

That sounds great until I need a loop?

Not that I think there's anything wrong with trying new stuff, but the shell has a ton of useful stuff (redirection, globbing, variables, loops, etc.) that pretty much require it be a programming language. And it's not a great language, but no-one's made the teeniest bit of progress in displacing Bourne-style shells in decades. Partly because it does an excellent job of scaling up from simple executable+arguments commands to full-fledged scripts -- you can always reach for just as much as you need at any given moment.

Maybe someone should try adding terminal emulation to Bash. That'd be interesting...

See also

Posted May 18, 2011 18:57 UTC (Wed) by drag (guest, #31333) [Link]

> That sounds great until I need a loop?

You should be able to pass the arguments to create a loop to a bash shell.

I don't think it would be a good idea to replace the shell with a 'smart terminal', but it would be cool to be able to take more control over the environment.

The biggest problem is that the shell is intensely complicated. Keeping backwards compatibility would be very difficult.

if I was smarter I could create a proof of concept or whatever.

See also

Posted May 19, 2011 14:15 UTC (Thu) by bjartur (guest, #67801) [Link]

See Tclsh.

See also: hotwire

Posted May 23, 2011 5:09 UTC (Mon) by nevyn (guest, #33129) [Link]

This is mostly what "hotwire" (yum install hotwire) did ... and worked pretty well for what it did (some of the best TAB completion in a GUI I've still ever used), but like a lot of the other attempts it was so successful you haven't heard of it :).

See also

Posted May 18, 2011 15:57 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

I put two of them:

* being able to submit shell commands as individual lists of arguments rather then a line of text that is parsed by a shell.

* do something intelligently with non-text data or structured text. Like if it's html then parse it and display it usefully. Or if it it's binary data display a hexdump or detect it's mimetype and display that correctly. Stuff like that.

I suppose a few other things like integrate functionality like tmux or screen. Be able to subdivide the terminal and move sections between windows and close out and recall shells. Something beyond just tabs.. more organic were I can subdivide and tile terminals in a single window easier.

Integration of ssh would be nice. Take advantage of some openssh features like ControlPath/ControlMaster. So that I could open a terminal directly into a ssh shell. Be able to change the view to pull up a application menu (the terminal should be able to pull up a menu from the desktop.menu on systems that support it.) for launching X applications or be able to right click and go into a nautilus file browser and such things. Create tunnels and open extra sessions. That way I only need to create a single ssh session, but be able to take advantage of it in a easy way.

Something equivalent to a browser history would be nice. The 'history' dot files have a number of limitations. I should be able to recall sessions and see the commands I ran and, if possible, what systems I ran them on. Date stamps, see commands grouped by sessions, and such things.

See also

Posted May 19, 2011 14:24 UTC (Thu) by bjartur (guest, #67801) [Link] (1 responses)

Instead of splitting the terminal window, run a real window system (with an usable tiling window manager), and get a command line (shell input), a canvas (shell output), gvim and a terminal running top each in their window.

We seriously need some improvements to the traditional /dev/tty. I shouldn't have to stty -echo to prevent input clashing with output.

See also

Posted May 19, 2011 20:42 UTC (Thu) by drag (guest, #31333) [Link]

*shrug* I like having all my terminal stuff in one window and I don't like tabs.

But certainly I love tmux's backend daemon. That's something you certainly can't get with a tiling window manager.

See also

Posted May 18, 2011 16:08 UTC (Wed) by rillian (guest, #11344) [Link] (3 responses)

For a very long time I've wanted a terminal emulator which supports proportional fonts. This is a hard problem, assuming you don't require rewriting everything to output json.

There are simpler things too, like sniffing the output stream and spooling common binary formats for alternate display. Thus 'cat image.png' could display the image inline like TermKit, without having to re-implement cat.

More controversially, moving things like command-line aliases, completion, and history browsing into the terminal could improve display of that information, at the expense of the terminal running commands in the background for you.

E.g. the terminal could export remote files sshfs-style for local editing, saving having to type the rsync round-trip. So 'gimp image.png' could go through a terminal-side alias which runs gimp if the shell is local, but if it's remote, exports the file on a local mount and launches the local gimp on that.

That sort of thing.

cat $foo.png

Posted May 18, 2011 18:06 UTC (Wed) by signbit (guest, #71372) [Link] (2 responses)

I don't get the usefulness of catting images. OK, they are a cool gimmick, as long as they fit inside the terminal. But what if you need to scroll, zoom, copy, paste? You will end up messing up the original terminal window and then you'll need to change it back later. Is $viewer $foo.png that much of a hassle?

Most of the features that people want can be implemented by just running a shell inside EMACS. You get a nice editable scroll-back buffer and all that jazz.

cat $foo.png

Posted May 18, 2011 18:58 UTC (Wed) by drag (guest, #31333) [Link]

Yeah, but you have to use Emacs. It's almost a crime to do that to somebody. :P

cat $foo.png

Posted May 19, 2011 5:58 UTC (Thu) by rillian (guest, #11344) [Link]

I don't know how much I'd actually use 'cat foo.png' in practice. Certainly not for local images. But remoting GTK applications over the wan is painful, and unless the image is much bigger than the screen, spooling the compressed data over the network is going to be faster as well as more interactive.

As for scroll/zoom, presumedly a terminal with image display could grow image-viewer features as well, if they turn out to be important. And X copy/paste already supports structured data...

Regardless, it would be better than what happens now when I accidentally send binary data to the terminal. (Recently, gnome-terminal helpfully asks if it can search for a non-existent font to cover the unmapped unicode characters while I'm trying to send ctrl-c.)

Boiling the ocean.

Posted May 18, 2011 18:02 UTC (Wed) by tshow (subscriber, #6411) [Link] (2 responses)

That's the problem with all of these schemes; they're "boil the ocean" projects. You can't just replace the shell and the terminal, you also have to replace a good chunk of people's tools, and supply APIs (and hopefully patches) to get everyone else onto your system. Anything less than that, and people are going to stick with bash.

I've had a plan for a system kind of like this for a while; the ideas are similar, though I think the scheme I've got is substantially more radical. But again, success for my project implies displacing bash, the terminal emulator, context-aware quicklaunchers, the file browser and emacs/vi. Which is... um... ambitious enough that I've never pushed the idea past the formative stages.

I should really get back to it. The main problem is the surrounding framework; making everything that has a manpage play nice in it. That said, it would be worth it...

Boiling the ocean.

Posted May 18, 2011 23:33 UTC (Wed) by elanthis (guest, #6227) [Link] (1 responses)

Consider this project more of a proof of concept.

Right now, for instance, it requires two processes to even work: a server and a viewer. That's pretty insane.

Really, all this system actually needs to work is a way to communicate some meta-data about the streams. You can then write a nice GUI shell (WebKit or not) that can use that meta-data, a nice TTY that uses it, or even just run plain ol' Bash and stock UNIX tools and let them ignore the extra meta-data.

You could do this with a relatively simple UNIX-y protocol. Set a couple environment variables and open a fourth bi-directional socket for meta-data communication. Something like SHELL_METADATA_PID which serves the purpose of indicating that the metadata socket exists and making sure that only the target process tries to read/write to it (and not sub-processes, which would have a different PID). Tools that support the new metadata and which see that the env var is set and the right PID can read RFC2822 style meta data from socket 3 and write output metadata to socket 3. The main shell is responsible for creating these sockets and sanitizing inputs/outputs between pipeline stages. If the shell is just Bash or something, the env var is not set (or even if it was set by the parent of Bash, it would never match any of the children, so they act as if it was unset) and so those new tools just assume their input is untyped data and don't bother writing out any extra metadata. Wrap up the basic code for that in a small library and then write a shell that can use the extra metadata for final output streams and there you go.

A more complex -- but more powerful -- protocol could also be devised that allows things like negotiation between stages. Maybe ls can output some nice structured format, but if the next process in the pipeline doesn't want to deal with that or doesn't know how, it should get the classical text output of ps. That requires that either ps knows what output is desired, or requires the shell to transparently translate the rich output into the classical output between the pipeline stages. Either of these approaches require some way to get the accepted inputs of subsequent pipeline stages, and the shell-based translation additionally means that an enchanced ps would only be able to work with classical tools while running in an enhanced shell (so I'd suggest making the output format selection ps's job). This is a tougher problem to solve, but it's still worth it.

Boiling the ocean.

Posted May 19, 2011 15:43 UTC (Thu) by tshow (subscriber, #6411) [Link]

The scheme I've cooked up actually works in "screen" functionality as well, (as in, detachable terminals), so it does require multiple processes to work properly. Part of the idea is to simply extend the terminal escape codes so that a legacy tool will just work, but tools written for the new system can request the additional functionality.

Some of the additional functionality is there anyways; since a terminal is essentially a discrete series of execution sessions, I visually separate them by placing (subtle) bubbles around them. Rather than "backgrounding" tasks, things just keep running in their bubble, and you can tear a bubble off the terminal window and put it elsewhere on the screen. You get that whether it's a legacy shell program or not.

The new functionality allows things like the ability to create a progress bar that will sit in the terminal window where it was created, and receive updates from the program. The updates are all through the terminal escape commands, so the program doesn't have to care where things wind up on the screen. It also means a single program can have an arbitrary number of widgets in the output stream.

It also allows tagging things, to allow for saying things like "this segment of the output is mouse-active, poke me with this ID if the mouse hits it".

There's a lot more to the overall idea; once you've an explicit logical split between the execution environments, you can start allowing them to persist. Give them names, and they become sources and sinks for data.

So, say you do "ls", and you get a list of 10000 files. In my scheme, that list winds up in a mouse-active named buffer that has a scrollbar, named (say) ls-5. You can then use the contents of the buffer as the source for another command:

> grep foo < $ls-5

Or you can append data to it.

> ls bar/baz >> $ls-5

So, the execution bubbles wind up being emacs-like buffers. Programs that understand the new terminal/shell can create their own buffers as well, and do split output.

Anyways, this is just scratching the surface. I'm sure every programmer has a boil-the-ocean crazy project, and this one is mine... :)

See also

Posted May 18, 2011 19:22 UTC (Wed) by oblio (guest, #33465) [Link] (2 responses)

Powershell has some decent backwards compatibility ideas. And it definitely has support to get that network effect going. At least in the Microsoft world, all the new products come with Powershell modules.
Add to that the fact that Windows 7 and 2008 have Powershell built-in, and it will get really big, real soon :)

I know there's a Pash project to port it to Linux, but it's stalled. And I doubt any self-respecting Linux hacker will contribute to a shell replacement written in C# + Mono :)

See also

Posted May 18, 2011 19:51 UTC (Wed) by alvieboy (guest, #51617) [Link] (1 responses)

I don't think poweshell follows the usual KISS model of development. Every time I read someone writing about it, OLE is what comes to my mind.

Do less, but do it better, or in other words make it small featured, but with features that actually work 99.999% of time.

Don't add complexity - this is for upper layers. Keep things simple and smooth, if they prove "right", others will work on top of that.

See also

Posted May 19, 2011 0:14 UTC (Thu) by raven667 (guest, #5198) [Link]

Well I don't know what comes to mind when you think of OLE but PowerShell just exposes existing libraries and many vendors provide libraries with their own APIs each of which is a small modular component. powershell itself is small, it's the standard and vendor libraries that add all the features. I don't think the core is all that crazy.

Announcing TermKit

Posted May 18, 2011 16:15 UTC (Wed) by rilder (guest, #59804) [Link] (1 responses)

"Unix commands are "useless by default", and when asked, will only tell you raw data, not useful facts. e.g. "rwxr-xr-x" instead of "You can't edit this file.""

This did it for me. Thanks, but no thanks.

Looks interesting. Node.js is a nice new upcoming language.

Announcing TermKit

Posted May 18, 2011 18:49 UTC (Wed) by perennialmind (guest, #45817) [Link]

I think that that particular suggestion was made purely for the sake of levity. With a modicum of imagination, one can think of several useful ways to exploit the features of a rich terminal in that context, such as making an expanded permission and attribute display available on hover, a la the html title attribute. He did clarify in a comment that he had in mind graphical cues to augment, rather than reduce, the information content of current permission display.

Personally I've been dissatisfied with the ten character permission display of ls -l ever since I started using ACLs.

Announcing TermKit

Posted May 18, 2011 18:43 UTC (Wed) by mikov (guest, #33179) [Link] (2 responses)

I think he is missing a very (if not the most) important aspect of the "traditional Unix" model - simplicity. It works because it is extremely simple - to implement, to understand, to debug. That also means it is very flexible.

When we start involving asynchronous completions, Node.js, JSON, and even proportional fonts, all my professional experience and intuition (as a system developer, not as an admin) tells me that we have crossed the limit where complexity trumps usability. The thinking that everything has to fit inside a common framework is exactly what has lead to the Windows registry hell :-)

He has certainly identified real (and well known) problems, but the proposed solution is just way too complex.

Take the "somewhat parseable text" problem, which is certainly valid, but addressing it doesn't require changing the world. Applications can be modified to generate and process structured output, for example with a command line switch. That is up to the application developer - predictable, simple. Certainly not a policy I want enforced by a "kit".

Or "remote SSH lag" on a high latency link. A very simple solution is to do readline locally.

Or "bash escaping". A very real problem, true - bash as a whole is a horrible abomination, which we tolerate simply because it happens to be more powerful than the alternatives (especially if you are coming from "command.com" :-) But bash is "just" a shell. Completely replaceable. Use Python if you prefer. Nothing can be done for the existing scripts anyway.

Announcing TermKit

Posted May 18, 2011 21:53 UTC (Wed) by bjartur (guest, #67801) [Link]

No, a command line switch would yield terror.
find /usr/music/skálmöld -print0 | shuf -z | xargs -0n1 aplay
We need to standardize to a build time option (CFLAGS="-DOUTPUT_STRUCTURED") or an environment variable (FORMAT=bencode).

Announcing TermKit

Posted May 19, 2011 14:40 UTC (Thu) by bjartur (guest, #67801) [Link]

Ideally, you'd do:
rlwrap read | ssh mordor rc

Where rlwrap is line editing and history, read copies stdin to stdout linewise, and rc is the Plan 9 shell.
But then you can't let readline complete your filenames, but have to remember and type them out yourself. That means not letting the GNOME project choose filenames for you. Use short, lowercase mnemonic words as per Unix tradition.

Announcing TermKit

Posted May 18, 2011 22:30 UTC (Wed) by elanthis (guest, #6227) [Link]

Having looked into the implementation a bit deeper, I have to say two things. First, I love the concept. This is what the shell I run on my desktop should look and act like.

Second, the implementation is an abomination. It's at best a neat mockup of what the shell _could_ be, but very little of this implementation is actually usable or desirable for a Real Shell Replacement.

The protocol between applications needs to be defined in a way that seamlessly integrates with native, non-JavaScript tools. e.g., perl could be able to be used without changes; output from a previous command is just read as raw bytes and the Perl output woudl be automatically tagged as untyped data. Any common reusable code needs to be in a nice C library that can be easily reused in non-WebKit-based implementations, e.g. a TTY-friendly shell that can still use fancy text markup to give the user extra information even though it can't display icons or images. The WebKit UI needs to be a shell on top of an enhanced UNIX environment, not a view into a server process that only knows how to communicate with a browser.

Announcing TermKit

Posted May 18, 2011 23:35 UTC (Wed) by nicooo (guest, #69134) [Link]

This looks like the Web 2.0 version of OS/400 + 3270. OTOH, maybe having an interface not designed by IBM will make it more successful.

BTW, I'd love to have proportional fonts in Vim. Also, it would be nice to see screenshots that don't use OS X's fail fuzzy bold fonts.

Composing data processors or UI elements?

Posted May 19, 2011 0:09 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link] (2 responses)

The blogger and the comments here on LWN conflate different compositional models: the data-flow composition of standard I/O pipelines; the data-flow composition of processes acting sequentially on the host filesystem; the sequential UI composition of the shell read-eval-print loop; and the parallel UI composition of graphical window managers and their character-cell equivalents.

The blog's second diagram of a process having standard in/out/err and separate view in/out looks exactly like a normal X application to me. You can launch it from a script or command line, and have standard I/O for pipeline composition, but also have the side-channel GUI interface if needed. If there is a problem with this approach for non-GUI processes, it is only because stdout is conventionally overloaded for data stream and textual UI based on the detection of a TTY. A mildly post-Unix environment could easily provide additional standard file descriptors for data in/out, data error out, and operator TTY, allowing for example the use of a process in a data-processing pipeline while also allowing the process to use a terminal-based UI via ncurses or such. A batch pipeline would provide no TTY to the pipelined processes, while an interactive shell could provide psuedo-TTYs to each process and compose them into its own TTY, whether by multiplexing one character-cell terminal or providing multiple emulated terminals in a GUI environment. But, once you start wanting to provide non-textual elements, it is probably better to ditch the TTY-based UI model and just go back to a side-channel to a proper graphical environment.

In either case, you need to address the fact that the data-processing pipeline composition and the UI composition are not necessarily the same topology and actually require a more expressive programming language (e.g. a better shell language) to define both aspects of composition in a reasonable manner. And you would definitely want some standard utilities which could remap a UI channel into a data stream or vice versa, i.e. getting user input and sending it into non-interactive processes at the head of a pipeline, while consuming the output from the tail of the pipeline and putting it back into the UI channel for the user. Or, some combination of this with the native UIs of other pipeline elements.

Completely orthogonal to this issue of separated dataflow and UI is the desire by some to replace Unix's unstructured flows with structure. This can be applied separately to both kinds of channel in a post-Unix environment: object streams replacing byte streams in the dataflow pipeline, or semantic markup models (like Javascript, HTML, CSS, etc) replacing the low-level TTY or X drawing primitives in the UI channel.

Composing data processors or UI elements?

Posted May 19, 2011 1:27 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

> A mildly post-Unix environment could easily provide additional standard file descriptors for data in/out, data error out, and operator TTY, allowing for example the use of a process in a data-processing pipeline while also allowing the process to use a terminal-based UI via ncurses or such.

You're actually describing a standard part of classic Unix (though not one of the better known ones!). Opening /dev/tty gives you an fd to the "controlling TTY". This is how e.g. ssh can ask you for your password even when run inside a pipeline.

Composing data processors or UI elements?

Posted May 19, 2011 3:55 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link]

Well, in response to the blog, I was trying to describe a more compositional UI opportunity than just "interleaved lines in the same TTY" which is what you get with the controlling TTY approach of ssh and friends. If each child process was given a distinct psuedo-TTY as its controlling terminal, you could have the parent of the pipeline do interesting things to present separate UI frames from each pipeline element. The shell and terminal combination would be more like a window and display manager framing the widgets displayed by the invoked command(s).

This seemed to me more in line with some of the active UI elements that the blogger was trying to imagine, e.g. you could have an interactive 'ls' output that lets you click to expand/hide aspects of its listing output on the TTY, while sending a traditional machine-readable listing on its stdout for pipeline processing. I could use either or both of these outputs in one command. Having the 'ls' process stick around to drive the interaction makes a lot more sense in the Unix environment than assuming a bunch of pickled objects can stream out of the process and somehow carry their embedded code which can be executed by a different calling context.

One thing that gets lost in all of this fanciful interaction is the question of resource lifetimes. You wouldn't want every previous command process in your shell history to stick around presenting its active UI in your scrollback buffer, just in case you decide to go back and interact further. But you might want to go back a little! I've often wished I could have my 'man | less' pipeline still active for scrolling and search while I was starting to edit the command-line for my next command, based on what I was learning from the manpage.

Announcing TermKit

Posted May 19, 2011 7:35 UTC (Thu) by jengelh (subscriber, #33263) [Link] (2 responses)

Uhuh, another thing with a meaningless "Kit" suffix. Please pull a number (contending with Console-, Device-, Policy- kits), and wait in line. — A more distinguished name could have been chosen.

And if we do `ls | grep js`, where would we go? Reminiscient of UUOC, `ls *js*` would do just fine.

As for supporting cating of URLs, that is sort of un-Unixish. If websites were accessible through files (some VFS/FUSE trickery), every program could benefit – but then again, `./prog <(curl google.de)` already does just that. Also note that images can be overlayed over xterm, w3m(-inline-image) has already set a precedent.

Speaking of cating images, it would seem that augmenting the cat command instead of limiting the smart cat to termkit is a win for everybody.

function cat {
    data=$(file "$1"); # deal with $@ later
    switch "$data"
    *JPEG*|...) some-viewer "$1";;
    *) command cat "$1";;
    esac;
}

Announcing TermKit

Posted May 19, 2011 12:22 UTC (Thu) by nye (guest, #51576) [Link]

>As for supporting cating of URLs, that is sort of un-Unixish. If websites were accessible through files (some VFS/FUSE trickery), every program could benefit

$sudo aptitude install avfs
$mountavfs
$cat ~/.avfs/#http:lwn.net

Announcing TermKit

Posted May 19, 2011 22:38 UTC (Thu) by Hausvib6 (guest, #70606) [Link]

Luckily, this one is not one of the usual *Kit.

A new kind of shell

Posted May 19, 2011 11:00 UTC (Thu) by dgm (subscriber, #49227) [Link]

I think most people miss the real value of this proposition, that is, a _new_ kind of shell to the system, not a replacement for xterm+bash. I view it more like a command-based Nautilus than pretty-pictures xterm.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds