🚀 go-pugleaf

On 19 Mar 90 14:16:57 GMT, peter@sugar.hackercorp.com (Peter da Silva) said:

Peter> In UNIX, you have to use several expressions:

Peter> 	_*.[ch] _*.bak ck*.[ch] ck*.bak *test*.[ch] *test*.bak

Deven> For csh users:  {_,ck,*test}*.{[ch],bak}

Deven> AmigaDOS's (x|y|z) syntax is directly analogous to csh's {x,y,z}.

Peter> No, it isn't. In most cases it can be used the same way, but
Peter> it's not identical.

Peter> The csh {,} syntax is parsed before wildcarding is done. It's
Peter> not really an alternation operator, like the Amiga (|) syntax
Peter> supports. For example, expanding {core,*.o} will produce the
Peter> string "core" whether or not there is a file matching that
Peter> pattern. This can be useful, but it's not the same thing.

That's true.  You're right there.  But, it's close enough for casual
use.

Peter> Also, as other people have pointed out, there's still no
Peter> closure operator. How about all file names of the form cx
Peter> followed by any number of digits?

Peter> 	cx#(0|1|2|3|4|5|6|7|8|9)

Can't.  But, it IS nicer to be able to use "[0-9]" instead of
"(0|1|2|3|4|5|6|7|8|9)"...

Peter> Also, of course, it's not available in scripts.

No reason why some Unix shell shouldn't allow full regexps for
globbing.  They just don't, usually.  :-)  [tradition, y'know.]

Deven> Granted, AmigaDOS wildcards are flexible and powerful, but I
Deven> find them less convenient to use than Unix wildcards, under
Deven> most circumstances.

Peter> Which is why my original message, that started this whole chain
Peter> off, suggested using UNIX wildcards interactively and the more
Peter> powerful Amiga wildcards in scripts.

Well, I'd like to be able to use Unix wildcards in scripts too, unless
I really need the closure or some such.

Peter> That suggestion, by the way, was that *all* uses of wildcards
Peter> be marked explicitly, and all arguments not marked as wildcards
Peter> not be wildcarded.  On the Amiga, for example, anything not
Peter> enclosed in parentheses would be treated literally.

I would like to be able to do "Join *.c wx#(y|z) ab#c.* to '*'" and
have it work as expected.  That is, first *.c is Unix semantics,
second wx#(x|y) is AmigaDOS semantics, third ab#c.* is a combination,
and the fourth (fifth) '*' is an escaped wildcard, so it would open
the console as * normally does for BCPL...

Peter> Anyway, Deven, get back to coding up Amigix & quit wasting time
Peter> on News. :->

News isn't as hard as debugging...   *sigh*

Well, I starting building the shared library yesterday.  Layed down
all the structure and wrote a few functions.  Used the sample.library
from the 1.3 Includes & Autodocs RKM as a guide.  Right now, the
functions in the library [and this will change] are malloc(),
calloc(), AllocMem() [not necessarily externally visible], and free().

The allocators call Exec's AllocMem for the actual block and for a
MemList block to describe it.  All memory allocated is tacked onto the
task's tc_MemEntry list, which means it will be freed by RemTask when
the task exits or if another task removes it.  The sick Unix semantic
of freeing a block of memory and still using it is supported.
Implementation is as follows.

The free() function will scan the tc_MemEntry list for a MemList with
a single block with a matching address pointer.  If it finds it, it
does a Remove() and AddHead() on it, and sets the node type to -1 as a
flag.  When any of the memory functions is called (malloc(), calloc(),
free()), it first calls a subroutine which checks the node type of the
first node in the tc_MemEntry list of the task, and if it is -1, then
it does a RemHead() and FreeEntry() on it.  If the node type is not
-1, it does nothing.  In the event on an exit, then RemTask will still
clean up the "freed" block, since it is still in the tc_MemEntry list,
and RemTask doesn't care what the node types are.

I have written these functions completely (in assembly) but I have not
tested or debugged them yet.  I still need to write other memory-
related functions, such as realloc(), ReallocMem() [a tougher one; I
may be forced to muck around in the system memory lists directly],
bcopy(), bzero(), bswap() [nonstandard perhaps, but obvious, no?] and
bcmp()...  I need to add in the SwapMem functions I wrote recently.
If I make AllocMem() externally visible as a library vector, [I
probably will] then I will add a FreeMem() to go with it.

For those sitting there thinking "Why?" -- this AllocMem is like the
malloc() in that is saves the block in the tc_MemEntry structure for
tracking, but allows a requirements argument.  The FreeMem() will
probably NOT free memory if it can't find the matching block in the
tc_MemEntry list -- might be an invitation for a "freeing memory
already freed" GURU.

Why write bcopy() when there is exec.library CopyMem()?  Because bcopy
will handle arbitrary overlapping memory blocks, which CopyMem() does
not.  [might as well deal with that issue ONCE so you can later forget
it and use bcopy without worrying about if the blocks overlap.]
Bcopy() will be be efficient.  Bzero() will simply zero a block of
memory efficiently.  bswap() will swap two blocks of memory
efficiently, arbitrarily overlapping.  Bcmp() will compare two blocks
of memory, also efficiently.  And so forth.

Then I need to deal with the I/O (fd) structure, and functions for
that, and I need to add the System Task, and _then_ I can attack
fork() itself.  Or maybe vfork() first.  I'll half-implement exec().
(Initially.)

It gets a little complex.

Deven
-- 
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2151 12th St. Apt. 4, Troy, NY 12180   Phone:  (518) 274-0327
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.