ETH Oberon FAQ appendix: Command Line Interface (CLI) compared to TUI

In a comp.lang.oberon article dated 26 Nov 1999, Ronald Praver wrote:

What is your response to having a CLI (Command Line Interface) viewer as an extension to STRAW HAT OBERON. Does it sound useful, desirable or whatever ??? With this kinda like a shell in Unix/Linux we might be able to cash in on existing cost from the other OS's. Let me know!

Several participants reacted in favour of a CLI extension with a scripting facility for reproducing long sequences of actions. Among them we may cite: Bart Van den Bossche, Juergen Kahrs, Lars Duening, Anes Sadikovic.

On 30 Nov 1999, J. M. Drake issued a longer counter-argument which is reproduced here, unedited and in its entirety [at the ETH, we agree with this viewpoint].

Well, it looks like I'm the lone voice of dissention, but dissent I must. :-) (Well except for the classic crack against MS-DOS.)

At the base level a CLI offers absolutely nothing over a TUI (Textual User Interface). What do I mean by "base level"? Does anybody here, besides me, go back far enough to remember CP/M? That's a "base level" CLI. It has little, if any, scripting, no piping or redirection, etc. A CLI means that when you press "ENTER" the command is executed. With a TUI you can do pretty much the same thing, except that the command isn't executed until you click on it. Someone raised the issue of "when" can you type in a command in a TUI. Answer? Anytime you feel like it! You don't have to open up a "blank window" and type your new command in. You don't have to put the new command into the log. You can put it in any document you happen to be working on. Say if you're editing a module and you want to test a new command. Just type it in and click on in the that same window. It's just that simple. Sure, it takes more to type in :

System.DeleteFiles file1.txt file2.txt file3.txt ~


del file1.txt
del file2.txt
del file3.txt

But if that's all you can see, you're missing the point. Names in typical CLIs are short (and cryptic) because you're likely to type them again, and again, and again. The Oberon TUI saves on typing, hence command names can be longer and more meaningful.

CLI scripting - CP/M is an example of a command interface that has little or no scripting capability. (I would probably go so far as to say no only to have someone post a "my brand-X CP/M machine had scripting." I'll just say that the CP/M I worked on didn't have it, at least as far as I know.) But what about the reverse question? Can you do scripting in a TUI? Answer absolutely!!! Proof by example is JavaScript and VBScript. After all, HTML is really a variant on a textual user interface, except that it's not as "transparent" as Oberon. But scripting, on a lower level, has been done in Oberon also. Anyone who's ever used Installer.Install to load a package under ETH Oberon has used a script. Ok, so the scriping language for Installer is special purpose and lacks niceties like FOR loops. But that doesn't mean that a more general scripting language couldn't be written without adding a CLI.

As for those who can't "get into Oberon" unless it has a CLI, I have one piece of advice, drop your preconceived notions of how a computer is supposed to work as, as Nike says, just do it! Sure it takes some getting used, but it takes getting used to "rm" and "cat" in Unix after you been using "del" and "type" in MS-DOS. And if Oberon did have a CLI you would have to get used to typing "System.DeleteFiles" over and over again.

The Oberon TUI also gives "for free" other things that have to be added to CLI interfaces as "features". A good history comes to mind. I can't tell you the number of times that I've been caught in the Java edit-compile-run development cycle that I've hated the fact that the Java compiler and Java interpreter names are so similar. Thus when I type:

java foo

I can do !j (in Unix) to run "java foo" again, but I can't get back to the compiler command unless I remember where it is in the history list! Major pain. Unnecessary in Oberon. In Oberon you also get "session capture" for free. In Unix you can "redirect" your output, but you can't see what you're typing. If you use the "script" command in Unix (which, as far as I know, is unavailable in MS-DOS) you can save your output, but my experience is that script often appends "special characters" to your work. This is where I have found a CLI in Oberon helpful, namely the "Terminal" package that comes with the V4 Solaris implementation. It's not a CLI for Oberon, but a shell for Solaris that runs under Oberon and gives Oberon's screen capture capabilities.

However, the best feature of Oberon's TUI as opposed to a GUI is that a TUI seems, to me anyway, to be a natural bridge between a CLI and a GUI. When prototyping a project, commands can be typed on and clicked in a manner which isn't that far removed from a CLI. But these same commands can be rapidly incorporated into an ETH Oberon "gadget", a BlackBox "form", or a V4 "Dialog". In ETH Oberon, these command can be tied to variables on the gadget by use of macros. (Yes, Oberon does support macros. Had to throw that in there.)

Whew, another post that's turned out to be longer than I meant. :-)

I have to add this thought. I'm not writing this to turn you off from writing a CLI in Oberon. Quite the contrary. I think you should do it, if nothing but for the learning experience. If you've gotten an understanding of the Oberon programming model you should be able to whip out a rudimentary CLI in a weekend if you limit the project to a CLI that simply lets a user type in a single command and it's parameters and then press "ENTER". Perhaps then someone who gets tired of using such a limited CLI will write a scripting language for it that you will then be able to "back-engineer" into the Oberon TUI proper. ;-)

7 Feb 2000 - Copyright © 2000 ETH Zürich. All rights reserved.