The Inferno Shell, an Introduction with Examples

http://debu.gs/entries/inferno-part-1-shell

by 1337p337 • 14 years ago

61 19 14 years ago

f45s8g23• 14 years ago

Question for the author:

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?

1337p3377• 14 years ago

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.

f45s8g23• 14 years ago

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.

andrewflnr• 14 years ago

Inferno is supposed to run on just about anything, from bare metal to Windows, IIRC.

doublec• 14 years ago

Inferno has even been ported to run on phones: http://www.android-dev.ro/2011/09/17/hellaphone-inferno-os-f...

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

chubot2• 14 years ago

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?

1337p3377• 14 years ago

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.

chubot2• 14 years ago

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).

rogpeppe2• 14 years ago

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.

1337p3377• 14 years ago

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

repsilat2• 14 years ago

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.

1337p3377• 14 years ago

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?

repsilat2• 14 years ago

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.)

rogpeppe2• 14 years ago

"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?"

absolutely. that was rc's main innovation IMO.

The Inferno Shell, an Introduction with Examples

Related Stories