Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Unix V7 functionality under (or along with) AmigaDOS?  (*LONG*)
Keywords: Workbench Shells Exceptions
Message-ID: <6420@cbmvax.UUCP>
Date: 29 Mar 89 02:10:29 GMT
References: <6275@cbmvax.UUCP> <DEVEN.89Mar6082649@daniel.pawl.rpi.edu> <0776.AA0776@julie> <0856.AA0856@julie>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 79

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? 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.

	As I said it isn't clean - some things in the CLI structure are accessed
directly, instead of through function calls.  What it means is that to be
compatible one must either maintain reasonable values in the CLI structure
from your shell, or look like WB to the program (WBMessage, etc).

>>        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.

	What I meant is that for almost all people who use unix the fact that
a shell is "just another program" isn't important, only the features are
important.  I meant that few people write shells, even hackers.

>>        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.

	Note the "get used to it".  Also note that we are not the people I
was refering to: I was refering to the generic user who buys an amiga, and
in general is not horribly computer-literate to begin with, or is only slightly
literate in one of msdos/C64/mac/Apple-II/ST/etc.  You know, _users_.

>>>  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?

	I assumed that he was talking about the packet interface to handlers.
Packets are documented and supported (even if the documentation is not
perfect, it's usable).

>>>  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?

	You misunderstand.  We're talking exec messages, sent from the shell
to processes that execute programs for the shell.

>>        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...)

	Within limits stated before: BCPL programs can't share filehandles.
NEVER Close() the result of Output().  Don't pass it off and exit, wait until
the other process is done with it.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup