Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!hplabs!hpfcso!hpfelg!koren
From: koren@hpfelg.HP.COM (Steve Koren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: SKsh weirdness
Message-ID: <13920046@hpfelg.HP.COM>
Date: 13 Feb 90 15:23:26 GMT
References: <02152.AA02152@thekeep.UUCP>
Organization: HP Elec. Design Div. -FtCollins
Lines: 85

> >I figured it was about time to upgrade from Matt's Csh 3.02
> >to Steve's SKsh 1.2 --- and a look at the manual to SKsh 1.2
                   ~~~
First off, try 1.3 (which is the newest, and will continue to be
for another month or two yet).

> >dmail and matt's UUCP stuff to be exact.  Guru'd the machine 
> >right away.  Postnews worked, but most other UUCP utils blew
> >the machine away.  The utils that DID work, didn't seem to inherit

Make sure you have the latest arp.library (mine is 17100 bytes).  If
you have an old arp, there are several known problems with command
invocation.  Also, try giving it boatloads of stack.

> >the command path of the shell.

Use c:path to set whatever path you want external binaries to see.

> >Second problem: some software, like setenv, required an EXTRA <return>
> >to make the command complete, and they rarely thought they had the

>        o I get Guru #3's when I start up certain C programs without any 
>          arguments (Lattice Make Utility, for example).

Hmmm.  Lets see if I can manage to explain this in a way that makes
sense.  Way back in the early days of SKsh (which used to be called Ash),
I had planned to use the "normal" AmigaDos method of executing
applications.  Well, it turned out that there *is* no normal method.  The
supplied Execute() function has many problems the prevented me from
using it *at all*.  One day I stumbled across Arp, and Arp provided a
clean interface to command invocation (you pass it a string to execute
and some input and output handles).  Since that was the only procedural
interface available, it is what I used - SKsh builds the string to
execute, and simply gives the string to Arp.

The problems you report are all caused by the arp SyncRun function, since
SKsh doesn't deal with command invocation itself.  Of course, they
are not Arp's fault, really - one has to go through incredible
gymnastics to execute a program on the Amiga, and there are many
special cases to consider (BCPL vs Lattice vs Manx vs programs compiled
on Tuesdays after 3pm, etc).  Arp did a great job (considering what they
had to work with), but there are a few cases that it doesn't handle.

If and when Commodore supplies a clean *procedural interface* to
a command execution function, I will glady remove the arp mechanism
from SKsh and use the supported Commodore solution.  In the meantime,
there is unfortunately not much I can do, since the problems lie outside
of SKsh's little world.

In other words, its not my fault! really!  :-)

> I suppose when I get finished setting it up I should report these to Steve.

He knows :-)   (but feel free to report them anyhow; I keep counts of
which problems are reported (directly to me) how often, and assign
priorities accordingly).

Brief note to Commodore, if they're listening:

I think that we need something like this:

    result_code = ExecProgram( char *command_line,
                               struct FileHandle *input_fh,
                               struct FileHandle *output_fh,
                               int stack,
                               int priority,
                               int background_flag,
                               whatever_else_is_needed
                             );

It should work with *all* programs, and not require the programmer
to mess around loading stuff into registers and dealing with
segment lists and different program types.  Pleeeeese???  And
while we're discussing wish lists, can I have a fork() command (the
real thing, not the Lattice forkv() stuff) so I can say:

      if (fork() == 0) {
         /* here's the child process */
      } else {
         /* here's the parent process */
      }

Those two things would keep me happy for a long time :-)

        - steve