Article View: comp.sys.amiga.tech
Article #13101Re: What should be in future SKsh versions?
From: Steve Koren
Date: Mon, 11 Dec 1989 15:38
Date: Mon, 11 Dec 1989 15:38
50 lines
2918 bytes
2918 bytes
> > I like this idea, though I think the best route is to supply two binaries,
> > one with the builtins and one without. Hard drive users tell me "get rid of
> > the builtins" and floppy users tell me "add more builtins". I don't think
...
> Why exactly do you need builtins at all, even on a floppy disk, given the
^^^^^^
> existance of REZ? [Which has the large advantage of letting the USER decide
Well, there are a few reasons:
1) First of all, if you REZ (or resident) everything, you will consume
*much* more space than by building it into the shell. For example,
the 'basename' command probably consumes but 80 or so bytes (just a guess),
but in compiled C it would probably be 4 or 5 K (again, a guess). If you
add this up over the course of all the builtins, you get a huge amount of
stuff resident. You can partially solve this by only making resident
a few of the builtins, but if the whole shell is made resident, you only
pay this price once anyhow.
2) As Kim points out, AmigaDos limits external command lines to a very
small length (something like 256 chars). This causes a problem for
things like 'externcmd *', where '*' matches a large number of files (or
a few files with long names). I run into this all the time with things
like 'zoo -add foo.zoo *'.
3) People are asking me for it.
4) Some builtins (such as 'exit') cannot easily be provided as an external
command. I haven't yet identified exactly which ones can be yanked, but
I think that there will be a core set in there anyhow. As another example,
some commands are provided as a 'keyword', and they have to be. Consider:
time { dir; sleep 3; my_cmd }
It would not be possible to make 'time' an external command in this case,
since it can time *any* complex command, not just a single external
binary. It has to be part of the syntax.
5) Not all external commands are pure. Granted, REZ fixes this, but
I'd like to avoid depending on another freeware program that might up
and go away at any time.
FYI, some future release of SKsh (past 1.3) will provide a shell with
only the necessary builtins (like 'exit' and 'set'). I still feel that
two versions (minSksh and maxSksh) would be the best route, since there
are a large number of people who want both types. (What's that saying
about pleasing all the people some of the time, or some of the people
all the time... :-)
- steve
Technical Details
Message-ID:
<13920030@hpfelg.HP.COM>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpfcso!hpfelg!korenReferences:
<13920018@hpfelg.HP.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpfcso!hpfelg!koren From: koren@hpfelg.HP.COM (Steve Koren) Newsgroups: comp.sys.amiga.tech Subject: Re: What should be in future SKsh versions? Message-ID: <13920030@hpfelg.HP.COM> Date: 11 Dec 89 15:38:57 GMT References: <13920018@hpfelg.HP.COM> Organization: HP Elec. Design Div. -FtCollins Lines: 50