-----BEGIN PGP SIGNED MESSAGE-----
firstname.lastname@example.org (Paul Wilson) writes:
> My understanding is that Scsh process control is based on UNIX-style
> fork(), which may be problematic for non-UNIX OS's
Well, yes, that's true, but to quote from the introduction
to the manual:
This is a draft manual for scsh, a Unix shell that
is embedded within Scheme.
and the reference paper is a really good rant about
everything wrong with UNIX, replete with many arguments
about why it would be much nicer if it had a good
The general systems architechture of Unix is
cooperating computational agents that are realized as
processes running in separate, protected address spaces,
communicating via byte streams. The point of a
shell language is to act as the glue to connect up these
computational agents. That is the goal of scsh.
... Perhaps cooperating lightweight threads
communicating through shared memory is a better
way to live, but it is not Unix. The goal here
was not to come up with a better systems architechture,
but simply to provide a better way to drive Unix.
I think that this pretty much says "fork you". :-)
> I'd think that spawn could be more portable than fork.
> Comments welcome.
While I would agree very quickly that there are some
deficiencies in scsh (it's _big_ comes to mind), and that
there are some obvious possible improvements, I think
firstly that scsh is currently incredibly useful and
secondly that it would not be substantially more useful if
Olin Shivers dropped some functionality and UNIXiness in
order to get it running on more platforms as a full- blown
It may be that that kind of full-blown, portable
development environment would ultimately be more useful
to many people for many things, but "it's not UNIX".
I'd rather have Olin and company spend their cycles making
scsh more UNIXy (read that as: smaller, cheaper startup :) [*])
than on making it more portable, although that would mean
that some things on my wishlist would have to be done by
another tool altogether.
Of course, that's very UNIXy: one tool does not do
everything, which is why UNIX has lots of tools.
Mind you, looking at 4.4BSD's cat(1) manpage and
remembering that I'm occasionally spotted (and even admit
to) running emacs to read email and news, maybe I'm being
a bit hypocritcal. :-)
[*] : chops.icp.net ; ps l
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
3005 1581 396 1 10 0 836 176 wait S+ p0 0:17.38 /bin/rc -i
3005 22259 1581 0 2 0 18532 464 select S p0 8:43.94 emacs
3005 23524 1581 19 10 0 16568 340 wait S p0 0:01.49 scsh -o /usr/l
3005 23525 23524 1 10 0 416 124 wait S p0 0:00.10 sh
3005 23526 23525 3 18 0 404 180 pause S p0 0:00.16 -sh (csh)
3005 23527 23526 6 10 0 184 236 wait S+ p0 0:00.11 rc
What is wrong with this picture?
(For extra points, spot the two processes which have
actually been used to run more than one child process :) )
(For extra extra points, name the author(s) of each of the
shells, and list his, her or their crimes against humanity. :) )
-----BEGIN PGP SIGNATURE-----
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey
-----END PGP SIGNATURE-----