Rich Command Shells
waywardmonkeys.org
waywardmonkeys.org
The command line works with text. The command line remains the best interface I've ever used. It's user friendly, composable and available everywhere. It's easy to automate and easy to extend.
I wish the "command line with pictures" idea would just go away already. It adds nothing for the general public. I can already view pictures on remote machines with X forwarding.
Command line with pictures never made it, because there are ten competing standards. With text, everybody just agreed on ASCII and now Unicode/UTF8. Text has hundreds of ugly clutches on top of it (Extended ASCII, ANSI, Escape codes, etc, etc). It still works. It's still simple. It has its problems, but nowhere near as many problems as GUIs.
Those who don't understand Unix are doomed to reimplement it... poorly.
So why shouldn't we have a couple of extra escape sequences where the terminal could, e.g. draw an arbitrary bitmap? You are right, that would certainly require some sort of standard becoming prevalent, but why would a little extra capability (that doesn't break compatibility) be a bad thing?
By all means implement this thing - I wouldn't be surprised if there were already terminals that did that. But personally I'd be surprised if it caught on. Compatibility matters.
xterm actually support Sixel graphics now (although with 16 colors and a configure flag being set). Other terminals also support Sixel graphics, but not all terminal emulators and not the primary ones (Terminal.app, PuTTY, iTerm2, GNOME Terminal, etc).
Sixel and Regis graphics used to be available in actual terminals. I didn't mention Regis graphics in my post, nor did I mention Tektronix graphics, also available in vintage terminals. Both Sixel and Regis graphics were designed by DEC (Digital Equipment Corporation). Sixel was raster-based while Regis was vector-based.
Should we bother with Sixel today? Who knows? But there used to be standards for this sort of thing, but in the actual physical terminals, before we all switched to terminal emulators, most of which stuff with VT100 / VT220 emulation rather than anything too advanced. (Regis was available in the VT240, while Sixel came with the VT340, I think.)
Once the iTerm inline image support is out in an actual release, I have some tools that I'll update to support soon after.
But I have some follow up posts where I'll talk about some of this in-depth. This wasn't a random one-off post that I wrote. :)
(Writing HTML files is workable, but a bit annoying to use in practice, because if you don't run the web browser from your program (= more windows) you have to tab over to the web browser and hit F5. And that assumes you're overwriting prior results on each new run, of course, which you might not want to do (= more coding and hassle).)
I suppose it wouldn't even have to be HTML necessarily, but HTML has the advantage of being some kind of standard and many people are familiar with it.
That's scary. My browser is a very complicated tool that does a lot of complicated things and has a huge attack surface.
OTOH, the terminal is incredibly simple and does almost nothing. That has been a very useful division of labor these past 20 years and I'd like to keep it that way.
Is that true ? For instance, I am not aware that (for instance) the OSX terminal app does mouse reporting or geometry reporting.
Does default xterm ?
Kudos to Microsoft for bringing to Windows a little bit of Lisp Machine experience with Powershell.
Imagine having a workstation where the whole stack is written in Clojure (e.g. Lisp Machine).
Now when you open a REPL window, similar to what Common Lisp Interface Manager is, you can (:require) anything public from the OS, including applications, to interact with.
Powershell is similar in that, you are using objects and are able to reference any .NET class, COM instance or public functions from native DLLs by importing them.
So you can for example, import the Office COM automation API and interact with an Excel document that you just selected from the shell.
But More importantly, you can't change anything, you can only use it. So the FFI is nice and easy, but you could say the same about other languages. Or am I confusing things with Smalltalk images? Cl was somewhat before my time.
That's not to say CLIs are perfect for everything, because there are definitely use cases where a GUI makes sense.
But sometimes, the logical output format for the response from a command is going to be an image. And sometimes, you'd like to view that inline with your commands in the terminal.
That isn't that radical a suggestion. And it doesn't turn anything into a big old GUI suddenly. :)
Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored. Take a read of some of the earlier threads on HN about Shellshock, and you will find numerous people blaming Apache for not "escaping" the data it was putting in a shell variable. As if it even could.
Even Unix nerds have at least partially internalised the dangerousness of the paradigm -- "don't parse the output of ls" and so on. The fact that the Unix paradigm (passing everything as strings with magical characters and escape sequences) is broken for the most fundamental computing tasks like working with file names ought to be a damning inditement of the paradigm. Sadly people merely parrot the rote learned lesson "don't parse ls because file names can't be trusted", without thinking about all the other untrusted data they expose to unix shells all the time.
Just this week Yahoo got exploited. At first people thought it was Shellshock, but no, it was just a routine command injection vulnerability in their log processing shell scripts. A problem blighting just about every non-trivial shell script ever written.
The usual reply is "don't use shells with untrusted data". But auditing where any particular bit of data came from can be just about impossible once it has been across several systems through programmes written in a variety of languages, stored on a file system, read back and so on. The only sane solution is to never use shell scripts.
Like the C memory and integer model makes writing secure C code borderline impossible, the Unix "single pipe of bytes that defaults to being commands" paradigm makes writing secure shell scripts borderline impossible.
Unix needs to be taken out back and shot.
So how do you provide the same level of capability as C and UNIX but without mixing data and commands? Is there some alternative paradigm that is just as powerful but safe?
Yes! And then to compensate, they have to "sanitize" untrusted input to their systems. I had a meeting yesterday with a developer and a project manager at an organization that wants to work with my company to integrate one of our products with one of theirs. I mentioned the possibility of submitting some data in JSON format to a web API on their end, and the project manager asked about the risk of code injection attacks, by which he apparently meant SQL injection. I had to assure him, based on my knowledge of their tech stack (Node.js, CouchDB, and naturally, JSON) that code injection wouldn't be an issue. My point is that the common abuses of strings by Unix and web developers have led to well-known and widely feared security vulnerabilities which just don't exist in software that's built on a foundation of properly structured data.
See also this classic by Glyph Lefkowitz:
https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out....
It seems to me that this is the result of Cargo Cult Programming. People know that SQL strings, and user input need to be 'escaped,' so they just think "Obviously this needs to be escaped too! It's user input!" Yet they don't realize that they are trying to put a square peg in a round hole. They just know that pegs go through holes, so they keep banging away at it.
Also, it's always amazed me that there was never some sort of 'standard' way to shell-escape things, even though the shell has been around for ages. Why can't I generate a shell string in the same way that I generate a SQL string? E.g.:
sprintf("mv %t %t", src, dest);
Note: I don't generate SQL strings with sprintf(), but it's a close approximation of:
execute('select * from table where id = ?', id); execlp("mv", "mv", src, dest, NULL);
Edit: Fixed, thanks!
P.S. Doesn't execlp() require a NULL at the end of the parameter list?
People see:
execute("select * from table where id = ?", id);
execute(sprintf("select * from table where id = '%s'", escape(id)));
0'; delete all from user;'
can we stop with this please? I'm sure it's not your intention and it's the way it's always phrased but it's casual contempt and we deserve to treat each other and be treated better.
"escape() is written by someone who spent the large amount of time analysing all the issues, testing, taking and incorporating feedback so the rest of us, who are both smart and competent, don't have to duplicate the work.
in the other corner: the complaint that sometimes, people can put carriage returns in their filenames and screw up the output of `ls -1`. With no suggestion of what would replace composed functional streams.
Nice try Lennart.
How about functions that operate on data structures such as lists and maps? These can include generic functions that can slice and dice data structures regardless of what type of data those structures contain.
> Nice try Lennart.
Is Mr. Poettering's name now an epithet to be thrown at anyone who opposes the Holy Unix Way? Or do you just know something I don't about the identity of the commenter to whom you were replying?
lists: ls -1 | wc -l
maps: ps -ef | grep 'tobekilled' | grep -v grep | awk '{ print $2 }' | xargs kill
would unix be better if it were
cwd.files.count
and
processes.filter{name = 'tobekilled'}.map(kill)
?
maybe for the newbie who paradoxically already understands functional and object-oriented programming, I'll grant.
But the 'pipe' ("this is a bucket brigade") has always been pretty easy for people to grasp.
The Lennart bit was a joke. The OP's post was so histrionically overwrought that I responded sardonically. Apologies if you were offended.
>lists: ls -1 | wc -l
The computer has taken a real array (probably an array in C), joined all the items together into one big string using magical characters as dividers, and then split it again on those magic characters to try and reconstruct the metadata that it threw away. I think the problem is pretty obvious and well known.
>would unix be better if it were cwd.files.count
Well, at least that is going to give you the correct result. Correctness seems like it should be pretty important, no?
Are you really arguing for shells being easier to learn using an example of a complicated command with 4 pipes, 2 different quoted strings, several single letter arguments, and that requires implicit knowledge about the structure of the output from several commands? Compared to a much shorter, simpler, type safe, and self documenting bit of code?
Also, yes my original post was hyperbolic. That was because I was responding to a histrionically overwrought post claiming that unix is perfect.
Shell is easy to learn because people innately understand "and then do this with it". You can start with ls, get to ls -1, then think, I want to count these, and get to wc -l.
Yeah, there are exceptions -- e.g., files with newlines in their name -- and yeah, the interface could use some cleanup. But pedagogically, I can assure you that teaching people shell is easier than teaching them map-reduce.
My complaint wasn't about the efficiency of ls, it was the fact that valuable information that is required for correctness is thrown away to achieve compatibility with the unix 'stream of text' interface and the attempt to recover that information leads to incorrect results. The paradigm is just fundamentally broken.
>you would suggest replacing all of that with an object model that implements the equivalent of Ruby's enumerable. Got it.
I don't even like Ruby at all (ironically, I find its grammar far too complex and shell-like to be able to parse in my head), so I've no idea what you are talking about. You seem to be assuming that everybody who dislikes the shell must be some strawman hipster.
>there are exceptions -- e.g., files with newlines in their name
I honestly find it extremely bewildering that any programmer would see that as being acceptable. It's not just that it fails to give the correct result, it fails silently. Silent data corruption is surely just about the worse class of bug.
>But pedagogically, I can assure you that teaching people shell is easier than teaching them map-reduce.
I presume you mean the functional ideas of map, reduce, and filter, not MapReduce ( https://en.wikipedia.org/wiki/Map-reduce ). The latter is irrelevant to the discussion.
My experience is the exact opposite. I found understanding the concepts of map and filter trivial. If you can understand a loop you can understand them. Reduce/fold isn't hard to understand either, although a bit tricker to make use of. Your example didn't use reduce anyway. Map and filter are typically much easier to use and reason about than a for loop in C, or a chain of commands in a shell script.
The shell is an absolute nightmare to learn. I have tried to learn to use it numerous times of the last decade or so, and I have always forgotten it the next time I come to do anything in the shell. The amount of knowledge you need to actually do anything is huge (the awk language, obscure and terse command names, complex regexes, memorising a bunch of command flags, memorising the output format of commands - usually a format designed for displaying to users rather than machine parsing, the shells ridiculously complex grammar, how to escape things etc etc) Your example illustrates that. It would have taken me 20 mins at least to put together that line of code you gave. Also, it's not like you escape having to understand concepts like map and filter. If you don't understand them (not necessarily by name) then you won't be able to write the line of unix commands you gave.
>Shell is easy to learn because people innately understand "and then do this with it".
People might find the concept of piping data easy to understand (I'm not convinced they do to be honest), but that alone won't do them much good because as your examples showed, you always need to run a bunch of complex and obscurely named commands, regex, or awk on the data to make the next command able to understand it.
> I honestly find it extremely bewildering that any programmer would see that as being acceptable. It's not just that it fails to give the correct result, it fails silently. Silent data corruption is surely just about the worse class of bug.
Yes! We should strive to build our software on solid, non-leaky abstractions as much as possible, so that exceptions like a filename with an odd character in it just don't exist. Until we reach that point, computers will continue to frustrate their users for no good reason.
The devil is in the details. In OP's example, is "files" a field of "cwd," and "count" a field (or getter) of "files?" Is "filter" a method of "processes" and "map" a method of the resulting (implicit) list returned by "filter"?
If the answer to any of these is "yes," then you will find yourself needing to implement these fields and methods (and probably others) for each OS object. The "filter" in "processes" necessarily has a different implementation from "filter" in "files", since despite having the same external interface, they both operate in different contexts on different internal state (i.e. a process object is not a file object).
Contrast this with the UNIX approach, where the "filter" and "map" implementations (i.e. grep, awk, sed, tr) exist independent of OS-level objects (i.e. processes, files, semaphores, sockets, etc.) and their state, allowing them to be developed and improved independently of one another and the data they operate on.
You want there to be some notion of type safety and structure in IPC. This can already be achieved: simply rewrite your programs to communicate via asn.1, json, or protobufs, or some other common structured marshalling format. You can have ls send wc an array of strings, instead of having wc guess which bytes are strings by assuming that whitespace delimits them.
However, upon doing this, you will find that you will only be able to use wc with programs that speak wc's protocol. Now if you're lucky, you can convince everyone who wants to send data to wc to use the new protocol. If you're unlucky, you'll instead end up with a bunch of programs that only implement it partially or with bugs. If you're really unlucky, there will also be competing versions of the wc protocol. Moreover, what about programs that wc will need to pipe data to? wc will need to know how to communicate with all of them as well.
My point is, if we go the route of imposing structure and types on IPC, the only thing you'll have to show for it are O(N^2) IPC protocols for N programs, which they all must implement perfectly (!!) to get type safety. Want to write a new program? Now you also have to write O(N) additional IPC protocols so it can communicate with the others.
Maybe you can additionally mandate that each program speaks the same IPC protocol (i.e. there is One True Record for piping data in, and One True Record for piping data out). But, if this IPC protocol encompasses every possible use-case, how is it any different than a byte stream?
versus
> processes.filter{name = 'tobekilled'}.map(kill)
Yes, actually, I would like the second one better (although I know it's only pseudo-code). To me, the most egregious problem with the Unix way of doing this is exemplified by the "grep -v grep" part. The first grep command didn't specify precisely what you wanted, i.e. the subset of processes whose executable name (or argv[0]) is "tobekilled". It can't, because ps produces lines of text intended primarily to be displayed on a terminal and read by a human, and grep merely searches those lines of text for a substring. It's all a very lossy process. So you had to add a second grep to work around the fact that the first grep also matched a particular occurrence of "tobekilled" in a command-line argument other than argv[0]. But what if someone were running "vim tobekilled.txt" at the same time? These sorts of workarounds are to Unix as epicycles were to Ptolemaic astronomy -- evidence that the foundation is flawed.
> maybe for the newbie who paradoxically already understands functional and object-oriented programming, I'll grant.
I think it would be easier to teach the fundamentals of functional programming -- not the crazy academic type-theory stuff, but basics like map and filter -- than all the intricacies and gotchas of combining Unix tools like grep, sed, cut, xargs, awk, and so on. You do realize that, in addition to the shell language itself, you casually dropped in a whole second language (Awk) in your second example, right?
> The Lennart bit was a joke. The OP's post was so histrionically overwrought that I responded sardonically. Apologies if you were offended.
It bothers me that you used Lennart's name as a synonym for "anti-Unix", as if that's his most salient characteristic (if it's even true of Lennart). How do you think he would feel about that "joke" if he read it? Especially on top of all the other vitriol he's received?
Can we do better? Sure! One could imagine a reformation of the unix philosophy to center around strongly typed streams that could totally work after you put about 20 years of effort into replacing the existing tools. All too often, though, the reformers are people who don't understand the philosophy and want to try a weird collection of ad-hockery instead.
How about
file:. count
?(ls).Count
(where ls is an alias for http://ss64.com/ps/get-childitem.html which returns .net FileInfo objects, it can also return info for registry paths)
and
ps | ?{ $_.Name -eq 'tobekilled' } | %{ $_.Kill() }
(ps an alias for http://ss64.com/ps/get-process.html returns .net Process objects)
or the equivalent of pkill
Stop-Process -Name 'tobekilled'
What alternative do you advocate/propose ?
Genuinely curious ...
It seems to me that a lot of shell scripts could be ported to other languages. Does DHCP on Linux need to use a shell script instead of python or something like that? The benefits of the shell grammar and semantics which are designed to make interactive use easy seem more like hindrances in a lot of those kinds of use cases. I assume it's largely done to make it easier for sysadmins to customise things. If I was a sysadmin I'd much rather learn python (and feel like I actually understood it) than the crazy byzantine grammar of bash. Maybe that's why I'm not a sysadmin.
This paper by Rob Pike might also be of interest: http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf
>The current UNIX® text processing tools are weakened by the built-in concept of a line.
Command line interfaces are extremely powerful, simple to implement, extend and leverage, but, GUI's have their own advantages mainly in information density, context clues, and ease of operation. There is a world for them to both live in, but I would disagree with OP's approach of bring graphics to command line and suggest the approach of bringing command lines to GUIs.
I have already embedded a command line terminal in several GUI's I've built for industrial machines. The users can see the corresponding command line command pop up in the terminal when they click a GUI button and are free to type commands into the terminal. They can also define a script or batch of commands and easily assign it to a GUI button.
It was amazingly efficient for engineers to work with prototype machines whose functionality and controls were constantly in flux.
Downsides are that exposing a terminal to a potentially non-expert operator is a potentially dangerous, and I had to spend a good deal of time validating and sanitizing inputs(and risk missing something).
In the end, the terminal was removed in the production GUI, but was extremely helpful in the creation of a functional GUI that worked for the operator, rather than the opposite. In the case where the operator is always going to be an expert and is working with a complicated or constantly changing process, I could see a CLI/GUI interface working well.
HTML+JS seem like the obvious way to do it - even though the web is an awful platform, its standard, cross-platform and fully featured. Its the perfect worse-is-better solution for this.
I think the hardest part would be figuring out how to reconcile browser-like UI events and file streams. Maybe you'd need to make a standardized event serialization format so your process could receive serialized events via stdin or something like that. I think it'll be a really hard sell if we have to abandon our unix pipes entirely.
[1] https://github.com/unconed/TermKit
Previous hackernews discussion around termkit: https://news.ycombinator.com/item?id=2559734
How about Chrome Apps? They've got a mix of file I/O capability and HTML/JS.
It provides
- A shell for the web. Runs in the browser, pure client-side.
- File-like abstraction for URLs and other entities exposed by web APIs
- Unix-like style of composing commands using pipes.
- Visualization using HTML
For instance, cp -r /gdrive/<username> /home will backup the contents of your Google Drive to your desktop (see http://pigshell.com/v/0.6.2/doc/gdrive.html for details). Replace /home with /dropbox/<username>, and the same command will back up GDrive to Dropbox. And so on.
While it is already useful, there is still some work, especially around hardening the file abstraction/APIs (and reams of documentation) before before it can be horizontally expanded to support a bunch more APIs and cloud stores. I am actively working on these and expect they'll take ~2 months.
Seriously though: the file is a powerful and familiar abstraction. The primary motivation for pigshell was to provide a common minimum abstraction across different web APIs which would enable basic data movement and backup.
That said, pigshell commands actually pass objects across the pipeline; files are a kind of object. For instance,
cat http://pigshell.com/sample/life-expectancy.html | table2js -e "tr" foo country data | head | printf
The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.
I'm often thinking about how to present/"unify" these:
- command (statements validated by some token),
- repl (expression, less side-effect driven than the previous one),
- unary/immediate mode (each input event is interpretable right away, direct mapping between input and action),
- n-ary/non-immediate mode (some parsing occurs, gathering a few tokens into a higher level construct)
- non keyboard based UI/UX (some sofware like Maya have proper separation, most mouse events have direct translation into object methods)Any theories, anyone? I'm really curious. Still believe this can be improved, and work on some ideas in my free time, but I often wonder why I have to, and I can't already use those beautiful ancient features?
Since I discovered UNIX, with Xenix in 1994 followed by many other variants, I always looked for ways to replicate such workflows in UNIX.
At the end of the day, Mac OS X and Windows communities are more welcoming to such ways of working.
edit: the comment by zorbo seems an interesting answer to my question, but I'm still not 100% convinced; also, I must still ask how can we be sure we're not victims of a text-mode "Stockholm Syndrome" in this regard?
So they look around and see only UNIX CLI.
It is just like mankind during the middle ages that never experienced how the Roman and Greek society were developed before the empire downfall.
Just because it's old, doesn't mean it's only about nostalgia.
Besides, I for one can't have this kind of nostalgia because in the '70, my fingers were a bit too short.
There is something extremely convenient to be able to use the same environment everywhere, with minimum prerequisites, because terminal emulation software is very common (probably as common as Web browsers).
I also find it more natural to deal with the system with a CLI when you spend your time editing source code or doing sysadmin stuff; it doesn't break the flow. Of course it's totally different if you're a graphic artist or a Web developer.
Sometimes CLI makes more sense, sometimes GUI makes more sense. But accusing people of being stuck in the past, that makes no sense.
UNIX shells can only seem powerful for those that never had the luxury of playing with Smalltalk, Lisp, Mesa/Cedar or Oberon environments.
Where you have a CLI and GUI experiences interact together to create a composable workflow experience.
Where I can do function composition on my REPL over data that I just selected with my mouse on a word processor, just to give a possible example.
Where public functions from dynamic modules are exposed on the REPL and can take part in any set of commands.
There is this primitive notion that a CLI needs to be the UNIX way, when a REPL as CLI is so much more powerful.
By "tab" you mean tab in your web browser; do you not? (I ask because there are non-web-based IPython thingies.)
I'd guess that the technical decisions that differentiated early unix from the lisp machines etc. were based on hardware and cost limitations.(the development of unix is something I'd be interested in reading more about) Then as unix took off, these technologies became entrenched, with a kind of apologetics developing amongst users who liked those systems, or never used anything else.
There's an interview with Bill Joy where he said that Vi's famous modal interface was merely a result of his poor quality terminal and network connection, and now it's used by millions of programmers. I'm not saying that these users are wrong about the benefits of modal editing or the unix text interface etc, but that these are discovered benefits that are then used to retroactively construct a containing narrative of justification that often walls people off from alternatives.
I'd also hazard a guess that many of these technologies were simply inaccessible and/or unknown to the mass of post-pc-revolution developers who create the bulk of our present systems. The number of devs who had access to Lisp machines was small compared to the number who came in with Unix with its success in the workstation market, and tiny compared to the number of devs who came in through home computers/PCs.
I myself grew up with 80s home computers, moving to the PC and Linux in the late 90's. Lisp machines, Oberon etc. were unknown to me until a few years ago, and information about them is still hard to come by. Nearly all the lisp machine sites are web 1.0 with broken links etc. Very few of them try to market the benefits of these systems to people in the wider community.
After I got interested in lisp and lisp machines (thanks pg!) I spent a weekend getting that notorious leaked Symbolics Genera distribution working on Linux, inside virtual box on my mac. After a few hours in the Listener, with its rich output and superior incremental help system I wanted to show it to everybody I knew. It was one of the most incredible things I had ever seen on a computer. For the next few weeks at work I was occupied with the constant thought, "This is not as good as Genera". It's had a huge impact on how I think about software, even my indie game development.
https://en.wikipedia.org/wiki/Unix
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html
http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj...
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://www.levenez.com/unix/ has a good amount of info and links on the history of Unix and the people who worked on it. I came across the site a while ago and browsed it some. Interesting stuff, some of it at least. Recursively traversing the links should give even more.
In fact, I started hearing of all of those OSes fairly recently too, but I still see myself as a "youngster" in programming world, and thus I thought those technologies were more well known at that time. Also, that they were more well known to Important Figures and Big Companies then, so they could try to build on those ideas.
But now I start to recall, that most of those OSes are usually reported to be used and deployed quite rarely (Lisp Machines e.g. often dismissed because of high price and hardware requirements), so that could have limited their exposure. And also, I'm ashamed to admit I forgot about this (oh the times!), it must be taken into account that there was no Internet at the time, so this also made sharing of ideas harder than now...
There is also no command history for my gui clicks; once you've clicked on something, there's no way to reuse that click in some slightly different way.
Some R (programming language) GUI frontend does it in this way.
It would be kind of cool to have gui interfaces (including the general desktop gui) have something like this dual mode.
And: applications that have Macro recorder features (Office and many text editors) allow you to actually record your actions - clicks or otherwise - into code that can be rerun.
Why have macros and history reimplemented badly by every application when one application could do it well?
That doesnt take away from the point, however, that GUI actions can be stored in history, composed, etc.
So, when outputting a number, you could display it in the output stream as a circle of radius N. Then, any input which wanted a number as argument (using "(accept 'integer ..)") would let you type a number or click on that circle.
This could be extended to shell command parser for richer input choices (rmdir can only accept directories, cat won't). Existing utilities could support a "richly typed stream of objects" (graphical ls) or a wrapper or output processor could add it. The latter has the advantage that not all commands would need to be aware, and it could be multi-functional (could work on "ls|grep", "find", "tar tf" output--but you might need to specify type hints).
I think it would be handy to have all my recent files, directories, outputs handy in a list on the side (with keyboard shortcuts too; I'm not a clicker..).
So in no way should your command history have to be compromised just because you have alternative input methods available.
[1] A Guided Tour of the Common Lisp Interface Manager, http://3e8.org/pub/scheme/doc/lisp-pointers/v4i1/p17-rao.pdf
That said, that's a great topic to cover! I think GCLI does a pretty good job of command completion. The Lisp Machine did as well. I have friends who love some of the router CLIs, but not sure which one(s).
https://www.youtube.com/watch?v=o4-YnLpLgtk
the AI winter is something you don't hear too much about. http://en.wikipedia.org/wiki/AI_winter
After all, the core functionality of the application remains the same. To use a simple example: when you search for a product online, get a search result list and then select one from the list, couldnt this flow be modeled just the same in both gui and text interfaces?
I'm thinking back to the turbo-pascal style applications of the past that produced full-blown IDEs in text, or the wordstars/wordperfects of yore: the UI model that sits behind those apps cannot be much different in principle from the modern day equivalents.
Even farther back, there was a time (and probably still is for college assignments) when cli applications had a prompt-read user input-respond cycle, replete with text-based choices to select from and so forth.
What if we were to merge the two worlds instead of trying to get one to confirm to the other?
It is a shell, isn't it?