Use Standard English in Command Line Interface (CLI)

1

Do not follow the Unix and Linux style of cryptic, unintuitive commands in the Command Line Interpreter (CLI). Rather do what Digital Equipment Corporation (DEC) did with their Digital Control Language (DCL) and other companies did with CPM and DOS.

Make the commands in the CLI standard English. The command for help should be, just that, HELP. To print something, PRINT. To display a directory, DIRECTORY. To concatenate files, CONCATENATE. To invoke mail, MAIL. Edit a file, EDIT. To compile a program, COMPILE. To link/bind together objects and libraries into an executable, LINK or BIND. Etcetera, etcetera, etcetera.

Support symbolic definitions. Those users who wish to use symbols then may do so, using such non-intuitive commands such as MAN when HELP is needed or GREP to EDIT a file. A symbol may actually override a system command. This is not necessarily a mistake, it may very well be intentional. A warning message should be issued at the time of symbol defintion indicating a system command is overwritten but, allow the (re)definition to occur.

For the power users, they can create a command file (script) that performs the symbol definitions at startup, so when they use the CLI, UNIX users have their GREPs and MANs and others have whatever makes them comfortable.

Require uniqueness to determine precedence. Suppose a user uses a symbol such as EDT to invoked an add-on editor. If the user then types only ED, the system editor is invoked because according to uniqueness precedence, the first command, system or symbolic, will be EDIT rather than EDT. This is not problematic but usual and intuitive, because this is way most people think. The user could just as easily redefine EDIT or define ED to invoke an add-on editor.

Likewise, abbreviating a command means shortening it rather than redefining it. So, ED[IT] invokes the system editor or DIR[ECTORY] displays the contents of a directory and if no other command began with H, H[ELP] invokes help. Note - the letters between the brackets would not be typed, I show them to clarify what command may be invoked.

It is unreasonable to expect everyone to be a nerdy, UNIX geek :-). And though UNIX and Linux support symbols, their CLIs are Greek to the uninitiated or inexperienced. It will require the assistance of others or additional instruction for them to make use of a UNIX/Linux CLI. The price for this is lower productivity and diminished acceptance.

Bottom line, you want users productive as soon as possible with the least amount of interference or support.

2

The CLI is not used primarily by people anymore. It’s a place where scripts and tools of all kinds co-exists and make up software stacks. For example the GNU tools used to build Haiku, the GNU compiler collection, make, autoconf, etc, ad absurdum - they all need a standard shell. Replacing bash with something incompatible is almost as unthinkable as replacing C or C++. Alternatives to complement the default, yes. Replacements, no. Not unless you want to 10x or 100x the work to complete Haiku. Imagine not being able to use GCC, having to first create your compiler and tools, then create the OS, then create alternatives to all popular applications you can’t build anymore since you’re not compatible enough with Linux and the other POSIX-ish systems. It would be a nightmare, unless you’re into simplicity and/or reinventing the wheel.

What you -can- do is create a UserFriendlyTerminal to complement Terminal, (or just an alternative shell interpreter to run in Terminal), with all the natural language constructs you want. It would be user friendlier, but why would anyone use it, when all tools and scripts are made to run in classic, unfriendly shells?

I personally hate uppercase keywords. What an eyesore. We’ve got lower-case too these days. :))

3

LIFO.

Uppercase, except when used for acronyms and formal names, was used to differentiate the commands from normal verbage. The emphasis, after all, was on the use of regular English for the Command Line Interpreter (CLI). However, I agree, use of uppercase for its sake alone is unnecessary.

Another product easing the use of the CLI, as a substitute for replacing the CLI, is unnecessary. Haiku is not a UNIX/Linux clone - fresh, from the ground up, is the claim.

A script, containing symbolic command definitions, executed at startup, or when starting the CLI, permits the use of GCC or any other UNIX/Linux command, nothing is unusable. This is a feature already available in the UNIX/Linux BASH, DECs (DCL), IBMs (JCL), etc.

