mjw@f.gp.cs.cmu.edu (Michael Witbrock) (04/22/87)
Keywords:
Lately I have been thinking about ways to speed up the CLI.
An extensible command set is great in theory, but is rather slow in practice.
Two ways of dealing with this are evident:
1) Load the 'important' parts of C: onto ram: at startup, and put
ram: at the beginning of the path.
2) Write a shell with (some) built in commands.
There is a third, more general possibility: command caching.
This would require replacing the CLI with a (very primitive) shell type
program. This program, when given a command to execute, would look for
it on ram: ( a virtually instantaneous operation ), and if it's there, run
it from there. If not in ram, copy it there and run it. This should mean
that uncached commands run about as slowly as they do now (i.e. very, but
it's no loss), and cached ones at from-ram speed.
Obviously, when the 'shell' was started up, it coould take params like,
max ram: space to use, Max size command to cache etc. Care would have to be
taken in designing the cache replacement strategy (LRU, FIFO, use counts etc
etc).
This scheme has the advantage over scheme 1) above in that it doesn't
'waste' ram: with unused commands, nor does it wast time loading them.
It has the advantage over 2) in that it can make 'resident' the commands
that the user, not the shell designer uses most often.
There is, of course, the problem of telling when c: has been written to.
(i.e. cache consistency)
The only way I can see is to try to tell from the commands, and then do a
time stamp comparison. This wouldn't catch everything, but in most cases,
people aren't regularly changing the built in commands.
----
This is not meant in any way to be an attack on any of the shells people
have written. These are wonderful tools. I use one of them all the time (and
more often when I get a bit more memory). command line editing is not just
a nice thing to have, it is an essential preventative for insanity (HINT
for 1.3 or 2.0 or whatever :-]).
These shells may, however provide more than the average amiga-dos CLI
user needs.
In any case, caching frequently used non-built in commands might improve on
the current shells. (e.g. caching cc on a machine with lots of memory [I
know, I know it's not in c: ...]
Well? hows about it?
--
====================================================================
Michael.Witbrock@f.gp.cs.cmu.edu
US Mail: Michael Witbrock
Dept of Computer Science
Carnegie Mellon University
Pittsburgh PA 15213-6890
USA
Telephone : (412) 268 3621 [Office]
(412) 681 3806 [Home]
========================================================
"Be good, be kind, in whatever you say and do, and remember: keep cool
till after school." (Ollie Olsen, Television New Zealand Kids Programme host
[Translated from sign language] ).
--
====================================================================
Michael.Witbrock@f.gp.cs.cmu.edu
US Mail: Michael Witbrock
Dept of Computer Science
Carnegie Mellon University
Pittsburgh PA 15213-6890
USA
Telephone : (412) 268 3621 [Office]
(412) 681 3806 [Home]
========================================================
"Be good, be kind, in whatever you say and do, and remember: keep cool
till after school." (Ollie Olsen, Television New Zealand Kids Programme host
[Translated from sign language] ).page@ulowell.UUCP (04/23/87)
mjw@f.gp.cs.cmu.edu (Michael Witbrock) wrote in article <50@f.gp.cs.cmu.edu>: >Lately I have been thinking about ways to speed up the CLI. The CLI is fast enough (since it doesn't really do anything); it is DOS loading the commands from disk that you are concerned about. >This would require replacing the CLI with a (very primitive) shell program. >This program, when given a command to execute, would look for it on ram: This happens now if you use the PATHS feature of the CLI. I suspect the point of your article was that the shell put every command into ram when it gets started up, providing room. The problem with this (assuming you use a fixed area for the shell's 'cache') is that commands will be even slower to start up if they are not already in RAM, since the shell has to copy it there before it starts it up for you. This gets worse when your cache fills and you have to start removing files (LRU, etc) to fit your new one in. Also, since this is a multitasking machine, you will either end up with redundant caches (two CLIs, each with 'emacs' in ram?) or collisions for the same cache (I have 150K free, CLI 1 starts up DPAINT and CLI 2 starts up METASCOPE ... who gets the space?) In effect, it is a better idea if _you_ figure out what commands you use all the time and want quick activation for. Put them someplace in your ram disk - say RAM:C, and point the CLI (via the PATH command) to look there first. It is dynamic, can be shared across CLIs without problems, can be added to or deleted from easily. To implement your idea you'd need some kind of AI that knew what you'd been doing and what you were probably about to do. Maybe a shell that counts activations over time, and if it sees (say) 10 activations within 30 minutes it asks "Should I put this in RAM:C for you? You seem to be using it often enough that you'll benefit from the decreased load time. You'll have enough room in RAM if I remove FOO, since you haven't used it in the last 2 hours." The best idea, however is to rewrite AmigaDOG. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (04/24/87)
In article <1213@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >In effect, it is a better idea if _you_ figure out what commands you >use all the time and want quick activation for. Put them someplace >in your ram disk - say RAM:C, and point the CLI (via the PATH command) >to look there first. It is dynamic, can be shared across CLIs >without problems, can be added to or deleted from easily. There's an even better way, that several people (me among them) have pointed out. It's called a "disk cache." Instead of having the CLI buffer commands, you have the disk driver buffer tracks - in fast ram, if needed. This solves the problems of two CLI's saving copies of a file, etc. I think the product WOW! is supposed to be this. It's also supposed to have a dialable cache size. Optimally, it floats the cache with memory useage, so if I do something large, the cache gets flushed so I can use it as real memory. Likewise, this is better than ram:. Instead of copying things to ram, they get put in the disk cache. Things you tend to use stick to the disk cache, things you don't use very often get flushed out. Which is (probably) what you want. I ran a z80 system with 1/2Meg of cache and two floppies, and got better edit/compile cycles than people running off of hard disk. Seems that the right things stuck to the disk between phases. In other words, I think that a disk cache is in all ways better than ramdisk. Unless you've got something you don't plan on touching very often, but want to _always_ be there. vd0: does that quite nicely, though. The only other lossage is that temp files might get "written through" to disk, even if they are never read off the disk. Well, you can't win them all. >The best idea, however is to rewrite AmigaDOG. I've never run into an OS for which that isn't true. But caching vital things can overcome a _lot_ of problems. Just ask anyone who's kicked the Unix disk cache from 15-30 buffers to 100+ buffers. <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
blgardne@esunix.UUCP (Blaine Gardner) (04/24/87)
in article <50@f.gp.cs.cmu.edu>, mjw@f.gp.cs.cmu.edu.UUCP says: > > command line editing is not just > a nice thing to have, it is an essential preventative for insanity (HINT > for 1.3 or 2.0 or whatever :-]). Have you see Conman? I just got it from a local BBS last night, and I'm already in love! Conman is alternate console handler that gives you VMS style editing for the CLI (has some other neat features too). There are three small files (total < 7K) that need to be placed in the L, LIBS and C directories. Then just have your startup-sequence run Conman and the CLI is now really useful. Having CLI editing and a command history gives me about all I need, the shells are a bit of overkill for my uses. An interesting note: the author (William Hawes) is plotting with the Software Distillery to make this part of a "super-whiz-bang display manager". I can hardly wait! The files for Conman are quite small, anyone want them posted (if so, where, is comp.binaries.amiga, or whatever, reliable)? -- Blaine Gardner @ Evans & Sutherland UUCP Address: {ihnp4,decvax}!decwrl!esunix!blgardne Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne
upl@puff.WISC.EDU (Future Unix Gurus) (04/29/87)
In article <69@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: > Have you see Conman? I just got it from a local BBS last night, and I'm >already in love! Conman is alternate console handler that gives you VMS >style editing for the CLI (has some other neat features too). There are >three small files (total < 7K) that need to be placed in the L, LIBS and >C directories. Then just have your startup-sequence run Conman and the >CLI is now really useful. > I love conamn too. You neglected to mention that, since it is a replacement console-handler RATHER than a replacement cli, you get these functions auto-magicly in ANY console window, even ones opened by application programs. (I open a console window for debugging, and conman makes it a real pleasure). There IS a minor gotcha in conman, though. Have you tried doing a "more" from a conman cli? I replaced type (pretty useless) with more from the extras disk. Problem: Under conman, running more just returns a "not enough memory error". I have 1.5meg! I refuse to believe that conman takes 1meg+ !!! (Actually, I KNOW it doesn't because I checked with sysmon). Looks to me like more is assuming something about its environment it shouldn't, as everything else I've tried runs fine. Anybody have any suggestions out there? Most of what I do with my extra cli window during programming is more-ing include files...... Jeff Kesselman captain@uhura.cs.wisc.edu
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (04/29/87)
In article <726@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: > I love conamn too. You neglected to mention that, since it is a replacement > console-handler RATHER than a replacement cli, you get these functions > auto-magicly in ANY console window, I got a copy after seeing the initial posting. As good as that (as far as I'm concerned) is that the history applies to input to commands, as well as input to the CLI. This is something I've wished for in Unix for a while... > There IS a minor gotcha in conman, though. Have you tried doing a "more" > from a conman cli? I replaced type (pretty useless) with more from the > extras disk. Problem: Under conman, running more just returns a > "not enough memory error" There's another problem. The maximum size for a window opened with conman is the max of (640,200) and the size it was opened at. I run on an interlaced, morerow'ed screen, so this hurts. So much for half-height POPCLI windows... <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
phillip@cbmvax.cbm.UUCP (Phillip Lindsay CATS) (04/29/87)
in article <726@puff.WISC.EDU>, upl@puff.WISC.EDU (Future Unix Gurus) says: > > In article <69@esunix.UUCP> blgardne@esunix.UUCP (Blaine Gardner) writes: > >> Have you see Conman? I just got it from a local BBS last night, and I'm > > There IS a minor gotcha in conman, though. Have you tried doing a "more" > from a conman cli? I replaced type (pretty useless) with more from the The problem is that "conman" isn't supporting all the con-handler packets. Carolyns "more" sends a diskinfo packet to find out about the consoles enviroment. I talked to author of "conman" and a revision is comming... ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making.
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (04/30/87)
In article <726@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: >[] > There IS a minor gotcha in conman, though. Have you tried doing a "more" > from a conman cli? I replaced type (pretty useless) with more from the > extras disk. Problem: Under conman, running more just returns a > "not enough memory error". I have 1.5meg! I refuse to believe that > conman takes 1meg+ !!! (Actually, I KNOW it doesn't because I checked with > sysmon). Looks to me like more is assuming something about its environment > it shouldn't, as everything else I've tried runs fine. Anybody have any > suggestions out there? Most of what I do with my extra cli window during > programming is more-ing include files...... Hey! That's my More program you're picking on! My code makes the perfectly valid assumption that a machine booted with 1.2 has a console handler which PROPERLY HANDLES ALL 1.2 CONSOLE PACKETS. Under the REAL 1.2 AmigaDOS console handler, the ACTION_DISKINFO and ACTION_SCREEN_MODE packets are supported and ALWAYS return DOSTRUE (-1L). So, with the real 1.2 console handler, my packet-sending routine could only fail if there was NOT ENOUGH MEMORY to allocate the needed structures. The current version of Conman was not fully/properly supporting these packets and the author is correcting this problem. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
finkel@TAURUS.BITNET (08/10/88)
In article <2213@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes: > >After hearing the talk of AmigaShell and other related things. >I am wondering if any of these shells can execute my favorite >unix KSH command, namely the backtick. Let me give you an >example. > >Backtick (or grave accent) will "execute a command in place" >and let the results of that command be the arguements for >your command line. About 4 months ago, someone posted his Shell 2.07 variant. it included wildcard expansion, using the TAB key, and it also included the `command` trick you want. Wait ... I am looking at the shell docs right now ... Well - here it is: The Shell was Matt's shell with changes by Johan Widen ( jw@sics.se ), who is probably reading this now. The shell was 10KB larger than the original 2.07 release, probably because it was converted back to Lattice. Johan didn't post the full source code, but he included the diffs from the original shell. He also included a small program called 'sets' that makes the best use of the `` trick. Udi ------------------------------------------------------------------------------- Udi Finkelstein | Bitnet: finkel@taurus.bitnet or finkel@math.tau.ac.il Tel Aviv University | Internet: finkel%taurus.bitnet@cunyvm.cuny.edu Israel | UUCP: ...!psuvax1!taurus.bitnet!finkel -------------------------------------------------------------------------------
jonasf@kuling.UUCP (Jonas Flygare) (08/11/88)
From article <8808101326.AA29986@MATH.Tau.Ac.IL>, by finkel@TAURUS.BITNET: > About 4 months ago, someone posted his Shell 2.07 variant. it included > wildcard expansion, using the TAB key, and it also included the `command` > trick you want. I used that shell for a while, but had to abandon, due to frequent GURU's.. Anyone know what it might be? I use ARP, 1.2 and the csh Johan made. I have almost no problems with the regular csh.. > Udi > > ------------------------------------------------------------------------------- Udi Finkelstein | Bitnet: finkel@taurus.bitnet or finkel@math.tau.ac.il Tel Aviv University | Internet: finkel%taurus.bitnet@cunyvm.cuny.edu Israel | UUCP: ...!psuvax1!taurus.bitnet!finkel ------------------------------------------------------------------------------- -- Jonas Flygare (aka Flax) +------------------------------------------+ email: jonasf@kuling.UUCP | "Never try to hack while a playful ferret | real: Vaktargatan 32 F:621 | is watching your toes. | S-754 22 Uppsala Sweden +-------- I TRIED....... OUCH! ------------+
bennete@romana.cs.orst.edu (Erik J. Bennett) (01/03/89)
I ran into a problem yesterday with a dillon/drew shell. I had a REALLY big .zuu file that I needed to download from a unix system. Because of the size, I used the unix 'split' which spilts a file into 1000 line chunks. Upon the completion of this download (10 hrs @ 2400 baud), I typed: cat >foo.uue bar.z* and it didn't work. the command line truncates at some finite point (255 char?). The questions: 1) Is there a way around the 255? char limit? 2) Is there a shell that doesn't have this problem? 3) Am I the only one in the western hemisphere who considers this a problem? Thanks, (happy 1989), may we see lots of neat stuff for the machine this year. -Erik bennete@romana.cs.orst.edu
dillon@CLOUD9.BERKELEY.EDU (Matt Dillon) (01/03/89)
:I ran into a problem yesterday with a dillon/drew shell. I had a REALLY :big .zuu file that I needed to download from a unix system. Because of :the size, I used the unix 'split' which spilts a file into 1000 line chunks. :Upon the completion of this download (10 hrs @ 2400 baud), I typed: :cat >foo.uue bar.z* :and it didn't work. :the command line truncates at some finite point (255 char?). The questions: :1) Is there a way around the 255? char limit? :2) Is there a shell that doesn't have this problem? :3) Am I the only one in the western hemisphere who considers this a problem? : :Thanks, (happy 1989), may we see lots of neat stuff for the machine this year. :-Erik :bennete@romana.cs.orst.edu The problem stems from BCPL limitations. BCPL command strings can only handle something 202 chars (I think), with a theoretical limit of 255. This limitation doesn't apply to C programs but I chopped it in my shell. (2) Maybe, I dunno. I suppose I should get off my butt and allow C programs to have a larger limit. Nothing anybody can do about the BCPL programs. (3) No, I remember a couple of years ago complaining about this too. -Matt
john13@garfield.MUN.EDU (John Russell) (01/04/89)
In article <8079@orstcs.CS.ORST.EDU> bennete@romana.cs.orst.edu (Erik Bennett) writes: > >cat >foo.uue bar.z* >and it didn't work. foreach a ( bar.z* ) "cat >>foo.uue $a" This appends each file to the file foo.uue, which is not required to exist before you execute the command. The foreach command is ideally suited to getting around the 256 char limit on command lines or dealing with commands that don't take multiple parameters. John -- "If you steal all money, kids not be able to BUY TOYS!" -- Saturday morning cartoon character explaining why theft is bad
acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) (11/03/89)
I'm looking for a shell (CLI) for the Amiga which will emulate a Unix Korn, C or Bourne shell. Are there any out there (PD or commercial) which will provide a believable enough illusion of Unix? Craig.
a218@mindlink.UUCP (Charlie Gibbs) (11/06/89)
In article <3240@lab.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: >I'm looking for a shell (CLI) for the Amiga which will emulate >a Unix Korn, C or Bourne shell. Are there any out there (PD or >commercial) which will provide a believable enough illusion of >Unix? I'm still using Matt Dillon's Shell2.07m, which is on a Fish disk somewhere. I think later versions have been produced, but this one is good enough for me. Many commands are built in, and they have more of a Unix syntax; switches are preceded by a hyphen as God intended, with none of those damned keywords. If any of the commands aren't already their Unix equivalent (e.g. dir and copy) the built-in alias facility can fix them up. The wild card character is an asterisk. There is a history complete with command editing and the ! search. Shell scripts are apparently supported fairly well, although I haven't taken the time to get into it. But most important of all (to me, anyway), any file copy assumes the CLONE option. This feature alone was sufficient to get me using the shell, since I consider date stamps far too important (e.g. for version control) to allow the standard CLI to destroy them. Along with the shell I'm using on my bridge board (UNCLE even flips the MS-DOS backslash around the right way again), I can type Unix commands wherever I go. > Craig. Charlie_Gibbs@mindlink.UUCP "I used to be indecisive, but now I'm not so sure."
swan@jolnet.ORPK.IL.US (Joel Swan) (11/06/89)
In article <3240@lab.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes:
:
:
:I'm looking for a shell (CLI) for the Amiga which will emulate
:a Unix Korn, C or Bourne shell. Are there any out there (PD or
:commercial) which will provide a believable enough illusion of
:Unix?
:
:
: Craig.
The last two issues of Amazing Computing has been looking at a UNIX type syntax
shell called TShell. It is commercial (Metran Technology) and can be
had from Abel supply for $29.26. It looks rather impressive.
Joel Swanmamba@csd4.csd.uwm.edu (Paul A Deisinger) (11/07/89)
In article <2019@jolnet.ORPK.IL.US> swan@jolnet.UUCP (Joel Swan) writes: >In article <3240@lab.udel.EDU> acm131@eric.ccs.northeastern.edu (Craig Scott Lennox) writes: >:I'm looking for a shell (CLI) for the Amiga which will emulate >:a Unix Korn, C or Bourne shell. Are there any out there (PD or >:commercial) which will provide a believable enough illusion of >:Unix? >: Craig. >The last two issues of Amazing Computing has been looking at a UNIX type syntax >shell called TShell. It is commercial (Metran Technology) and can be >had from Abel supply for $29.26. It looks rather impressive. >Joel Swan I have been looking for either a replacement shell, or a program which will run overtop of the existing 'AShell' and give me filename completion as implemented in the Unix TShell. Is there such a beast? For those of you who don't have the wonderful Tshell on your system: If I have several files in my directory: Foo foo cab bozo itzy etc... I can type: >more F(tab) and it will automatically fill it in for me: >more Foo Also helpful would be command line spell checking (also a tshell feature) PD -- My other .sig is a Porsche. Boongawa.