OSDev.org

Jo?o Jer?nimo wrote: there is no concept of learning while you use a CLI tool, as you have always to consult either the handbook, the man pages, or the --help option before knowing how to do something...

well, i don't quite agree. In a well-designed set of CLI tools, there are common flags such as --verbose, --quiet, --force, --recursive, --help that all the tools implements and that (quite) the same way with all tools. There are other things you can learn to make interaction easier such as "*.mp3" stands for "all the MP3 files", or that hitting "TAB" will complete the current word, and that hitting TAB twice provides you a list of possible completions if there's more than one option.

Now, i have to admit it's far from being the easiest way to "jump into" computer. If all you have to do is "open a document with the only one program that can handle it" or "start the all-in-one application that i use for CD burning", an icon is just fine...

Also, the fact that the text shell languages are more or less interpreted programming languages makes CLI shells a bit harder to learn than a slave that speaks english or some other human language (like portuguese, for exemple)! It also makes them impossible to be read, thus not allowing us to pipe a speech recognising program to the shell's stdin...

What makes the slave "easier to use" is that it has brain of is own. A computer doesn't: it only has the knowledge developers put in it. That being said, what would have you said to your computer if you want to put audio tracks on a fresh writable CD ?

U: "i want to burn a new CD"

suppose i don't know what application on my Linux system is capable of "burn a new CD" ... I just type "apropos burn", which just replies "k3b (1) -- KDE CD burning program". that's almost unambiguous. If some "speaking shell" is there, it can identify "i want to" as being just informative and "burn" and "CD" as being interesting keywords, then it'll run "apropos burn" and "apropos CD", and use the lines that match both to consider the options.

