Path: utzoo!utgpu!watmath!att!pacbell!ames!indri!uakari.primate.wisc.edu!csd4.milw.wisc.edu!leah!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Shell command line passing Message-ID: Date: 8 Aug 89 00:40:34 GMT References: <0356.AA0356@julie> Sender: usenet@rpi.edu Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 36 In-reply-to: mcr@julie.UUCP's message of 5 Aug 89 01:20:53 GMT On 5 Aug 89 01:20:53 GMT, mcr@julie.UUCP (Michael Richardson) said: [lots of stuff about "policy"] methinks you've confused "policy" with "restrictions"... :-) mcr> I once brought up the fact that the CLI (Shell, ArpShell, WShell) mcr> are not a user level process. They most certainly ARE user-level processes. mcr> They are part of AmigaDOS. They are NOT shells. I was told that mcr> no, they are. The interface between them and AmigaDOS just isn't mcr> well defined. AmigaDOS's CLI *IS* a shell. It is a very simple shell, but it is a shell. What makes it so bizarre is that all programs it runs are loaded by the CLI, and run synchronously in the same process as the CLI, as if it were a function call. [which, in effect, it is.] mcr> But the whole point of having a DOS at all is so that the user mcr> can have it load and start running a program. How should they do mcr> that? With a program of course. Which is loaded because the user mcr> asked DOS to run it for them, which was loaded because.... The CLI is a shell, a specific program which _uses_ AmigaDOS calls to load a program, and simply jumps to the loaded code to start running it. [when the program exits, the CLI regains control and cleans up.] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.