Asserting that replacing the CLI will ‘10x or 100x the work’, as either a range or a choice of impact, is ridiculous and moot without quantitative and qualitative data for comparison.

Head-in-the-sand is not a Haiku characteristic. If replacing BASH, or C, or C++, is unthinkable, and this were the norm, Haiku would have no chance in the mass market.

Haiku is a product geared for the consumer, otherwise; it would relegate itself to the already crowded 1% of the market shared by all other non-Windows systems.

Cliches, such as, “re-inventing the wheel”, “if it ain’t broke, don’t fix it” and “this is the way we have always done it”, are inconsistent with Haiku.

The CLI is a tool, not a place. And, as long as there are people, there needs to be a CLI.

Regardless whether Haiku is at a mature stage or in a development stage, hamstringing UNIX/Linux neophytes is a sure-fire way to equally hamstring productivity and acceptance.

4

Be’s marketing memes, while catchy, were part nonsense. The BeOS and the BeBox were results of taking good parts of other systems.

I would love to see true innovation, but that always comes at a price. Programmers primarily use lots of parts that are already available. Starting from scratch, the life of a programer becomes “interesting”, and utterly painful. Some people enjoy that, but they are in the minority.

I would love to have a better CLI shell, better programming languages, better compilers, better hardware, but it grows exponentially harder to replace each sublayer. You have to compromise away all the things you take for granted.

It may be possible to add a little natural language aliasing on top of bash, but it’s still the same old shell. Aliasing ‘ls’ with LIST doesn’t help users much, when all scripts you may encounter use ‘ls’.

Regarding the 10x or 100x… I don’t know, but if Haiku wasn’t to be POSIX-compatible, and didn’t have, or by some other means support, a classic C environment, we wouldn’t be able to use GCC, and lots of other software, and then we’d be far behind the other OS:s, having to work on a compiler toolchain in addition to the work of creating device drivers, graphics and re-creating software from scratch rather than patching and porting software that other people have already written.

5

Since it seems shifting the shell away from the *NIX/POSIX realm might be difficult, would a base install alias script be an option? Something that fired up the first time the CLI was started and mappped 

dir->ls
help->man
ipconfig->ifconfig
etc…

I’m happy as long as I can jump to bash, and I think there are more scripts written for the *NIX-iverse than .bat files now. However, I would agree that some early adopters might just be coming from a Windows world and looking to Haiku for an easier alternative than Linux. For those folks, a quick prompt saying something like, ‘Do you want us to use DOS commands? (y/n)’ would at least give them an option to use what they are familiar with. And iirc, you could echo the *NIX command back out to start training adopters to the expected format.

Just a thought.

6

It’s common to see these comments from people who aren’t used to UNIX and bash/tcsh/ksh.

The thing is, UNIX commands have had their names for 10-20-30 years. I’ve spent I don’t know how many hours learning to use it since I switched from the old Mac OS, and then later using BSD on some of my computers. I know that there is a learning curve, but once you tackle it, you learn some tricks that flat out aren’t possible with GUIs, and you learn to do stuff that you don’t want to live without. That’s the curse and the strength of the command line - the power is there, but it’s hidden, slightly obscured, and you have to read books (of which there are millions, by the way, some are good, too!) to harness it. You trade off an ease of use for the first 100 hours in order to make it a better experience for the next >100,000 hours. I don’t think anyone who’s been on the CLI for more than a week is still thinking, what is the name of that command to list what’s in a directory - sooner or later it’s just muscle memory…

Another thing, why is DIR (to see the contents of a folder) more intuitive than ls (list)? And should we have CON(tents) and TELL( me what’s in this folder, you stupid piece of junk) as well? Until computers get smarter, plain English just doesn’t work very well, because the illusion that the computer speaks English will never be complete – and what about localisation?
In the end, user would still have to read up on the commands to know which did what, and changing them would just lead to the huge tasks of documentation, and maybe even reimplementation, when we can just drop the tried, tested, familiar, and well-documented bash/ksh shell in there and have >75% of a system that a lot of power users know and love.

