Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) [LWN.net]

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 24, 2008 23:21 UTC (Tue) by nix (subscriber, #2304)
In reply to: Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine) by walters
Parent article: Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

I'm interested in how this project will avoid the Emacs Trap (also known 
as the C++ Trap, Java Trap, et al; perhaps 'VM Trap' is a better word).

Namely, my understanding is that Hotwire commands are code written in 
Hotwire-specific Python... as against a Unix world in which *arbitrary 
executables* or scripts in arbitrary scripting languages that merely read 
and write from stdin/stdout can be used, regardless of implementation 
language.

(The real problem here is that Unix has a standard mechanism for 
exchanging text streams, but none for exchanging objects, so you're 
necessarily locked into *some* language's object model from the start, and 
other languages are necessarily second-class citizens from then on. I 
really like the idea of an OO-based pipeline, because it avoids quoting 
and serialization problems completely, but I've never been able to figure 
out a way around this rather killer problem. I'm not satisfied with a 
one-language shell replacement: no one language is good enough.)


Also, I'm afraid I tried using Hotwire for a while earlier this evening 
and found it intolerable. I thought I'd find it really nifty, and at first 
it was: but it soon became clear just how many of the commands I type in 
are elaborate pipelines, and whenever I tried to type one of them in, 
*wham* cognitive dissonance and quoting hell. The existing sh command 
seems like it could only work well if you're not using both " and ' quotes 
in your shell pipeline. I'm not really sure how to fix this, either: 
perhaps write the command out to a a one-line shell script in a temporary 
file and execute it, yuck.

You could say, sure, use a normal shell for that sort of thing, but that 
means I'd be hopping between shells every five lines or so, and synching 
the current directories et al would be very annoying.

(Also, did I miss something or is there no analogue of the POSIX-extended 
backquote operator $(...)? I'm sure I must have missed something here.)

(... hm, I just noticed the 'language will be overhauled' thing in the 
Wiki, in which case I'm moaning about stuff you're already perfectly aware 
of and should shut up and go to bed before I make any more of an idiot of 
myself. Yes, what a good idea.)

(Log in to post comments)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 25, 2008 1:55 UTC (Wed) by walters (subscriber, #7396) [Link]

Thanks for trying it out and for the very thoughtful response!

On VMs and Hotwire/Python. So right now, the commands are really nothing more than shortcuts
to ordinary Python functions. The idea is basically that nowadays, developers and system
administrators code to library APIs, and that a lot of /usr/bin is just wrappers around those
APIs (e.g. /usr/bin/GET, /usr/bin/lshal, /usr/bin/gconftool-2, /usr/bin/gvfs-ls, etc.).

I chose to prototype Hotwire in Python because Python has for a mix of historical, cultural,
and technical reasons had good bindings to various parts of the OS stack up through the
desktop. Mono is also doing well there nowadays, and the JVM is catching up fast.

But anyways, so the basic idea is that now we have these libraries, what if your shell was
more of a *direct* interface to those libraries, and what if it made it easier to transition
to using those libraries, just like how you would in a real program?

The simple pitch is the same one that's been well known for years; "ps" is easy to type and
inspect interactively, but a pain in the butt to try to parse as a robust API from a program.

Now there are two problems.

1) Only Python is supported
2) Hotwire is shipping the commands

On 1), my long term plan is to switch to either OpenJDK or Mono. The JVM and .NET have been
co-evolving for the last few years, and really legacy multi-language capability today on both
is pretty good. JRuby on the JVM and IronPython on .NET demonstrate that today;
Jython/IronRuby are both gaining steam. And there are several runtime-native new languages
like Scala/Clojure for the JVM and Boo/F# for .NET that show fundamentally different languages
can run.

So yes, the long term idea is that the JVM/.NET bytecode, calling conventions and runtime are
*the* system. With the ability to call into legacy external binaries in /usr/bin as unicode
streams though.

2) I would like to standardize the command system such that *the library* can ship a command.
Here's a post about how you can take an ordinary Python function and add a Hotwire-specific
decorator to it to make it callable from the shell:

