[Scene_Cast]

I am one of those people who thing that CLIs are not user friendly. The premise - giving a computer instructions via Natural Language (NL) - is very sound. However, the way CLI is done right now (from the ground up) - is broken. The most obvious example - why are CLIs ASCII-based? I want to pass around objects - "ls" should only give me just that, an array of objects (which can be serialized for output in any graphical way, including ASCII). There shouldn't be any ASCII flags or switches - those (if really needed) should be an array of objects as well. Another example, piping, something that UNIX proponents are quite proud of, is a good concept, but it isn't perfect. I can't even count the number of times I wanted to pipe an output of one program to multiple others, or pipe multiple programs into one. The list goes on and on.

CLI is the best tool that exists at the moment for a few things, but I definitely see how there could be a superior, semi-graphical, non-"scrolling-ASCII-buffer" alternative.

Note: I have tried Linux as my main OS for almost a year, I've done extensive dev under Linux, customized the hell out of my .profiles and *rcs, etc. Still, I see it as flawed. If someone comes up with a sane CLI, I'll be the first in line.

[ori_b]

> I can't even count the number of times I wanted to pipe an output of one program to multiple others

      ls | tee >(frob x) | grep y

should output the output of ls to both 'grep x' and 'grep y'. The '>(foo)' syntax in bash will create a subshell to run the pipeline in the parens, and evaluate to the name of the FD for the pipeline (eg, /dev/fd/42).

For multiple inputs, similarly:

     grep foo <(ls dir1) <(cat somefile)

[Scene_Cast]

Thanks! I didn't know about tee. My gripes were from working with something like this ( http://i.imgur.com/LnAvV.jpg ), and then trying to emulate that in CLI. (The picture shows a graph-based image processing system, Blender's compositing mode) --- Source: http://www.blender.org/typo3temp/pics/ca33eb4833.png

[ori_b]

That should probably get a domain-specific tool regardless; Generalizing the command line UI is probably going to end up getting too hairy for the common case.

[spc476]

"I can't even count the number of times I wanted to pipe an output of one program into multiple others ... "

There's nothing stopping you from doing that. Back in college I wrote a Unix shell (as part of a class project in Unix Systems Programming) that, in theory, could do that but I lacked a decent syntax for doing so. Perhaps that's an argument for a GUI, but what you ask for is certainly possible (although the semantics of piping multiple programs into one is hard to resolve, at least in my mind. Do you interleave by characters? By line? User specified? How?).

Also, writing an "ls" that output "objects" is also quite trivial, but the tooling required to convert (or write from scratch) existing command line tools is large. Also, the semantics can get quite rough.

"There shouldn't be any ASCII flags or switches-those (if really needed) should be an array of objects ... "

Again, I can go back to the shell I wrote in college. The arguments to a program were stored in an array. In fact, that's how you had to specify the arguments, as an array. It was an interesting shell, enough to get me an A in the class, but I never used it as an interactive shell. Typing commands (which were first class objects, by the way) was a pain. But boy could I sure could pipe stderr to more and stdout to a file.

Perhaps what you need to do is try to implement your own shell that works the way you think it should work. You could be the one to implement a sane CLI ...

[quanticle]

Have you looked at Windows PowerShell? That's exactly what it does. You don't pass around ASCII streams. You pipe .Net CLR objects between programs. I haven't seen much done with it that you couldn't do with a non-graphical shell, but, in theory, you could write filters for e.g. image data that worked exactly like text filters in bash.

[ricardobeat]

I have no idea what you mean by "passing around objects", and I guess that wouldn't make it any more friendly. An "object" is an abstract concept that must be known beforehand, and is just one in a myriad that could exist in the context of interacting with a computer.

Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/

[underwater]

If I want to work with e output of ls, why do I need to manually parse fragile strings?

It would be neat to have basic stringable primatives, like maps and tables, that scripts could write and read.

[ricardobeat]

You can't approach things from a programmer's perspective when thinking about interfaces. I mean, I see your point, but how would that make it any more user-friendly? More powerful, sure, but it would require an extra layer of abstraction, which is going in the directly opposite way of user-friendliness.

Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.

[spc476]

I personally prefer the CLI over the GUI since that's primarily what I'm used to. I also dislike control panels (a type of GUI) because they tend to restrict what I can and can't do, but at the same time, I get frustrated when using someone else's CLI. I go into a bit more detail in a blog entry I wrote a few years ago: http://boston.conman.org/2007/05/29.2

As I wrote: "GUIs, on the other hand, restrict the language available to the user, thus enforcing an interactive conformity—much like L'Académie française does for the French langauge (or rather, tries to do). It's not so much about enhancing productivity as it is usability in general (or communication, take your pick)."