Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 30 Mar 89 09:50:17 GMT References: <6275@cbmvax.UUCP> <0776.AA0776@julie> <0856.AA0856@julie> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Followup-To: comp.sys.amiga.tech Organization: RPI Public Access Workstation Lab, Troy NY Lines: 66 In-reply-to: mcr@julie.UUCP's message of 25 Mar 89 21:27:42 GMT In article <0856.AA0856@julie> mcr@julie.UUCP (Michael Richardson) writes: >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? [...] Easy... pr_CLI is an example of where the division isn't totally clean... >> 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. Ick. :-) > If you do not include hackers as unix users, then you've cut the population >of Unix users by a LARGE proportion. This be somewhat true... > 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. I don't like being told compatibility is unnecessary and you should just learn a new approach for every different system. Sorta defeats the whole purpose... [...] >The upshot of this is that programmers would have a cleaner way to >deallocate resources in an intelligent way. My intention exactly... > [...] If you like having >plenty of 300k animations around, a file system with a bigger allocation >unit is for you. Not necessarily. Why not a FS which doesn't use a fixed blocksize? > 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...) That would work, though it doesn't matter who closes it, as long as the file handle is only closed ONCE. I think sharing the file handle will share the R/W pointer, but perhaps not. "Run"ed commands send their output to the console window by opening "*" as an output stream (or being passed the same), not by sharing filehandles. There is a difference. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.