| |

Log in / Subscribe / Register

See also

See also

Posted May 18, 2011 15:13 UTC (Wed) by drag (guest, #31333)
In reply to: See also by nye
Parent article: Announcing TermKit

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.

to post comments

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

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