Slashdot Mirror

There is something like that -- based one Mozilla.
Called XMLTERM

XMLTerm mixes the command line and XML hypertext. I find it an instersting concept.

Perhaps :-)

I wanted to say that the existing Unix/Linux shells (1) are mutually incompatible (2) are often a pain to program (bash, uh) and use, (3) and some big vendors still keep the oldest and least friendly.

(1) Yes, they are. (Personally, I use bash for exactly that reason, since it keeps me from remembering to many syntaxes as bash is essentially sh++) (2) Well, I think bash is pretty ok. But of course, there could be lots of room for improvement. And yes, since you mentioned it, PATH (and CLASSPATH, LD_LIBRARY_PATH, etc) being colon-separated instead of newline separated makes it harder to manipulate it without a few nifty aliases. They should be standard and builtin to make things easier. (3) Well, trading backwards compatibility with user-friendliness is not always so easy. But since most shell-scripts start with #!/bin/sh anyway, it would make sense to give the users a more friendly shell by default.

Why do you think yet another new shell will fix that?

And as we both know, there are plenty of alternatives already. In particular, the following shells are all "better" than sh for end-users: tcsh, ksh, bash, zsh, es, and tclsh. It's not obvious that a new shell would improve the situation more than just add to the confusion.

But, for example, some aspects of the CLI could benefit a lot from a insightfull redisign.

I most definitely agree. But designing a "better shell" is very hard, and most people fail (look at the (lack of) success of es for example). The tradeoffs between terseness (for command-line use), regularity (for scripting), familiarity (to get anyone to use it at all), simplicity (to be useful for newcomers), and expressivity (to be the best tool for experts) makes it as much an experiment in psychology as in programming.

I doubt that we will ever reach shell-nirvana in unix (or any other place for that matter, but windows has a large advantage here, one of the things that holds us back, is that we still care about being able to run the shell over telnet to a teletype, but in windows they will probably make the default user experience to be more like e.g. emacs interaction mode, nice menus and all... By the way, have you ever looked at XMLterm? It's nice, and certainly innovative :-) Why not combine it with XML shell to get away from the pipe-filter on characters/lines only paradigm?).

The current unix-shells are the result of decades of stepwise improvements on a really good idea (at the time), and continues to be so much more useful than any of their alternatives that it's going to be hard to penetrate the "market"...

Not that it wouldn't be worth it though :-)

Because after the different UNIXes splitted, it was very difficult to make new major innovations to the system. Those innovations would have to be very important to be worth of being adopted by POSIX et. al.

It's the same as the PC and the floppy disk. After IBM lost his control over the PC, the system were kind of frozen. We were lucky we could adopt this huge 1.44 Mb drives we have now.

In the case of tty's, there should be several things that aren't implemented:

• A sane character model, where all keyboard keys could be transmited
• True color
• It would be nice to have some more high-level primitives so that ncurses interfaces over ssh work faster
• Perhaps some kind of graphics upload to the terminal, so that it would be posible to do: $ cat Logo.gif and see the gif there :)

Some of these things are being implemented by the XMLTerm project, but I don't know the status of it.

It exists already.

Here is the CLI mozilla interface:

XMLterm

an interesting idea...

Have you looked at XMLterm? It's a strange hybrid between a web browser and an xterm. You can use it with 'pagelets' such as xls, which is like ls(1) but produces HTML where each filename is a clickable link - so you have a simple directory browser in your command line window. Also xcat can display many file formats directly in the xmlterm window (anything Mozilla can display, essentially).

I don't know whether this sort of thing will take off, but it's certainly worth a look as a possible way of combining CLI and GUI.

Nobody seems to have mentioned XMLTerm.

It's a Mozilla spinoff. Think of it as xterm with icons. The usual Unix commands (ls,...) are hacked to emit XML and Javascript, and the XMLTerm renders it accordign to your favoutirte stylesheet.

So ls can produce hyperlinked icons, and you can process the XML through filters,...

I find it very interesting though very hard to realize.

Have you tried it?
__

The name is unfortunate XML is supposed to mean X Window + HTML but, of course, its confused with, well, XML.

