🚀 go-pugleaf

This message is a status report on the next version of ash and a request
for some answers to nagging little questions I've had for a while.  Pay
special attention to ? terminated sentences.

I've received lots of good suggestions for things to add to ash.  I've
solved the problem of doing a "rm *.*" and aborting the rm when . and ..
can't be removed.  Does anyone understand why a getfirst() and getnext()
with the *.* file specification will return . and .. but using . and ..
directly as file specs fails?  

I also have I/O redirection for the built-in commands working.  One
question I have is whether or not users would prefer a distinction between
error output and standard output.  For example, if you redirect output from
a "cat" and the file isn't available for reading, the error message stating
this goes to the screen (stderr) instead of the file you directed output
to.  What do users prefer?  Unless I get strong responses the other way I'm
leaving stderr pointing at the screen.

I also have ash recursing now so that scripts will run with lots less
memory.  An added side effect is that the environment (PATH, etc.) stays
around for scripts no matter how deep they're nested (I increased the stack
to 16K and can go 9 levels with no problem).  The initialization file is
now only executed for interactive invocations of ash and can contain any
valid ash commands.  This means the ash.ini file can do some initial copies
for you to set up your working ram disk for example.

I've tried in vain to make the environment available for Pexec()ed programs
invoked by ash.  Do I hear any suggestions on this one?  What kind of
format is this environment string passed to Pexec() supposed to be in? 
I've heard conflicting specifications.  Should I be using the _shell_p
variable for something?

One last query.  Since the command tail for Pexec() uses the initial byte
as a length, and assuming they don't take negative tails into account, you
should be able to have a 255 character command tail with byte 0 of a 256
byte buffer set to 255.  It seems that tails longer than 128 don't work. 
Can anyone shed some light on this one?  Ash does wild card expansion
(except when arguments are quoted) and while the command line for built-in
commands can be up to 255 characters, I can't pass that much tail to
external commands.  As an aside, it seems the Dosound() call needs the
first byte of the command buffer to be a length also and it's documented
just as well as the Pexec() call.

Moving files (mv) will retain the current time stamp and copying files
(cp) will change the time stamp of the newly created file.  Anything else
seems silly to me but I just thought I'd mention it because there was quite
a stir about it a while back.

I have added the code to set the keyboard clock when the gemdos clock is
set but for some reason while the time is set correctly the date on the
keyboard clock is munged up.  Any hints?  This is the code I use:

	long	kbd;
	kbd = (gemdos(0x2a) << 16) + gemdos(0x2c);
	xbios(0x16,kbd);

I've also tried it with both gemdos calls cast to longs and still the date
is incorrect.  I don't have this problem with the gemdos clock.

Also, I've enabled the arrow keys to work with command history editing.  I
don't use them the same way VMS does though.  I'm used to ksh history
editing so why settle for (much) less on my ST.

I have to finish the document before I post this version.  It should be out
by the end of May.  If you can help with any of the ? above please send me
mail.

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)