I wholly agree that splattering chrome over a terminal isn't the best way forward. Emacs shell mode gets me all?most? of the way to the interface posed as the solution (text editor as interface to terminal). Being emacs, I am sure I could finish up the proposed solution with "a few lines of elisp".
And I don't think it's the solution. These issues are spawned deeper in the design. Multiple streams of information are being spawned, and must be handled sanely: pipe redirection starts breaking down here because it's a line - what's needed is a graph of management that's able to handle different cases and join back for the next approach.
One approach might simply be to develop a higher-powered programming language environment that calls directly into the system.
Windows Powershell attempts to do what you're describing. PowerShell doesn't manipulate text streams, it manipulates .Net CLR objects. That allows shell programs to expose data in a much more meaningful way. You don't have to have a parser in every program that interacts with the shell when you can send and receive typed data.
I haven't worked much with it lately, but I wouldn't be surprised if Powershell was the closest existing technology to what the author is thinking of.
I think he agrees, except for the textual display.
From the article:
Data structure. Windows PowerShell had a chance to
redesign the terminal from scratch, but defaulted to
the same old grid of ASCII. One innovative thing they did
do was add structure to their data, piping .NET objects
instead of raw text, allowing the user to select fields by
name instead of writing elaborate AWK scripts. The shell
for the research OS Famke does a similar thing for
higher-order functions
I didn't quite get where the author was going with that. Windows Powershell has access to the full Windows .Net API. If you want to spawn a window to display graphics or what have you, you're free to do so.
You can already side-chain data flows with file descriptors. You can solve more complex problems with temp files and tee. I can't really imagine that making me use a GUI to select where to pipe what would be more efficient. Most of the time, when people have problems that require complex data manipulation like this, they'll jut use their favorite scripting language.
There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great.
"Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great."
No, they don't. Really. Look at the source code to ncurses and see if the millisecond timing loop around select() is still there, to distinguish between a terminal sending ESC[1D in response to you pressing "left cursor" and a human pressing "ESC" "[" "1" "D" very quickly :-)
It sucks. Windows got this right a long time ago, to the extent that the left & right modifier keys are distinguishable. Try doing that on a VT100.
Of course, a REAL VT100 doesn't have half the keys ; F1-F4 (IIRC) aren't sent "over the wire" and have no standard encoding. Linus basically invented one for the "linux" console terminal type, and lo yet another "standard" was born.
And don't talk to me about shells. The lunacy that is never quite knowing what insane metaquoting scheme you'll need today based on which arcane shell some moron has configured as the default for THIS particular machine is EXACTLY what the top-voted Koan is about.
> There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Emacs shell mode was my first thought too. It doesn't try to implement a new standard for pipes, though. The idea of using invisible control characters as metadata is interesting.
(My biggest complain about shell mode is that it's impossible to send certain characters to the underlying process, TAB being the most important one, so you can't rely on built-in tab completion behavior.)
And I don't think it's the solution. These issues are spawned deeper in the design. Multiple streams of information are being spawned, and must be handled sanely: pipe redirection starts breaking down here because it's a line - what's needed is a graph of management that's able to handle different cases and join back for the next approach.
One approach might simply be to develop a higher-powered programming language environment that calls directly into the system.