Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: What should be in future SKsh versions? Message-ID: <4729@sugar.hackercorp.com> Date: 10 Dec 89 21:58:57 GMT References: <13920018@hpfelg.HP.COM> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 40 In article kim@uts.amdahl.com (Kim DeVaughn) writes: > I am all for leaving it up to the user to decide which commands, or specific > implementations thereof, to use. Absolutely. Here's an idea... it requires (a) having a special flag on a file somewhere, and (b) adding a new case to the startup module. If the flag is set, then make SKSH do a workbench-style start with a modified struct WBStartup. Maybe make sm_NumArgs negative to flag that it's new and replace: char *sm_ToolWindow; struct WBArg *sm_ArgList; } with something like: LONG sm_ReturnCode; BPTR sm_StandardInput; BPTR sm_StandardOutput; char **sm_ArgV; } Then make the new modules use this structure. When they finish they set sm_ReturnCode to the value of exit(), and bounce it back to the parent. This method of launching programs is much cleaner than the CLI's, and if an innovative must-have new tool like SKSH started using it it'd really take off. > Is it possible this limitation will be removed under 1.4? It can be removed under 1.3, and *we* can do it! > Arbitrary, hard-coded limits like this really turn me off (and yes, I know > there are a bunch of them in UN*X, too)! Grrrrrrr .... Yeh, weren't we just speaking about arbitrary hard-coded limits? -- Peter "Have you hugged your wolf today" da Silva `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"