🚀 go-pugleaf

> Sksh 1.4 is a great improvement: it is good enough to replace
 
> Could the UNIX << stdin redirection be implemented?

I think so, but I have to fiddle with the parser a little first; it
is currently limited to 1023 character tokens, which removes much
of the capability of <<! style redirection.  Its on my list of
enhacements though...

> Could the & be made a synonym for 'srun' or a subshell?

Yes, but I "deferred" that enhancement; I'll see if I can manage to
briefly explain why.  Running an *external* program in the background is
a piece of cake.  However, I wanted the ability to use the '&' suffix
to run *anything* in the background.  For example, this works fine
in Un*x under ksh (just a dumb example):

  ( while true
    do
       rm -f ~/.sh_history
       sleep 30
    done ) &

In that case, the shell must fork itself; the child process then
runs the subshell script in the background.  That is the problem; I'm
sure its possible to do on the Amiga, but at the moment its not at 
all obvious to me how to make the shell fork itself.  (Creating a
task, not a process, has the severe limitation that you can't do
I/O).  If I can ever figure out how to do this without a lot of work,
I'll put it in, and it will use the '&' suffix.  What I really want
is an equivilant to the Un*x fork() command (which is very different
than Lattice's forkv() call).

> How difficult is it to use the PIPE: device for simultanous
> pipes?  Steve's pipes.readme suggests that it can handle one
> such pipe at a time - is it because he is trying to use the
> same pipe: file name between three programs?

No.  I don't know why it is (yet :-).  It is trying to run the first two
programs in the background (with Arp's ASyncRun()) and the last one in
the pipeline in the foreground.  For example,

   a | b | c

runs a and b asynchronously, with c in the foreground.  However, for
some reason this crashes the machine.  You can observe this behaviour
in SKsh 1.4 if you enable real pipes as discussed in the pipes.readme
file and pipe something through three commands like that.  (Make sure
you are in a state where your machine can crash though!)  I have
very carefully watched the data going into ASyncRun and SyncRun for
all three command calls, and it looks fine to me.  If bad data was
going in I could fix it, but I'm really confused now.

> It's a great program, Steve.

Thanks!

   - steve