I’m all in favour of trying to move more of the power of the command line into the GUI (GUI pipes! Sort it out!) but changing to a dumbed-down set of UNIX tools (and it will be dumbed down to begin with) with new names wouldn’t accomplish anything of worth, IMHO.

7

This is an interesting idea, applying the idea of symbolic links to terminal commands.

I’m more than comfortable in bash, much more so than a DOS prompt. But there are those that will be coming from Windows, and I could see how it’d be nice for them to use “dir” and all those other commands they’re used to.

(BTW, “dir” is more intuitive than “ls”. Afterall, a monkey can figure out that “dir” probably is short for “directory”, while “ls” is just two seemingly arbitrary letters. But we’re not here to say UNIX shell commands are or are not better than their DOS counterparts. We’re discussing symbolic links for terminal commands.)

I really don’t see a problem here; it’d work just like symbolic links in a filesystem: you can call the link or you can call whatever the link points to directly–you’ll get the same file or directory either way. I don’t see how this would break compatibility for scripts, as the classic terminal commands would still work just fine; in fact it could be argued that it would add a layer of compatibility.

The question is, would something like this be feasible and worth the effort? I can’t answer that, but I’m guessing it would be No.

8

Adding DOS-named symlinks to the equivalent commands in Unix won’t help people coming from Windows, since arguments, pattern matching, the filesystem, etc, (job control?) are very different. You can’t hide the fact that it’s not a DOS shell. Batch files won’t work, and people won’t be able to type the command switches they remember from Windows. So why bother?

It’s not like DOS shells are more intuitive / user friendly.

This from someone who’s got a ‘cd…’ alias for ‘cd …’

9
You can't hide the fact that it's not a DOS shell.

Very true, nor would we want to. But you can make the transition easier on Windows users by offering many of their commands available in bash. Afterall, Be decided (in R4?) to allow users to choose whether they want Alt or Ctrl, and they did this to make the transition easier on those users coming from the PC.

I don’t think it’d be a worthwhile idea, but it’d be a cool thing to have nonetheless, and I think some people would benefit from it. I could be wrong, though. :wink:

10

“alias” is a bash feature, and it’s already there.
In fact, many linux distro already alias “ls” to “dir”.

11

Comparing MS-DOS DIR to Unix ls:


http://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1

DIR [drive:][path][filename] [/A[[:]attributes]] [/B] [/C] [/D] [/L] [/N] [/O[[:]sortorder]]
[/P] [/Q] [/S] [/T[[:]timefield]] [/W] [/X] [/4]

ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx1] [file …]
(+ piping to ‘more’, etc)

You can alias or symlink one to the other, but they’re still very much incompatible. If you’re going to learn the other set of command switches, the command name is the least of your worries. It’s two incompatible worlds.

Even if one made look- and work-alike DOS command binaries, to run on Haiku, the default shell itself treats stuff like * > pipes etc differently - a lot of these things are handled by the shell and not passed on verbatim to the command itself - so you still wouldn’t be able to type command sequences the way they are written in magazines, webpages or scripts. You would have to also create a DOS shell with it’s own DOS-view of the mounted volumes, in which you run your DOS commands. A fun project perhaps, and it might help a few people who are strong in DOS, but I can’t see how it would be a giant leap of usability.

On a positive note, have a look at MacOSX Automator.
Now that’s something I’d like for BeOS/Haiku myself.

12

Maybe standard windows commands should simply return a help page showing the equivalent bash commands… That was my biggest struggle when first learning Linux coming from a Windows world.

13

I don’t think it’s necessary to emulate DOS behaviour and syntax to the full extent.
It would be helpful newbie user to key in dir (something) and merely get short ls usage description or at least “use ls --help” for help.
That would save much time for the user. I recall myself once as a fresh Linux (and BeOS alike) user trying to remember how to dir or type.
Such approach could be considered as a tutorial rather than emulation/compatibility since “dir c:” would most likely result something like “try ls --help”.
Only one consideration. DOS “help” should not be linked to “man” but to display short overview of differences.