Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!brutus.cs.uiuc.edu!wuarchive!texbell!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: Using PIP: Keywords: dupping closing pipes Message-ID: <4778@sugar.hackercorp.com> Date: 16 Dec 89 21:02:59 GMT References: <4689@sugar.hackercorp.com> <1610.AA1610@julie> <1718.AA1718@julie> Reply-To: peter@sugar.hackercorp.com (Peter da Silva) Organization: Sugar Land Unix - Houston Lines: 73 In article <1718.AA1718@julie> mcr@julie.UUCP (Michael Richardson) writes: > /* fast:exp/src/include/roguestar.h */ > struct RogueStartup { > struct Message rs_Message; > struct MsgPort *rs_Process; > BPTR rs_Segment; > LONG rs_dummy; /* ALWAYS 0 -- would be NumArgs in WBStartup */ Probably should be OK. > char *rs_ToolWindow; /* Usually NULL */ I'd leave in sm_ArgList as well. > int rs_argc; > char **rs_argv; So far so good. > int rs_fhc; /* Number of file handles to install */ > long *rs_fhv; Not sure about this part. UNIXY, to be sure. But is it useful to get that far ahead of AmigaDOS? > int rs_exitcode; Good. > BPTR rs_CurrentDir; Good. But I'd put this in sm_ArgList[0]. And put in the real program name in there too. Keep compatability with WB stuff. > char **rs_environ; /* Arguments of environment space */ > int rs_envcount; /* Number of variables */ Not a good idea. You want to co-operate with AmigaDOS, and that means using env:. > char *rs_envspace; /* Buffer containing variables */ > int rs_envsize; /* Size of buffer */ > long rs_closebits[2]; /* Close this filehandle (major kludge) */ Why is this a kludge? It fits in well with rs_fhc/rs_fhv. Of course, you should probably not do this unless you know you have a Rogue program. > I don't want the locks. I pass the full file names. A possible modification > would use exec List instead of an array to hold the arguments. There's a point to both. It'd be cooler to make RogueStartup a full superset of WBStartup. Using some magic token to distinguish them. > ConMan is also a pipe-handler responding to the name PIP:NNNN... Please don't make it depend on CONMAN, anyway. > > sprintf(PipeName, "%s:rogue%dpipe%d", PipeDevice, ProcessId, Sequence++); > > pin = Open(PipeName, MODE_NEWFILE); > > pout = Open(PipeName, MODE_OLDFILE); > My last resort. Pipe: doesn't like. I can't parse this statement. PIPE: doesn't like what? > I've spent hours running dnet both here to school, and between myself and > other people, and I've _never_ gotten the scli server to work the DPIPE:, > or Matt's original pipe, or the 1.3 pipe... You can make "PipeDevice" "PIP:" if you know you need that. I don't use ConMan (irrational prejudice... it just feels icky to REPLACE con:), so I could use P:, PIPE:, whatever... What order are you opening the pipes in? -- Peter "Have you hugged your wolf today" da Silva `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"