http://groups.google.com/group/hotwire-shell/browse_threa...

Java class file annotations or .NET attributes obviously could fill this same role.

Now as for the cognitive dissonance/quoting hell...can you give some specific examples?

There is sadly no analogue of $() or `` yet. I need to figure that out. I do miss it myself
sometimes too.

I don't blame you for getting frustrated now; there are a mix of bugs and not-implemented
things.

To be honest lately what I've been spending time on is trying to "productize" my SSH client
that came out of this work (new website is http://www.gnome.org/projects/hotssh/, will make a
release soon).

But anyways, it is fun to hack on Hotwire and really my end goal is just to push the
developer/operating system boundary further. If Hotwire doesn't succeed itself but someone
else gets inspired to create something *actually new* rather than just what has been done in
the VT100 emulator box, I'll count that as success =)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 25, 2008 2:33 UTC (Wed) by drag (subscriber, #31333) [Link]

I don't really see it any different from any other Unix shell in terms of python-specific
commands. 

Every shell has their own set of built-ins. Stuff that conflicts and may break scripts and
such. Pointing at some symbolic link vs trapping commands vs wrappers around library
functions.. what's the difference? Different ways to accomplish the same goals. 


The only thing I'd care about is avoiding depending on the mouse for _anything_. My favorite
media player is Mplayer for a very good reason (and it's nothing against gstreamer...).
Non-use of the mouse == faster + less chance of ruining my wrists. It's beyond just personal
bigotry, there is a serious ergonomic issue going on here.

Also.. if it was possible to use this hotwire from a virtual console or just a plain xterm,
then that would be fantastic. Screen beats the absolute living crap out of any sort of tabbed
system I've ever seen in my life.

Basically I have nothing against nice friendly gui systems.. that's very good. Even if you
still end up requiring a special python gui to run hotwire, I would like to be able to disable
the tab bar, menu bar, and the scroll bar and still be able to use it.

Just my 10 cents. If you ignore me I am not going to start badmouthing you or anything like
that. :)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 25, 2008 10:16 UTC (Wed) by nix (subscriber, #2304) [Link]

Every shell has their own set of built-ins. Stuff that conflicts and may break scripts and such. Pointing at some symbolic link vs trapping commands vs wrappers around library functions.. what's the difference? Different ways to accomplish the same goals.

Yeah, but this isn't really like that, not yet. This is like it would be if you had a shell with extensible builtins (like bash or zsh) but for which you needed to know if commands were built-in or not, because built-in commands had a different syntax.

(As an aside, has anyone ever seen the loadable dynamic builtin stuff in bash used? I've seen loadable builtins in zsh used occasionally, but never the corresponding bash feature.)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 25, 2008 17:56 UTC (Wed) by drag (subscriber, #31333) [Link]

It depends on how you look at it.

With python you avoid the source --> compile --> linker cycle. You just edit the source code,
add your functions to a library or to a directory, and the compiling and that sort of thing is
done on the fly. 

With bash you'd have to get the source code and edit it to extend it, unless you use a plugin
or extension feature like you mentioned just now.

That being said, I like the idea of a script-based shell. It's very similar to Emacs.. the
major difference here is that hotwire isn't going to pretend its a editor to trick programmers
into trying it out. :)

After playing around with hotwire I've decided that I like the concept very much. If the
keybindings can be made to be theme-able then it should be simple to make my own screen-like,
vi-like bindings.

Any thoughts on a mode-based shell? :)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 26, 2008 12:34 UTC (Thu) by mish (guest, #52694) [Link]

> After playing around with hotwire I've decided that I like the concept very much. If the
> keybindings can be made to be theme-able then it should be simple to make my own
screen-like,
> vi-like bindings.
> 
> Any thoughts on a mode-based shell? :)

I've typed up some thoughts before in this thread:
http://groups.google.com/group/hotwire-shell/browse_threa...

