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]:
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?