🚀 go-pugleaf

In article <0fsYK90nyi1010tJHM2@amdahl.uts.amdahl.com> kevin@uts.amdahl.com (Kevin Clague) writes:
>In article <261600001@trsvax> johnm@trsvax.UUCP writes:
>>I like the idea but think it needs at least one more thing.  A unix
>>compatible wildcard expansion mechanism.  With this we could build the
>>set of unix tools that so many of us would like to have on our Amigas.
>>A shell just doesn't cut it in many situations because...
>>
>>	A) Many have really annoying restrictions on what you can enter in the
>>	shell.  One of the older shells would not let you run EXECUTE under it.
>>	What a pain.
>>
>>	B) Tools don't sit there continually sucking up memory.  A shell does.
>>
>>	C) You can't replace PART of a shell.  You can replace ONE tool.
>>
>>Even if you only get partway, post what you get done.  It will be welcomed.

>I appreciate the spirit of this posting, but let's not let it get into
>a religious discussion of wildcards like the one in comp.sys.amiga.

The idea here is to make things as functionally compatible with Unix
as is reasonably possible.  The filename matching wildcard expansion
is handled by the shell, and will be, but I may put in library
routines to support it and make it easier to write different shells.
For the shell *I* write, I fully intend to implement Unix-style
wildcards (with some extensions I have in mind) AND Unix-style
pathnames.  (i.e. open("../file",...) would be internally translated
to an AmigaDOS Open("/file",...) call, while "/file" would be
translated to ":file", etc.)

Later, I'll probably implement my own file system to go along with it,
which will use the Unix syntax directly.  For now, a simple
translation and underlying calls to AmigaDOS for the actual FS
management will work.

I have some serious gripes with the Execute() function, and haven't
decided whether or not to support it.  As far as the C:Execute command
goes, I don't expect to directly support that, either; that kludge is
fairly tied to the CLI's mode of operation.  I will, however, have a
scripting language as part of the shell's functionality, and as such
will be able to do all an AmigaDOS Execute script can do and more.
Perhaps I will supply a shell script which aliases commands to make
Execute scripts run under my shell.  We'll see.

The AmigaDOS CLI is a shell.  A pathetically simple and poorly
designed shell, but it IS a shell.  And it is ALWAYS in memory, using
that space.  However, ALL the CLI's in the system use the SAME code
for their CLI, so the overhead isn't so great; probably on the order
of 10K + 1K/CLI or so...

The shell I write I expect to be generally running with a shared text
segment.  Whether or not I'll try to implement shared text segments as
part of the file system interface or not, I'm not sure.  (Probably
sooner or later, in some form.)  I expect the complexity of the shell
to be on the order of that of Unix sh or csh.  (Though not early
versions, of course.)  The shell syntax will be quite similar as well.
And many more tools, like filters and utilities, will NOT be built
into the shell.  There will be a dividing line.

Who says you can't replace PART of a shell?  That depends on what you
want to replace and how the shell is implemented...  (and you can
always change the source and recompile.)

Don't worry; I am sick of the wildcard flame wars, and they don't
belong in comp.sys.amiga.tech anyhow.  _I_ am implementing this, so it
will be implemented _my_ way.  The coder's rule: he who writes the
code makes the rules.

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.