Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: SKsh deficiencies Message-ID: Date: 6 Mar 90 19:28:38 GMT References: <13920054@hpfelg.HP.COM> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 137 In-Reply-To: koren@hpfelg.HP.COM's message of 5 Mar 90 23:15:41 GMT 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 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.