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)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 ...
Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/
It would be neat to have basic stringable primatives, like maps and tables, that scripts could write and read.
Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.
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)."
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.