Path: utzoo!dciem!dretor!nrcaer!julie!mcr From: mcr@julie.UUCP (Michael Richardson) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Keywords: Workbench Shells Exceptions Message-ID: <0856.AA0856@julie> Date: 25 Mar 89 21:27:42 GMT References: <6275@cbmvax.UUCP> <0776.AA0776@julie> Followup-To: comp.sys.amiga.tech Organization: Sandleman Software Works' Debugging Department, Ottawa, ON Lines: 112 Randall Jesup writes: > No, sorry. The CLI is a shell, just like Workbench, or AmigaShell. >It so happens that the division isn't totally clean, and one should consider >the CLI structure as part of the program environment, since programs often >access it directly. Then why the pr_CLI entry in the Process structure? If I should "consider the CLI structure as part of the program environment" then the CLI IS special, as it maintains that structure. Since writing shells appears to be somewhat of a black art, and CLI being the main shell in existence, then the CLI must be special. > 99% of unix users (not hackers) don't care much whether a Shell is >somehow special or just another program. The only people who care are >hackers/wizards and shell writers. Then 99% of unix users must spend all their time using those menu driven stuff, in which case, Vic Basic (without a wedge) is all they really need. If you do not include hackers as unix users, then you've cut the population of Unix users by a LARGE proportion. [stuff about 1.4, things breaking] Understand that I am not complaining that much about the contradiction, I just wish you put your effort in the right places. > This is all amusing, but we are trying to reduce the number of >distinct environments in the system, not increase them. The current >WB/CLI(or shell) split makes the system tough to work with, especially for >novice users. I find that amusing with Dave Haynie telling us that switching between Unix, AmigaDOS, Vax/VMS, etc. is easy once you get used to it. If writing shells was easier, (the shell/program interface was well documented, supported inheritance of environments, redirection (open file descriptors are passed), and error codes.) then the issue of who does wildcarding, and what they are would be less important. (If the shell wants to do it, then it need only quote every argument. If the program doesn't want to do it, then you wind up with things like DPAT.) >> Wish read(), write(), were better documented. I don't really understand >>what they do... (internally) > > Internals are supposed to be hidden. I meant the packet interface to the filing systems. What if I want to do asynchronous I/O? [Execute.device] > Sounds like a WorkBench process to me. It was meant to. (And Peter, I was thinking about and looking at your launch code when I wrote that. That is exactly what I had intended to do.) > Can't be done unless you can GUARANTEE the PC will not be in a ROM >routine, or with a Forbid() or LockIBase or ... held. Exceptions aren't as >useful as you think. Some standard exception code would be nice. (excption.zoo by Herald T. Hewes came across the net awhile ago, although I've yet to incorporate it into my code. I do intend to though.) And if that means that code that wishes to lock a resource must also add unlocking routines to the exception chain, then okay. Or else, it must request that exceptions not be delivered while it is in progress. (Enable()/Forbid() would automatically do this. A ExceptionMask() call would also be a good idea when locking structures.) The upshot of this is that programmers would have a cleaner way to deallocate resources in an intelligent way. >> It ISN'T fork()/exec(), but it does make a much more orthogonal >>system, shells send messages to "execute" servers, much the same >>way that comm programs send messages to "serial" devices... > > In fact, exactly how I do it. Exactly how you do what? talk to the serial device or the execute device? >> Have you talked to Colin (Plumb?) (microsoft!w-colinp) >> His extent based file system looks quite nice... > > Not for HD's. Also might be kinda slow in some cases. The point is that people are looking into alternate filing systems. I'm of the opinion that one SHOULD use different filing systems for different applications. If you intend to store lots of little files scattered into several hundred directories, (That is how I program --- the effects of a youth spent with Unix boxes accessed at 300 baud.) then use a filing system designed for that. If you like having plenty of 300k animations around, a file system with a bigger allocation unit is for you. >> The fexec() library function would lookup the highest FileHandle assigned >>to ask (kept in an Exec list of course to eliminate that 20 files open bit) >>and duplicate each one. This list would be part of the standard stuff > > You can't dup() a filehandle. So I can take the result of "Output()", pop it into a message, send it to another task and have the other task write to wherever I was writing? I gather that I must wait until the other task has finished with it and then _I_ must close it (or return it to wherever I got it.) But it is okay for the two of us to output to this FileHandle at the same time? (It must, my "Run"ed commands can send their output to the master window...) >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10