mcr@julie.UUCP (Michael Richardson) (01/12/90)
[ I was away for Christmas, so I'll respond to a whole bunch of stuff in one article. Please excuse any errors in attribution, I'm doing this in dme.] In article <11223@thorin.cs.unc.edu> tell@oscar.cs.unc.edu (Stephen Tell) responded to article <4778@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva), both of whom were quoting this code: char **rs_environ; /* Arguments of environment space */ int rs_envcount; /* Number of variables */ peter> Not a good idea. You want to co-operate with AmigaDOS, and that means peter> using env:. tell> But env: is deficient in that its "global" and therefore you can't have tell> more than one environment. Yes, but my getenv() command will look at the local one, and then arp/Manx, and finally 1.3. putenv() may just do arp/Manx (since there is little point in changing your own environment unless you want to pass that on to a child, in which case I think I may implement something like addenv() or something. I don't know yet.) peter>I understand this. However you should retain compatibility with the system peter>as it exists. Similarly, your programs should use AmigaDOS keyword argument peter>handling rather than UNIX -option style, and they should work properly under peter>the Workbench and CLI as well as RogueStartup. Hmm. Maybe I'm just a Unix weeny, but I like -option a LOT better than the silliness in AmigaDOS. [Try getting a listing of a directory called 'DIRS'] Depending on how soon the 2630 comes out (and drops in price) how cheaply I can get disk (and tape backup!) and SVR4, I may just find myself a 32332 VME card and use the Amiga as my terminal. [I might even consider a 386.] That isn't the issue though, I like the Amiga, and I am a starving part time student (well, actually, I eat rather than buy ram. I know where my priorities lie.) so considering new equipement isn't really an option. peter>If Getenv returns a different value depending on whether the program is peter>started from RogueStartup and CLI that's a bad thing. tell>There's a point to both. It'd be cooler to make RogueStartup a full superset tell>of WBStartup. Using some magic token to distinguish them. That is why I put the `dummy' field in the same place as the number of workbench arguments went. Workbench doesn't ever pass zero arguments, (I hope.) [Drat, I saved these articles in the wrong order...] mcr> BPTR rs_Segment; mcr> LONG rs_dummy; /* ALWAYS 0 -- would be NumArgs in WBStartup */ peter> Probably should be OK. mcr> char *rs_ToolWindow; /* Usually NULL */ peter> I'd leave in sm_ArgList as well. I'm not sure why I would want to? mcr> int rs_fhc; /* Number of file handles to install */ mcr> long *rs_fhv; peter> Not sure about this part. UNIXY, to be sure. But is it useful to peter> get that far ahead of AmigaDOS? Yes, no. You see, part of my master-plan is to create ROOT: (I've already started playing. I've got a simple file system with 26 possible single letter filename. Coincidentally, they correspond to the letters of the alphabet. I haven't got ExNext working yet though, I haven't figured out what (if anything...) remains constant. I also haven't looked at NET: yet.) ROOT: will allow one to mount other file systems in its namespace, and do packet forwarding -- well actually, it will be more of `packet translation' --- I'd like to kludge a DupHandle() call. [I saw the '89 DevCon notes yesterday, I'm quite upset over LockFromFH(), NameFromFH(), etc.. But, then I'd already heard rumours of them on the net, from Colin Plumb, I believe] Before I go much further --- I should say: I doubt I will ever get this working well, if at all. However, it will keep me busy when I get tired of dealing with other people's problems... mcr> int rs_exitcode; peter> Good. This was the main reason I started this. Execute() (the most reliable way I could see to launch a program, wouldn't give me the exit code. I knew of SyncRun(), but wasn't sure I wanted to get into Arp at the time.) mcr> BPTR rs_CurrentDir; peter> Good. But I'd put this in sm_ArgList[0]. And put in the real program peter> name in there too. Keep compatability with WB stuff. The whole point of the rs_dummy field is so that (if you like), you _can_ tell the difference between workbench and roguestart. If anything, sm_ArgList[0] should contain a lock on the directory that the program came (quite usefull in many respects when it comes to finding your binary. However, I don't necessarily believe in doing things like modifing one's binary. I've stored data files [under SunOS] with my binary, but that was a Lisp interpreter, and the data file was in fact built from the symbol table of the binary, and was therefore very intimitely related.) mcr> long rs_closebits[2]; /* Close this filehandle (major kludge) */ peter> Why is this a kludge? It fits in well with rs_fhc/rs_fhv. The fact that it exists at all is the kludge. See debate over DupHandle(). peter> Of course, you should probably not do this unless you know you peter> have a Rogue program. I haven't decided how to recognise a Rogue program. I may rely on the user doing things correctly, I may build in (in my shell) a `ROGUEPATH' that only holds Rogue binaries and just SyncRun() the other stuff (a Rogue program can still be run at the CLI), or I may steal one of the higher protection bits... peter> There's a point to both. It'd be cooler to make RogueStartup a full superset peter> of WBStartup. Using some magic token to distinguish them. Hmm. I like the message passing concept. I'm not in love with the WBStartup. mcr> ConMan is also a pipe-handler responding to the name PIP:NNNN... peter> Please don't make it depend on CONMAN, anyway. My personal sanity depends somewhat on ConMan. I don't understand why ^S/^Q processing is such a strange concept to CA=. They had a chance to win me with NewCon:, but the ^S/^Q killed it. mcr> My last resort. Pipe: doesn't like. peter> I can't parse this statement. PIPE: doesn't like what? Pipe: doesn't like me. :-) In article <11223@thorin.cs.unc.edu>, tell@oscar.cs.unc.edu (Stephen Tell) wrote: tell> Now if we were all to use env:<process-id>/variable, and use links where only tell> a small part of the environment (or none at all) changed between a parent I can't say I like that. Yes, we need a global environment, but an inherited environment is also a really neat idea. tell> and its child... (What? no links? aren't they "in there" too?) Not in 1.4 we were told (I can't argue), but never if the lock -> file handle function is made bijective, and one can go from a file handle to a lock. Umm... I hope I haven't stepped on any toes. :-) For those who hung in there this long (the 'n' key suspiciously close to the home row...) and are curious what has happened to (rogue) popen(av,ac,pp): it now uses CA= PIPE: and seems to function well. I haven't done much more than run a couple of tests of it, so I not yet certain. I'll probably post to alt.sources.amiga (if that still exists, that is, I assume it was not a facsimile of Peter da Silva that created it) providing that fts1's feed (nrcaer, now on the internet) had in fact created it, etc... I've never seen anything come through, but I haven't exactly been watching. I let my roomate do that type of thing. -- :!mcr!: Michael Richardson Amiga v--------+ HOME: mcr@julie.UUCP | SCHOOL: mcr@doe.carleton.ca Fido: 1:163/109.10<--+ WORK: michael@fts1.UUCP
peter@sugar.hackercorp.com (Peter da Silva) (01/17/90)
In article <1766.AA1766@julie> mcr@julie.UUCP (Michael Richardson) writes: > Yes, but my getenv() command will look at the local one, and then > arp/Manx, and finally 1.3. This seems reasonable... PUTENV should go into the 1.3 environment, though. You can always use the Manx stuff for the Manx environment, and you can build your *own* RogueStart. > Hmm. Maybe I'm just a Unix weeny, but I like -option a LOT better than > the silliness in AmigaDOS. Both have advantages and disadvantages, but this is AmigaDOS, not UNIX. When I write a program, I always stick to the syntax the machine uses, no matter how silly it is: UNIX: command -opts files Amiga: command options files DOS: command /opts files DEC: command files/opts Sperry: command,opts files Eric Allman recently published an article in UNIX Review describing a common interface that can handle all of these cases. It's called "parseargs" and will (according to the publisher) soon come to a sources group near you. > That is why I put the `dummy' field in the same place as the number > of workbench arguments went. Workbench doesn't ever pass zero arguments, > (I hope.) Well, you should also put a dummy in at sm_ArgList as well, then. Stick all your flags at the end. > I'm not sure why I would want to? Because a LOCK+name is the only unambiguous pointer to a file. Because you need to remain consistent with Intuition. At the very least skip over all the currently used fields. Personally, I think you should have a magic number right after the current startup message and put ALL your new fields there. And fill in all the gaps in the existing message. That way you can RogueStartup Workbench programs, and they work. It allows for interoperability. > You see, part of my master-plan is to create ROOT: I've thought of this one, too. It's a good idea. Go for it. But what does it have to do with passing an array of file handles. You need to retain as much interoperability as possible. > The whole point of the rs_dummy field is so that (if you like), > you _can_ tell the difference between workbench and roguestart. Yes, but you also want to be able to RogueStart workbench programs. If you can do that then RogueStart can take over completely without hurting anything. If not, it'll just become a third alternative... > If > anything, sm_ArgList[0] should contain a lock on the directory that > the program came Just like Workbench. > peter> Of course, you should probably not do this unless you know you > peter> have a Rogue program. > > I haven't decided how to recognise a Rogue program. As you can see by some of my other comments, I've started to think that you may be able to build RogueStart so it will safely start workbenchable programs. In which case you don't need to recognise Rogue programs at all. Have a regular WBStartup, a magic word (the 8 bytes 0xFEEDFACE 0xDEADBEEF would make a fun one), and your extra fields. Then a Rogue program would modify the magic word (say, to 0xDEADBABE). That way if you call a WB program you know you may have more cleanup to do when you get the message back. > Hmm. I like the message passing concept. I'm not in love with the > WBStartup. It's better than Execute. More importantly, it's there. > My personal sanity depends somewhat on ConMan. I don't understand > why ^S/^Q processing is such a strange concept to CA=. They had a > chance to win me with NewCon:, but the ^S/^Q killed it. Yes, but CONMAN isn't standard. Maximise interoperability and portability, remember... > I'll probably post to alt.sources.amiga (if that still exists, > that is, I assume it was not a facsimile of Peter da Silva that created it) alt.sources.amiga has been around for on the order of a year. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
aduncan@rhea.trl.oz.au (Allan Duncan) (01/19/90)
> the silliness in AmigaDOS. [Try getting a listing of a directory called > 'DIRS'] Depending on how soon the 2630 comes out (and drops in price) how list "DIRS" and similarly for any other keyword. Allan Duncan ACSnet aduncan@rhea.trl.oz ARPA aduncan%rhea.trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!rhea.trl.oz.au!aduncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
new@udel.edu (Darren New) (01/19/90)
>> the silliness in AmigaDOS. [Try getting a listing of a directory called >> 'DIRS'] Depending on how soon the 2630 comes out (and drops in price) how >list "DIRS" >and similarly for any other keyword. Actually, it's deeper than that. You can say LIST ? and get the template (as you can for almost any AmigaDOS command except FORMAT). The template lists "dir" as one of the keywords. Therefore, LIST DIR XXX will list directory XXX no matter what the name is. Under most UNIX commands, this is impossible even if you quote it. For example, try removing a file named "-rf" from your home directory under UNIX. Even the commands that support "-" as an option meaning that you have reached the end of the options usually don't like it if you have "-" as the only option. Additionally, many commands treat "-" as meaning stdin. Hence, a file named "-" will either be treated as meaning stdin or as meaning the end of the options list; either way, it's ignored. Also, under AmigaDOS, the templates allow an easy one-line interactive help unavailable to UNIX commands that work even without parameters. For example: % rm Usage: rm [-rfi] files % cat (not no usage message) If you want usage under AmigaDOS, just type LIST ? If you want a directory of file "?" just type LIST DIR ? It always works, and as expected. Even with shell scripts this works. The only advantages of the UNIX method is that it is easier to parse in your program and that wild-card expansion can be done outside the program (although this can be ugly too, for example in UNIX grep). If I could figure out how to get arp.library to do the @$#$%#@ parsing for me, I'd always use the AmigaDOS templates. -- Darren