Path: utzoo!attcan!uunet!tektronix!tekgen!tekigm2!phils From: phils@tekigm2.TEK.COM (Philip E Staub) Newsgroups: comp.sys.amiga Subject: Re: aliases and RUN Message-ID: <3801@tekigm2.TEK.COM> Date: 14 Nov 88 19:54:18 GMT References: <5230@louie.udel.EDU> <483@boing.UUCP> <2975@sugar.uu.net> <3792@tekigm2.TEK.COM> <2993@sugar.uu.net> Reply-To: phils@tekigm2.TEK.COM (Philip E Staub) Followup-To: comp.sys.amiga.tech Organization: Tektronix, Inc., Beaverton, OR. Lines: 123 Note that followups have been redirected to .tech, where I believe this discussion belongs. In article <2993@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: ..multiple references deleted.. >> > [Rewrite the CLI...] >> >I'd say... dump the CLI completely. Switch to a workbench environment. >> Why? > >Because the CLI programmer interface is inadequately documented, buggy, and >a royal pain to use if you want to try to follow the rules. Even worse, it's >infested with BPTRs. (I'm going to refer to this in the future... call this >paragpraph "exhibit A") I'll grant you that the CLI programmer interface has problems, but isn't dumping CLI a little like throwing the baby out with the bath water? > >> I hope you're kidding about this one. One reason I bought an Amiga instead >> of a Mac is that with the Amiga the icon oriented user interface is >> optional for those applications where it is appropriate, while on the Mac it >> is not. > >I didn't say change the user interface, just the programmer interface. As I OK. Sorry, I just got a bit confused. (Perhaps understandable, since you just said to "Dump CLI". To me, that could mean either (or both). >went on to say... > >> >Now, you can still have shells and command line interpreters, but make them >> >spawn programs in a workbench environment. >> So now you have the overhead of Workbench even when all you wanted was >> a CLI to begin with. > >What overhead? You don't need to have Workbench loaded to start a task and send >it a workbench message. This is all documented in considerable detail in the But you'll still have to have WB up and running to be able to click on the CLI icon to spawn the program in the first place. >manuals. It's a very clean environment. (This paragraph is my second global >reference... call it "exhibit B") > >> I suppose you could make the same statement about >> Workbench having to deal with CLI's overhead, but somehow I don't think >> thats quite the same story. > >No, it's worse. See exhibit A. > >> One of my biggest beefs about the WB environment is that it is too difficult >> to change options.... > >You're talking about the workbench *user* interface. I'm talking about the >workbench *programmer* interface. See exhibit B. Actually, my comment refers to both. I'm a little concerned that we are losing sight of the fact that the Programmer is a user too, and although his needs may not be those of the majority of users, I hope they are still worthy of consideration. First of all, much of the code I use, write, or port (much of it from Unix) passes command line options via the argv array. The thought of having to call up Workbench's INFO menu selection every time I wanted to switch between 'make -f makefile.1' and 'make -f makefile.2' or 'cc -n foo.c' and 'cc foo.c' or having to have two separate icons to do this worries me. (No, I haven't forgotten what you said about the fact that you could spawn a shell from WB. I guess I'm just not sure how I feel about *having* to do it). Your (correct) assumption below that I haven't done much (actually any) software which is specifically intended to be invoked from Workbench is going to show here, but I'm under the impression that the message-passing mechanism for starting a Workbench based application may be clean and consistent and nice, but it also totally alien to any other C language programming environment I know about, at least insofar as command line arguments are concerned. Isn't that what we're really talking about here? I'm really not trying to be reactionary about this, but if that's so, I'd still have to vote for maintaining some way to support the argc/argv based programs, if for no other reason than the fact that the Amiga is not (yet?) enough of a standard software environment that we can afford to just write off (or at least make more difficult to port) a very large existing base of code. And yes, I have looked at the startup modules which create the argc and argv which get passed to a user's 'main'. I know they aren't pretty. And I know that it is there mostly because of the ideosyncracies of the BCPL. But I'd have to think it would look just as bad to synthesize argc/argv from a Workbench startup message. > >> Maybe I misunderstood your intent here, >> but this is exactly what I feel you would be doing by making CLI run under >> Workbench, rather than the other way around. > >Currently, neither runs under either. The Workbench and the CLI are two >completely different and mutually exclusive run environments layered on top >of a 'process' structure. In the CLI you run as part of the CLI process, >and in the workbench you run as a seperate process... much as you do in UNIX. Perhaps I should have worded that a little differently. What I meant to say is that as things are now, the Workbench is started from the CLI environment that exists when the system boots. If the Workbench were the default environment when the system boots, you would have to start a CLI from Workbench, as is now possible, but which I seldom do, because I don't usually load Workbench as part of my startup-sequence. > >> Am I just dense, or what? > >No, you probably just haven't done much programming in this area of the system. Yes, you are very correct here. >-- > Peter da Silva `-_-' peter@sugar.uu.net > Have you hugged U your wolf today? > > Disclaimer: My typos are my own damn business. Phil -- ------------------------------------------------------------------------------ Phil Staub Tektronix, Inc., Vancouver, Washington 98668 phils@tekigm2.MEN.TEK.COM