
The Inferno Shell, an Introduction with Examples - 1337p337
http://debu.gs/entries/inferno-part-1-shell
======
chubot
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?

~~~
1337p337
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.

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

~~~
1337p337
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.

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

~~~
1337p337
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?

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

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

~~~
1337p337
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.

~~~
f45s8g2
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.

~~~
1337p337
No Execute is one of my favorite (semi-) blogs!

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.

~~~
f45s8g2
I'm reading through No Execute now and it's fantastic so far.

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.

~~~
1337p337
Your profile is fairly sparse; I wonder if you'd mind emailing me; there are a
couple of things I wanted to chat about. (Address is on my site.)

