I like the idea of the shell being an HolyC interpreter. Do we have some analogs with the mainstream languages - I know I could fire up, say, the Python REPL and use it as my shell but that wouldn't be convenient to manipulate files.
It'd be interesting to think about this from the inside out rather than the outside in as is normally done.
So imagine if you wanted to fire up a Python REPL and use it as your shell. What the shell essentially does is treat bare words as external command/executable invocations. Every dynamic language treats bare words as internal function/method invocations. That would mean that any executable looked up in $PATH (a global variable that holds a list of directories) would supersede any internal method in that scope! Is this workable? Why not try it and see? Also if you created a Shell library for Python (in C ;-)) then it could be used by Ruby and Perl and Node (or whatever they're calling it nowadays) and ...
It is interesting to imagine not having to context switch to shell-speak to interact with your machine. If you are a Pythonista just speak Python, a Rubyist the same ...
The article proves your point, even Linux with its openness is still very much tied to years of tradition.
And what if the shell output wasn't line-oriented but a live hypertext doc, say HTML5?
I was about to suggest you could do this easily in Ruby, but it turns out that getting a catch-all method_missing at the top level to work is quite annoying - too many things in both Irb and Pry (the two main Ruby REPLs) seem to rely on trying method calls and catching the exceptions in ways that broke horribly with my most naive attempts.
But something like this works of-sorts in Ruby:
module Sh
def method_missing sym, *args
bin = ENV["PATH"].split(":").collect do |path|
full = File.join(path,sym.to_s)
File.exists?(full) ? full : nil
end.compact[0] rescue nil
if !bin
raise NameError.new(sym.to_s)
else
bin = system(bin,*args.collect{|a| a.to_s})
end
end
end
self.extend Sh
Pry can't handle it very well, probably as it relies extensively on method_missing "magic" itself, but Irb seems do do fine with it.
I'm sure there are ways to do the above in much cleaner ways, and even in Ruby syntax still gets in the way. E.g. you need to do 'ps :aux' or 'ps "aux"' instead of "ps aux" or the options will get interpreted as a method (though you could conceivably try to handle that by capturing NameError exceptions and applying really horribly nasty hacks, there would be a special place in hell for you if you were to do that; even the above is likely to break all kinds of stuff).
> And what if the shell output wasn't line-oriented but a live hypertext doc, say HTML5?
There have been all kinds of attempts at that, notably XmlTerm from Mozilla ca. 2000 [1]. It turns out to be a hard problem to get it right enough to make people use it. Basically to get that working at all I suspect you need to start with a good terminal emulator + a good shell, and make small enhancements rather than go the other way which most of these kind of projects have done.
And while that page doesn't really highlight it, it works pretty well out of the box:
% ipython
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
Type "copyright", "credits" or "license" for more information.
IPython 2.3.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: pwd
Out[1]: u'/private/tmp'
In [2]: ls
KSOutOfProcessFetcher.0.r55jifrBu08ZlGAfPLYXKgYad4c=/ lein-trampoline-M8eCP9ASjLYqO
KSOutOfProcessFetcher.501.r55jifrBu08ZlGAfPLYXKgYad4c=/ lein-trampoline-i3aRyHVGcm1Fr
com.apple.launchd.QiAYKXJLr7/ snow-nic1.pcap
com.apple.launchd.iNBrDiEeE8/ snow-nic2.pcap
com.apple.launchd.z0Zss1uMx6/
In [3]:
I think that's something every programmer dreams of sooner or later. It seems like anything I've worked on that's larger than a utility script eventually results in fudging around with multiple tools trying to get them to cooperate.
And every time, I'm like "I've got some fing code and they've given me some fing code and all I want is for them to run together."
Powershell can call code in .Net assemblies and I imagine there's a way to pass C# or some other .Net code in but it probably requires a fat command.
The true beauty here, I think isn't just the way the Command Line acts as an interpreter but that all the code on the system is exposed at all times through a simple, common interface.
Right? Imagine if you wanted to, I dunno, render HTML in a window in your application for some reason, and you could just easily pull up the running copy of Firefox on your system and call one of its functions, in real time, in your application. Done, now you've got an HTML renderer in your software.
You can actually do that in most modern GUI toolkits. It's usually called something like a WebView widget. See also the Chromium Embedding Framework. None of these talk to a separate running browser, to be fair.
I think even in HolyC you'll be fully quoting all paths. With general purpose languages, they're going to need either a recognised-shorthand-expanding preprocessor, or unfettered "reader" macros to be able approach Bourne shell style unadorned text that does process and file wrangling.
I actually pitched that idea to Rob Pike regarding a future for Go. I think that having an environment shell like that, baked into ChromeOS, would both promote the OS and the language. He didn't seem all that impressed, but TempleOS is very close to what I had in mind.
For a while I was running Perl as my shell, it bakes in most common unix commands as top level functions and its easy to call ones that aren't built in using system calls. Perl is pretty nice for file manipulations out of the box if you know what you are doing.
The C shell does not come close. It's just a shell with a C-ish syntax. Fundamentally different than having a C compiler (or interpreter) as your shell
