The Inferno Shell, an Introduction with Examples
debu.gs
debu.gs
Are inferno dynamically loadable modules just like loading .so's in Unix? Is there a standard ABI/C interface for them so every module doesn't have to be compiled against specific shell headesr?
"Where in most Unix systems exec()ing sh -c is somewhat popular, in Inferno, it’s unnecessary. You just load the sh(2) module into your Limbo program and run programs, parse commands, glob patterns, etc., as much as you like."
How does security work in this model? If I shell out to "gzip" then I know it's only going to have access to the data I sent it via pipe. It sounds like if you're loading other code into your process it can do weird things to calling program, depending on what the interface is.
I've looked at the es shell cited at the end of the 'sh' doc, the rc shell -- any more in this family?
A command loaded into your process can do things to you if you run it directly without calling spawn() or pctl(), but you'll usually use those to seperate the process, although it's rare to do it that way.
As far as other shells in the family, mash influenced Inferno's sh, but I think it's a relatively sparse branch compared to bourne-compatible shells.
What I was trying to convey in the article (sorry if it was a bit vague) was that using functions available to the shell was the nice part, the actual advantage over regular Unix. That is to say, if a user passes '*[0-9]?.gz', you can call functions within the shell to handle the glob rather than having to implement them yourself, for example. The shell is also designed as a library, in other words. This includes things such as parsing sh's syntax, even.
check out some of the inferno papers, and the limbo language in particular, which is an elegant predecessor of Go, including some things that Go still does not have - the dynamic module loading being the most marked example, and the main reason i haven't yet ported the inferno shell to Go.
To make Go run well under Inferno, you'd need to change the language to allow dynamically loaded modules (can we use the type compatibility model when we can't link everything together at once?).
These issues are doable, but even if you've done that, the performance trade-offs when writing a program to run in a VM are quite different from running natively - in particular, much idiomatic Go code would probably be dog slow under Inferno, because we're not steaming along at native code rates.
All that assumes we'd translate Go to Dis though. There may be alternative routes.
1. How it differs from existing shells I'm familiar with, and
2. How those differences solve problems with existing shells.
This article says that the shell uses lists rather than strings for some things. Great, does that mean this shell deals with spaces and newlines in filenames better than bash?
This article shows off the new language by pointing out how exotic it is, how different the shell is to everything you know and hold dear. Maybe it should be embarrassing to admit this, but that's a little scary. I'm reading because it's interesting, but this isn't an article that will people to go out and use it to solve their problems.
And at the end of the day, that's what a shell is for - they're the way you interact with your computer. They can be clever if cleverness is appropriate, but first and foremost they should enable us to use our tools effectively and if possible intuitively.
; for i in `{ns} {echo $i | sed 's/.* //'} | sort | uniq
The short digression on escaping and quoting (`fourspaces` and all that) at the end of the "Fetching Web Pages" is lovely. Really, that's exactly what I was after - "This is Bash and it's annoying, this is Inferno and it just works right." It's succinct and it clearly shows that Inferno does better than the alternative (and when you're convincing someone to use your shell the argument is as much about Bourne and Bash as it is about your option.)
absolutely. that was rc's main innovation IMO.
Your blog says you have an EeePC and run Plan 9. So does Plan 9 run on the Eee? If yes, which Eee model do you have? As for the article, it's been a while since I looked at Inferno. Thanks for redirecting attention to it again. It seems like it would make a great mobile OS.
I am going to try running Inferno on an EeePC. Will it only run on Linux? How about BSD?
If you want to try runnong Plan 9 on an EeePC, 9atom is tuned for that. I have one of the older ones (701 is the model, I think) and it does boot Plan 9.
I've also been an Atlast user for a few years. Can't believe I never heard about your fork of it. John Walker's writeup on Atlast should be required reading for all programmers.
I'm going to try 9atom. I have a newer Eee with no CD drive. With BSD I can convert iso to img, add boot code and be up and running quick. But I guess it won't be so simple with 9atom? If this works, I'll be very happy.
I couldn't agree more about the Atlast writeup. I'm glad for the vast proliferation of Lua, if for no other reason than it has made scriptability a library. I can certainly believe you've never heard of my fork. I actually feel bad because it's still "in beta", being a work in progress. I've been meaning to send a patch to Mr. Walker for the 64-bit issues, but there's always another bug or feature in the way, and I've held off on a "real" (tarballs on a server, documentation) release until I ping him and fix some bugs.
Regarding 9atom, I don't recall any difficulties booting from USB, but it was a while back, and I didn't quite get it installed. I've been running 9front for the most part when I run Plan 9.
Thanks again for redirecting our attention toward some quality stuff.
I'm psyched to get some version of Plan9 running on a netbook. Plan9 is work of art.
Similar to Mozilla's B2G in approach, it uses Android's basic Linux system and builds on that. Source here: https://bitbucket.org/floren/inferno