🚀 go-pugleaf

Okay, you asked for it...

I said:

Deven> I exit an instance of SKsh, it usually frees about 120-150K of
Deven> memory, and that's with the 70K executable RESIDENT.  I don't
Deven> consider such excessive use of resources to be justified, so I
Deven> have switched back to [AShell...]

On 5 Mar 90 23:15:41 GMT, koren@hpfelg.HP.COM (Steve Koren) said:

Steve> That is bigger than the number I get.  On my system, the
Steve> overhead of an additional SKsh is 48944 bytes if I load only
Steve> the .skshrc file (most of that memory is taken up by hash
Steve> tables and whatnot).  Even when I load my .skshinit file (which
Steve> is big) and the entire Stuff.sksh file, the overhead is still
Steve> only 60952 bytes.  Sure you're not measuring the overhead of
Steve> the addition window?

Yes, I am counting the window, but that's not the point.  50-60K+
overhead for a single shell invocation is utterly insane.  Yes, it's
more functional, but that is simply TOO MUCH overhead.

Steve> That alone consumes some memory, but it would anyway.  You're
Steve> absolutely right, though. SKsh is not for 512K systems.

This was on a 1 Meg system.  I might find the overhead acceptable for
a system with 3 Meg or more, but NOT for 1 Meg or less.

Steve> I can't really make the executable much smaller - for what it
Steve> does, its not bad.  It has comparible functionality to the Un*x
Steve> version, which, depending on your Un*x, is usually over twice
Steve> as big.  I will eventually release a tiny_sksh which has
Steve> reduced memory requirements.

Don't bother comparing to Unix.  Yes, it's smaller than a Unix
version.  No, it doesn't give me reason to use it.  Bear in mind that
the Amiga is NOT a Unix system, and when you use the calls for Unix
compatibility which the compiler provides, you're adding a LOT of
unnecessary overhead, because all that code gets linked into the
executable.  Also, if you're using lex and yacc or equivalents, then
you're adding a lot of overhead for the parser as well.  (but it is a
more reliable parser that way, I'm sure.)

Deven> There are several other major reasons I stopped using SKsh --
Deven> it is EXTREMELY slow, and it also takes a LOT of memory, and it
Deven> doesn't give useful error messages -- only cryptic numbers.
Deven> Granted, I haven't tried SKsh 1.3, but it seems unlike that it
Deven> improves on the stack, memory and speed problems.

Steve> You sure you're using SKsh?  It does tell you more than the
Steve> "cryptic number":

Steve>    blah: can't change to directory (8)

Steve> compare that to "Can't find blah" for the AmigaDos command or
Steve> "Object Not Found blah" in the Dillon shell.  They all seem
Steve> about the same to me.

Yes, I'm sure I'm using SKsh.  A more pertinent example:

more <file>
more: unable to execute program (24)

Great.  Real useful.  The important part is a cryptic number.  In both
cases, SKsh tells me THAT it can't do what I asked.  In neither
example did it let on WHY.  I'm forced to guess.  That more example
was for when more was resident with ARP's ARes.  But SKsh ignores the
resident list.  (1.2 SKsh)  Another reason I stopped using it.

Steve> If you want more error messages, or different wording, send me
Steve> mail with specific suggestions.  It is all open to change.  I
Steve> have been toying with the idea of loading all messages from a
Steve> disk file so they could be customized as you wish.

I want to know WHY a command failed.  If you MUST use a magic number
instead of a text message, then use the AmigaDOS error numbers!  At
LEAST then I can look it up, or possibly recognize it.  Instead you
are using some magic number which isn't even documented.  I don't find
that acceptable behavior for so basic a tool as the shell.

Steve> What is too slow?  If you mean the external commands (wc, etc),
Steve> they are getting much (5 to 10 x ) faster in 1.4.  The script
Steve> language is much slower than a compiler, of course, but again
Steve> it doesn't do too bad when compared with Un*x on a much faster
Steve> processor.  Interactively, it seems about as fast to me as
Steve> other Amiga shells for the same operation.  If you have
Steve> *specific things which you wish were faster, please let me
Steve> know, and I'll see what i can do.  There is some penalty to be
Steve> expected since SKsh is doing much more complex things than
Steve> other shells when you type in a command, but it should be
Steve> barely noticable.

"Simple things should be simple and complex things should be
possible."  I don't want it to take forever to do simple things.  And
especially, startup and exit take forever.

Steve> [ How fast is significantly faster? ]

Starting an AShell with everything needed resident or on the ramdisk
takes under half a second.  Starting an SKsh under identical
conditions takes something more on the order of 10 seconds.  Exiting
AShell is virtually instant, while exiting SKsh takes at least 5
seconds usually, and often yells about fatal errors on its way out.

Steve> Unfortunately, I didn't save the numbers. I seem to remember
Steve> something around 30-50%, but 1) that's from memory, and 2) it
Steve> will probably depend a whole bunch on the size of block you
Steve> request, memory fragmentation, etc.

All I know is that SKsh is SLOW and LARGE.  It doesn't add enough
functionality to justify my using it, and it inhibits me too much
anyhow.  (not supporting resident programs, etc.)

I want a shell which is resident and reentrant, code size uner 10K if
possible, 20K max, additional memory overhead minimal (<10K when
"idle", including stack), fast startup and faster exit.  I want some
added functionality in the shell (cd, echo, cp, etc builtin) along
with full resident support and concurrent piping available using
either ConMan's PIP: or C-A's PIPE:.  In other words, I want a shell I
can USE.

When SKsh was first announced, it sounded promising, but that promise
wasn't borne out in practice.  I admit that I haven't attempted
installing SKsh 1.3, but SKsh is now in a similar mental category with
Dillon's "csh" and variations thereof.  Well, not quite.  But almost
as useless to me.

Too bad I haven't had time to write a shell myself.

Deven
-- 
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2151 12th St. Apt. 4, Troy, NY 12180   Phone:  (518) 274-0327
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.