What you'll probably want then is information about whether starting a program is "sensible" or not. Launching K3B by mistake isn't an issue, launching re-partitioning tool, etc. could be ... So the computer would silently run the application (that is, it will launch it, tell the user it has done so, but won't wait for the user to confirm "CP: shall we start "k3b, KDE CD burning program", milord? " -- "U: make it so!")

Now, honnestly, in a futuristic house, do you think you're going to dictate "U: from author 'Madonna', pickup song 'Music' and 'Like a Virgin'" or do you think you're rather ask to see it "on screen" and expect the computer to locate you in the living room, turn on TV, and send the list of your favourite tunes on the screen, so that you can pick what to be burnt.

Oh, and you know when i'd really love a speech interface ? when i'm below the desk messing with the cables

they can be or not be easy to use, and can be more flexible or less flexible, depending on how they are designed...

I'd like to take "text searching" as an example here:
---- start a new program (grep) to do the test search
+--- click an icon/menu to pop up a search box
++-- hit a keycombo ('/' or 'CTRL+F' or 'CTRL+S') to pop up the box
+++- just hit the keycombo, then type the word you search ... the matches are highlighted and you're told what combo to hit if you want to search for the next/previous occurence.
++++ same as above, but working on all programs, with the same combo, and responding immediately.

For latex documents, my emacs does +++- and responds immediately. That means if i've spotted a typo on a printed document, i just have to hit "CTRL+S", start typing the words around the typo until i see the sentence on screen. When i have it, i just hit one of the arrow key to move back to the begin/end of the word, and fix the typo. Never experienced something similar in MS-Word (though i might be guilty of not asking clipper )

Pype.Clicker wrote:

Jo?o Jer?nimo wrote: there is no concept of learning while you use a CLI tool, as you have always to consult either the handbook, the man pages, or the --help option before knowing how to do something...

well, i don't quite agree. In a well-designed set of CLI tools, there are common flags such as --verbose, --quiet, --force, --recursive, --help that all the tools implements and that (quite) the same way with all tools.

Yes, but then you have the badly designed CLI tools!
You have *many* tools that won't understand you if you ask --help nor -h... some will only understand --usage, etc...
--verbose/-v are other example that is not enough common...
And for example make scripts sometimes have --prefix=???, others read ${PREFIX}, and other are impossible to configure the prefix...

There are other things you can learn to make interaction easier such as "*.mp3" stands for "all the MP3 files", or that hitting "TAB" will complete the current word, and that hitting TAB twice provides you a list of possible completions if there's more than one option.

All these are features of the CLI shell, which is a CLI program which features have to be learned from documentation, too...
You will not learn them because you use your shell, but only if you read it in the documentation or someone tells you (unless you press TAB by mistake and notice the effect...

Now, i have to admit it's far from being the easiest way to "jump into" computer. If all you have to do is "open a document with the only one program that can handle it" or "start the all-in-one application that i use for CD burning", an icon is just fine...

Yes, but if you wan't to delete all the files starting with a "J", having an unknown letter, then a "b", and then any other letters, you have no eficient way of representing it on the GUI shell... In a UNIX-like OS, I'll go to the diretory with my CLI shell and do "rm J?b*" which is fine...

Also, the fact that the text shell languages are more or less interpreted programming languages makes CLI shells a bit harder to learn than a slave that speaks english or some other human language (like portuguese, for exemple)! It also makes them impossible to be read, thus not allowing us to pipe a speech recognising program to the shell's stdin...

What makes the slave "easier to use" is that it has brain of is own.

Not exactly, because the slaves were educated not to use their brain...

A computer doesn't: it only has the knowledge developers put in it. That being said, what would have you said to your computer if you want to put audio tracks on a fresh writable CD ?

U: "i want to burn a new CD"

First, ask the kernel to execute the CD burning app (note that the aplication is equivalent to the slave, not the computer)... then, I tell the app to create an empty CD "Create a new CD", then, I would tell it what musics I wanted to add to the CD "Add X", Add Y", etc...

suppose i don't know what application on my Linux system is capable of "burn a new CD" ... I just type "apropos burn", which just replies "k3b (1) -- KDE CD burning program". that's almost unambiguous.

I've lived happy until now without knowing that command!
But if you find that useful, there could be an app that would tell you what program does some thing...

JJ

Jo?o Jer?nimo wrote: Not exactly, because the slaves were educated not to use their brain...

I would consider, a semantic analysis of a command given in a human language, a reasonably great effort of a slaves brain, compared to what computers (programms) currently (can) do.

HEH! Many people still doesn't use their brains at full capability even today. ;D

That's totally normal, even their autonomous systems like understanding a command works, which is very much something what to not like about.

Cheery wrote: HEH! Many people still doesn't use their brains at full capability even today. ;D

That's totally normal, even their autonomous systems like understanding a command works, which is very much something what to not like about.

I know perfectly that command line interfaces are easier than many people think... but if someone ants to remove CLIs completely, it's not easy to replace it as a powerful shell...

JJ

Jo?o Jer?nimo wrote: I know perfectly that command line interfaces are easier than many people think... but if someone (w?)ants to remove CLIs completely, it's not easy to replace it as a powerful shell...

The question is do we really want to get the CLI out? Or do we need the CLI to be better integrated with the graphical shell ... I know i often pop my "FutureShell", but why couldn't you just type what you want to "CD" into and have a visual confirmation of the folder... If you need to do something slightly complicated like "foreach (*.wav) oggencode %.wav %.ogg", that'd be just fine to type it ... or you just type "*.wav" (or J?b*), see all the files selected, then right-click on any of them and select "encode into .ogg"

Pype.Clicker wrote: The question is do we really want to get the CLI out? Or do we need the CLI to be better integrated with the graphical shell ... I know i often pop my "FutureShell", but why couldn't you just type what you want to "CD" into and have a visual confirmation of the folder... If you need to do something slightly complicated like "foreach (*.wav) oggencode %.wav %.ogg", that'd be just fine to type it ... or you just type "*.wav" (or J?b*), see all the files selected, then right-click on any of them and select "encode into .ogg"

The idea of mixing two shells types has the problem that you can't control everything with the same input device...

JJ

You have two devices anyway, mouse and keyboard. My shell idea is roughly similar to Pype's, if nothing is currently selected (ie, the "desktop" has focus with no icons being manipulated), or you hit a shortcut key combo, then typing will actually type directly onto the desktop (think a transparent command window). This means you have a graphical interface with all the shininess and easy-clicking inherent there, while still retaining the power of a commandline whenever you want it.

Kemp wrote: You have two devices anyway, mouse and keyboard. My shell idea is roughly similar to Pype's, if nothing is currently selected (ie, the "desktop" has focus with no icons being manipulated), or you hit a shortcut key combo, then typing will actually type directly onto the desktop (think a transparent command window). This means you have a graphical interface with all the shininess and easy-clicking inherent there, while still retaining the power of a commandline whenever you want it.

The problem is when you are using yhe keyboard and need to switch to the mouse or vice-versa... it takes time...

JJ

If you're new to computers or only have one hand maybe One hand on the mouse and one hand on the keyboard works fine for me when I'm not typing (note particularily that's the standard for most games), when I am typing it takes a whole second to put a hand on the mouse.

Kemp wrote: If you're new to computers or only have one hand maybe One hand on the mouse and one hand on the keyboard works fine for me when I'm not typing (note particularily that's the standard for most games), when I am typing it takes a whole second to put a hand on the mouse.

When i'm working in a GUI I rarely have a hand on the mouse and other on the keyboard... usually I only have it at the keyboard, unless i'm doing something for which I need to use both... not very desirable in a GUI...

JJ

An advantage of a well designed VAUI (Voice Activated User Interface) is that you don't have to write any video drivers, only sound drivers! Although I personally would choose writing video drivers over voice recognition software anyday.

Of course, not everything would be possible by voice, but a VAUI vs GUI argument is like the GUI vs Command Line arguments of the early 1980s.

A real advantage of a VAUI is for computers where screens would not be found or needed, such as in a vehicle or in robotics. Imagine driving while your car reads you your e-mails and then Googling for the movie session times at a local cinema (assuming the VAUI comes with a voice-activated web browser). It wouldn't be too good if, say, you had friends with you and you car automatically begins reading a love letter from your girl/boy-friend.

But before we get too far into the future, I believe the easiest implementation of a usable VAUI would be a microphone-wrapper for the keyboard of a command-line, whereby saying a key would simulate pressing it (for example, saying "ar ee bee oh oh tee enter" to type "reboot" on the screen). I could imagine walking into Microsoft and yelling at the top of my voice "EFF OH AR EM AYE TEE SPACE SEE COLON SPACE SLASH QUE ENTER WHY ENTER"!