I'm hacking on other stuff at the moment though, so don't hold your breath.  But new hackers
are welcome if you want to help move this forward :)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 30, 2008 19:05 UTC (Mon) by massimiliano (subscriber, #3048) [Link]

There is work ongoing on making a free "posh", google for it...
It could be nice if the projects cooperated :-)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 26, 2008 12:53 UTC (Thu) by mish (guest, #52694) [Link]

> Also.. if it was possible to use this hotwire from a virtual console or just a plain xterm,
> then that would be fantastic. Screen beats the absolute living crap out of any sort of
tabbed
> system I've ever seen in my life.
> 
> Basically I have nothing against nice friendly gui systems.. that's very good. Even if you
> still end up requiring a special python gui to run hotwire, I would like to be able to
disable
> the tab bar, menu bar, and the scroll bar and still be able to use it.

I definitely expect that everything should be able to be done without a mouse - I think that
is possible now, and I have some other ideas that would extend that (though they're not at the
top of my list to do yet ...)
http://groups.google.com/group/hotwire-shell/browse_threa...

Also, the code is intended to be split so that the core code is separate from, and does not
depend on, the UI code.  (Note this split is currently not clean - there are dependencies).
This would allow other UIs to be written, including a UI that can run inside an xterm.  It
should also (eventually) allow the core code to run on a remote machine while the GUI runs
locally.

But don't hold your breath (unless you want to help make the split cleaner and write the xterm
UI ;-)

Hotwire: a combined terminal/GUI for GNU/Linux (Free Software Magazine)

Posted Jun 25, 2008 9:45 UTC (Wed) by nix (subscriber, #2304) [Link]

But anyways, so the basic idea is that now we have these libraries, what if your shell was more of a *direct* interface to those libraries, and what if it made it easier to transition to using those libraries, just like how you would in a real program?

Aah, right, so rather than writing little tools that just consist of a library call, we can turn it upside down and write tiny library functions that do little more than run a tool :) I suppose that works just as well: the hard part is getting there from here ('cos a lot of stuff, especially older stuff and the filters that are most useful on the command line, are *not* wrappers around libraries --- yet.)

Transitioning to a more widely used VM with Python support seems like a good idea. I suppose the historical problems with using the JVM, at least, aren't so significant anymore (the historically enormous JVM startup times are much smaller these days, and it doesn't matter so much because you only take that hit when you start Hotwire as a whole).

Your Hotwire-specific decorators are nice enough that expecting people to produce them doesn't seem incredibly harsh: of course it's generally the people who write the language bindings for whatever-library in (Python|Java|C#) who'll need to do that.

Regarding ps(1) in particular, it used to be a pain in the butt to handle in days of yore when every system had a radically different ps(1), but even if you have to be portable to systems without libproc, a combination of 'ps -o' and a small wrapper function allows you to inspect output really quite easily. (I long ago wrote a C wrapper which allows you to feed I/O in and out of pipelines directly from functions with persistent state, generator-style, and I'd be amazed if others hadn't written similar things. I should make it public, I suppose, but it barely seemed worth it, and the code, well, it still looks like it was written by a fifteen-year-old).

(hotssh looks really quite neat as well.)

OpenJDK + Groovy

Posted Jun 26, 2008 2:56 UTC (Thu) by ringerc (subscriber, #3071) [Link]

If you're looking to move it onto another language/VM platform for the final version and are
considering the JDK, you might want to start with Groovy. It's interactive interpreter
features and generally more dynamic structure would be a better fit for building a shell than
compiled Java would be.

In particular, being able to load and run Groovy scripts (as well as compiled .class / .jar
format commands shipped by libraries etc) would be really handy. Libraries could ship fast,
precompiled jars that your command classloader could quickly pick up, but users could write
groovy snippets and scripts without needing the `javac' step. Handily, groovy can be compiled
too, so if you do then want to package your groovy scripts as fast precompiled commands you
can.

Sounds good to me.

I would personally much prefer to see it take the Java path both because the JVM is now GPL
and because Java is subject to the JCP. It also has excellent backward compat. Mono, while the
codebase is free, is still very tied to Microsoft's language direction, and I'd be a bit
nervous about building new core OS infrastructure on it myself.