One way to implement such things would be to write a replacement for xterm and define a new terminal type. Just as xterm has escape codes to set the foreground and background colors, the new terminal could have additional escape codes to create or update certain display widgets

Personally, I think a term that would take

cat photo.png page.html

and render the image and/or HTML on the page would be a wonderful addition to the command-line toolset. However, the ability to work in text-only mode is a critical part of the appeal of Unix.

Hmmm... looks like the project's been pretty quiet for a while. Anyway, it's still a good idea.

Something got screwed up, try http://xmlterm.com/

I believe the ideal is a combination of command line and GUI. Some things are a lot quicker to achieve graphically, other quites awkward or impossible, but very easily done on a command line.

XMLTerm is XTerm meet icons and hyperlinks.

If you are looking for novelty in UI design, I think this is new. I don't know how easy or bloated it is, but it's different though, at the same time, it's known.
__

A GUI CLI, whodathunkit?

While it might not qualify as a pure example of an Anti-Mac interface, it could easily be mistaken for a transitional form. The screenshots from the web site tell the story better. Pay special attention to these two;

Graphics with text CLI

Collapsing output from the GUI/CLI like a folder list

A GUI CLI, whodathunkit?

While it might not qualify as a pure example of an Anti-Mac interface, it could easily be mistaken for a transitional form. The screenshots from the web site tell the story better. Pay special attention to these two;

Graphics with text CLI

Collapsing output from the GUI/CLI like a folder list

A GUI CLI, whodathunkit?

While it might not qualify as a pure example of an Anti-Mac interface, it could easily be mistaken for a transitional form. The screenshots from the web site tell the story better. Pay special attention to these two;

Graphics with text CLI

Collapsing output from the GUI/CLI like a folder list

A GUI CLI, whodathunkit?

While it might not qualify as a pure example of an Anti-Mac interface, it could easily be mistaken for a transitional form. The screenshots from the web site tell the story better. Pay special attention to these two;

Graphics with text CLI

Collapsing output from the GUI/CLI like a folder list

I think the biggest problem is that they felt they could not just build a *browser* but rather it has to be a "Web browsing desktop environment" that does everything except re-compile your kernel.

You severely underestimate the fine people at Netscape. Check out the xmlterm project. Yup, it provides you with a very cool xml-aware xterm thingie that models your interaction with a shell as a (dynamic) xml document. So you can cat (or xcat) html documents and have them rendered onto standard output...and re-compile your kernel for you in a subshell.

:-)

GUI/CLI love child:

xmlterm

It is quite unfortunate that masses are mixing up the notions of system functionality and of the actual science of User Interface.

It maybe a necessary functional requirement for an operating system to allow scripting capability, however user interface has actually nothing to do with that.

Scripting should be an essential part of a GUI. Apple has taken steps towards this (I've not really used it yet, and wonder how well it works), but until we are able to graphically/intuitively show the computer a task, and tell which set of objects to enact it on, computer UI's will remain in the dark ages where they are now. XMLTerm is taking great strides towards slick intergration of GUI and CLI, which is one step towards the future.

I imagine you're thinking of the Symbolics Lisp machine. It was/is indeed a very nice machine, running an operating system called Genera.

The user interface was quite special, indeed. It can best be explained as "XMLTerm on speed". It was basically a command line interface, but pretty much everything could be clicked on with a mouse. A status line on the bottom of the screen showed what different mouse button actions would do to the "object" currently pointed at -- very helpful.

Lots of information can be found on the Sy mbolics Lisp Machine Museum.

Oh, and by the way: Symbolics (the company) is currently developing and delivering Open Genera for Alpha-CPUs. :-)

this "beginner's" mode has got to be the most confusing thing I have ever seen.

I don't think UNIX folks will ever be weened from a command line interface. I know I feel somehow constrained if I can't start typing in commands. It just allows so much more expression and power than a GUI ever could.

That said however I know there are sometimes that a GUI is more convenient, especially when just learning an app. I know many people start out in AutoCAD using the buttons & menus but then move to the command line as they become more familiar with it.

Until GNOME & KDE apps are completely decoupled from their interface and allow plugging in scheme or perl to control them I won't be satisfied.

One interesting thing is several groups attempting to apply XML to UNIX. Somehow I am intrigued by an app that combines Bash with Windows Explorer