Path: utzoo!attcan!uunet!bu.edu!orc!decwrl!sdd.hp.com!hplabs!hpfcso!hpfelg!koren
From: koren@hpfelg.HP.COM (Steve Koren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ASyncRun() doesn't work with pipe:xxx!
Message-ID: <13920089@hpfelg.HP.COM>
Date: 5 Sep 90 13:31:01 GMT
References: <13920086@hpfelg.HP.COM>
Organization: HP Elec. Design Div. -FtCollins
Lines: 47

> > looked at it in detail), but rather ask Steve _why_ he won't use Conman
> > pip: device?  I find that it works well, and _is_ a real pipe c/f pipe:
> > which is just a kludge.

[Peter da Silva replies:]

> Perhaps because he's planning on distributing his program and wants to
> minimise the amount of third-party software that is needed to run it?

Exactly.  Granted, I already have dependencies on the ARP library, but
I'd like to minimize the number of such dependencies.  Tryin' my darndest
to use the CBM solution if there is one. 

  * makes it easier to explain how to run SKsh - don't have to tell people
    to hunt down and install 42 other things first

  * reduces problems should one of the things I depend upon break

  * reduces problems when people out of date versions of the other stuff

So I don't think there is anything wrong with the ARP solution per se.
I'd just rather use the C= one.  The C= pipe: seems to work fine in
other usages, so I know it is capable of doing the job.  There are
actually some advantages to named pipes over anonymous ones also
(and the reverse is true as well).

Anyhow a number of people have pointed out to me in email that ASyncRun()
closes the input filehandles itself; that is OK in this particular case
as my test program only closes them if ASyncRun() failed.  I checked that
one out.  Thanks anyway though...

Also, I should point out that this only crashes if the pipe: reader is
invoked by ASyncRun().  If the pipe reader is invoked by another
method, everything is A-OK.  But multiple statement pipelines require
multiple readers all invoked by ASyncRun().  (Someone will probably
notice that SKsh 1.4 include a limited 2-level pipeline mechanism using
real pipes - this is why it was only two levels.  The rest of the code
was in SKsh, I just couldn't get past this little problem - I had
initially thought it was an artifact of the Lattice Un*x like I/O
package, but that turned out not to be the problem).

Of course, this whole problem will neatly up and go away in 2.0.
But that means that SKsh won't run under 1.3 anymore, so I want to wait
until 2.0 is used by more people than 1.3 is before I compile with the
2.0 calls.

   - steve "waiting anxiously for 2.0..." koren