Hacker News Reader

Comment by chubot | Hacker News Reader

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?

View on HN

Plan 9 does have a POSIX-like shell, psh.

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.

I'd rather see Go ported to Inferno. :)

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.

Reply on news.ycombinator.com