|
|
Log in / Subscribe / Register

See also

See also

Posted May 18, 2011 13:58 UTC (Wed) by epa (subscriber, #39769)
Parent article: Announcing TermKit

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.

to post comments

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 (subscriber, #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.


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