This is cool, didn't know there was another shell for plan 9 besides rc.
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's the advantage of doing everything in the same process? Your article said this is nicer but I don't see what the advantages are and there are some disadvantages I listed (ABI issues, security).
Well, spawn() and pctl() are actually more like a finer-grained fork(), without the necessity of, for example, O_CLOEXEC, or anything in fcntl. Between pctl() and Limbo's channels (on which Go's are patterned), a lot of what is required for security in "vanilla" Unix is unnecessary.
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.
all inferno modules are written in limbo, which has a safe memory model, so modules can't access data they're not given.
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 Inferno run Go efficiently, you'd probably need to add instructions to the Dis VM to do interfaces, channel closing, slice capacities and likely other things I haven't thought of.
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.
To be honest this isn't the sort of introduction I want to a new shell. What I want to see is
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.
I'm planning a couple of more articles on this topic, so your point is of interest to me. Since it's all content I have absorbed by using the shell, some things that seem obvious to me might have slipped through the cracks when I wrote the post. It seems from your comment like #1 was answered (how it differs from existing shells). The problems with existing shells (byzantine quoting rules, general opacity in terms of being able to use them from the outside, and crufty, non-uniform syntax, lack of simple FD manipulation, lack of modern facilities like blocks, scoping, etc.) were sort of taken as a given, and the examples should have shown how they are obviated. What is it you'd like to see explained?
Looking more closely I think I was less turned away by the content (which is there) than the progression of the tutorial. I started out scared by the "no conditionals, no loop constructs, no functions, no aliases" - What I really needed was something confidence-building, like
; for i in `{ns} {echo $i | sed 's/.* //'} | sort | uniq
It looks familiar, and you can mostly puzzle it out without having to know a lot. More to the point, it looks like something you'd do every day. It's also a nice introduction to the `for` construct and it introduces a quoting syntax. "Just enough rope to hang yourself." No doubt we wouldn't guess that those braces are for lambdas, but that's easy enough to correct. Perhaps my complaint says more about me than you - I'm more than happy to `load std` before I even know what a module is, because all I really want to do is process some text. Similarly, I can appreciate conceptual cleanness in a language, but in a shell especially it's an ancillary benefit.
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.)
"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?"
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?
Inferno seems to do fine on BSD, OSX, Windows. It had a little trouble coping with CLang but a makefile tweak to make it use gcc fixes it.
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 just ran across No Execute on your blog. I can't believe I never found that before (I've chased up all the Plan 9 stuff before).
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.
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?