🚀 go-pugleaf

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