850031m@aucs.uucp (Ross MacGregor) (02/27/90)
Im using version 39.1 of the ARP library and Aztec 3.6a to spawn a
WB style process using ASyncRun().
The problem is, whatever I try, it returns -11. The include file says
it "/* Couldn't get stdio handles". What does this mean?
I don't care to have stdio handles, thats why I tried
pcb.pcb_Control=PRF_SAVEIO|PRF_NOCLI
Then tried
pcb.pcb_Control=NULL
And ASyncRun was still returning -11! Anybody know how to use this call?
--
Ross MacGregor | " Elvis Lives - I
E-mail: 850031m@AcadiaU.CA | heard him on the
UUCP: {uunet|watmath|utai}!cs.dal.ca!aucs!850031m | radio yesterday" 850031m@aucs.uucp (Ross MacGregor) (02/27/90)
Please Ignore my last posting concerning ASyncRun().
Seems I was passing it the PCB incorrectly :-(.
It's been one of those weekends :-).
--
Ross MacGregor | " Elvis Lives - I
E-mail: 850031m@AcadiaU.CA | heard him on the
UUCP: {uunet|watmath|utai}!cs.dal.ca!aucs!850031m | radio yesterday" koren@hpfelg.HP.COM (Steve Koren) (09/02/90)
Here's a question for all you tech types.
Why doesn't Arp's ASyncRun() call like AmigaDos pipes?
I've include a short program at the end of this note. The program simply
runs two programs in the background. The standard output of the
first one goes to a file named by argv[1], and the standard input of
the second one comes from a file named argv[2]. Note that the program
wants you to have certain files in ram:.
Consider this. I run the program as:
mytest ram:out1 ram:in1
where ram:in1 exists. This is like saying, in Un*x:
wc blah >out1 &
cat <in1 &
Everything works OK. Both programs are run
in the background. The stdout of the first one goes to ram:out1, and
the standard input of the second one comes from ram:in1, just as
we expect. We can run it as many times in a row as we want and
everything works: thus, the programs are being invoked correctly.
Now, lets run it again as:
mytest pipe:a pipe:a
this is like saying:
wc blah >pipe:a &
cat <pipe:a &
or,
wc blah | cat &
But IT CRASHES THE MACHINE! Why???
Firstly, it is not a problem in the program itself. I can create a small
program that uses ASyncRun() to invoke just one program in the background.
I run this program twice in a row, once sending output to pipe:b and
once getting input from pipe:b, and it crashes in the same way. This
other program is very short and I am sure it is correct.
However, if I use the AmigaDos run command to invoke the programs, pipes
are handled fine. Furthermore, if I use ASyncRun() to invoke the first
program, and run the second one in the foreground, everything is again
fine. Even running the first with ASyncRun() and running the second
with AmigaDos run works fine.
Why doesn't ASyncRun() like to be run twice with pipe:a as output from
the first and input to the second?
Whatever this problem is, it is effectively stopping real pipes from
ever appearing in SKsh. I will not use conman pipes, and in AmigaDos
1.3 ASyncRun() is the only practical means of executing commands in
the background. I don't want to wait for 2.0 to get real pipes
working, but I might have to.
Anybody have a clue?
- steve
------------------------------------------------------------------------
#include <proto/all.h>
#include <proto/Arp_Proto.h>
#include <ArpBase.h>
#include <libraries/dos.h>
#include <libraries/dosextens.h>
struct ArpBase *ArpBase = NULL;
struct ProcessControlBlock pcb;
long main(argc, argv)
int argc;
char *argv[];
{
long rc = 0, stack = 4000, pri = 0;
/* open arp */
if (ArpBase == NULL)
if ((ArpBase = (struct Arpbase *)
OpenLibrary("arp.library", 0L)) == NULL)
exit(2);
pcb.pcb_Input = NULL;
pcb.pcb_Output = (BPTR)Open(argv[1], MODE_NEWFILE);
pcb.pcb_StackSize = stack;
pcb.pcb_Pri = pri;
if ((rc = ASyncRun("ram:wc", "ram:blah", &pcb)) < 0) {
Printf("%s: unable to execute %s\n", BaseName(argv[0]), "ram:wc");
goto Done;
}
pcb.pcb_Input = (BPTR)Open(argv[2], MODE_OLDFILE);
pcb.pcb_Output = NULL;
if ((rc = ASyncRun("ram:cat", "", &pcb)) < 0) {
Printf("%s: unable to execute %s\n", BaseName(argv[0]), "ram:cat");
goto Done;
}
Done:
if (rc <= 0) {
if (pcb.pcb_Input) Close(pcb.pcb_Input);
if (pcb.pcb_Output) Close(pcb.pcb_Output);
}
CloseLibrary((void *)ArpBase);
return(rc);
}
aduncan@rhea.trl.oz.au (Allan Duncan) (09/04/90)
From article <13920086@hpfelg.HP.COM>, by koren@hpfelg.HP.COM (Steve Koren): > > Here's a question for all you tech types. > > Why doesn't Arp's ASyncRun() call like AmigaDos pipes? ... > Whatever this problem is, it is effectively stopping real pipes from > ever appearing in SKsh. I will not use conman pipes, and in AmigaDos > 1.3 ASyncRun() is the only practical means of executing commands in > the background. I don't want to wait for 2.0 to get real pipes > working, but I might have to. I won't try and answer the original question (in part 'cause I haven't 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. Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
peter@sugar.hackercorp.com (Peter da Silva) (09/04/90)
In article <2156@trlluna.trl.oz> aduncan@rhea.trl.oz.au (Allan Duncan) writes: > I won't try and answer the original question (in part 'cause I haven't > 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. 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? That's one of the reasons I avoid ARP myself, actually. The other being that I just don't trust it. (boy, is it going to be tough avoiding 2.0 though...) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
koren@hpfelg.HP.COM (Steve Koren) (09/05/90)
> > 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
w-stephm@microsoft.UUCP (Stephan MUELLER) (09/06/90)
In article <6516@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: %In article <2156@trlluna.trl.oz> aduncan@rhea.trl.oz.au (Allan Duncan) writes: %> I won't try and answer the original question (in part 'cause I haven't %> 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. % %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? Hmmm. Personally, I'd really like to see SKsh use ConMan's PIP: device. To minimise the amount of third-party software *needed* to run it, Steve could use PIP: if it's there, and not provide pipes if not. Seems better than the current situation to me. I'm not sure offhand what the distribution restrictions on ConMan are, but maybe Bill Hawes wouldn't mind ConMan being distributed with SKsh. This may not be the case seeing as SKsh could be considered competition for WShell, but has anyone asked? Not using robust, complete, useful, easily obtainable software because it's third-party seems silly to me. Of course, all of this is just based on the above conjecture. If this is not the reason Steve isn't using PIP: in SKsh, I'd like to hear what it is. %That's one of the reasons I avoid ARP myself, actually. The other being %that I just don't trust it. %Peter da Silva. `-_-' %<peter@sugar.hackercorp.com>. Dunno what there is not to trust about ARP. The ARP stuff has always worked better for me than the stock CBM stuff. The amount of software using the arp.library has made it a defacto standard, and a fairly good one at that. ARP's not perfect, but it's better than what it replaced. Seems like you're shortchanging yourself Peter. stephan(opinions mine alone); uunet!watmath!watcsc!stephan don't reply to w-stephm@microsoft, the account vanishes soon
peter@sugar.hackercorp.com (Peter da Silva) (09/06/90)
In article <57200@microsoft.UUCP> w-stephm@microsoft.UUCP (Stephan MUELLER) writes: > Hmmm. Personally, I'd really like to see SKsh use ConMan's PIP: device. > To minimise the amount of third-party software *needed* to run it, Steve > could use PIP: if it's there, and not provide pipes if not. Which is pretty silly considering there's plenty of amiga-normal pipes out there. They're not as nice as one with a real "pipe:" call, but generating a unique file name is just not that hard. > %That's one of the reasons I avoid ARP myself, actually. The other being > %that I just don't trust it. > Dunno what there is not to trust about ARP. Every time I've switched to ARP I've run into problems, either because of limitations in ARP or incompatibilities. What I'd do is install ARP, then swap back to AmigaDOS whenever I ran into a problem. After a while I found that a good deal of my C: directory was back to DOS. Plus, they early on decided on gratuitous incompatibilities (such as wildcards) which makes it hard to use ARP in an Amiga environment. Plus, it's in assembly. I would rather put up with a bit of code bloat and minimise the amount of assembly used in the system. Yes, I'd rather BCPL to assembly. Why? Because that's where most of the bugs are. Finally, ARP doesn't (or didn't, I haven't looked at the last couple of releases) come with source. So I can't fix it. > The ARP stuff has always > worked better for me than the stock CBM stuff. Not me (see above). If it works for you, good. > The amount of software > using the arp.library has made it a defacto standard, and a fairly good one > at that. ARP's not perfect, but it's better than what it replaced. If it's so good, why hasn't Commodore picked it up? They've never been shy about borrowing good software: Commodities Exchange and AREXX are standard with 2.0, in 1.3 has some of Dillon's stuff. > Seems like you're shortchanging yourself Peter. If I hadn't tried it, you'd probably be right. I tried it and I didn't like it. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jeh@sisd.kodak.com (Ed Hanway) (09/07/90)
peter@sugar.hackercorp.com (Peter da Silva) writes: >Every time I've switched to ARP I've run into problems, either because of >limitations in ARP or incompatibilities. What I'd do is install ARP, then >swap back to AmigaDOS whenever I ran into a problem. After a while I found >that a good deal of my C: directory was back to DOS. Is it really necessary to "switch" to ARP to run programs like sksh? All that they really require is the 17100 byte arp.library, not all of the replacement commands in C:. Like sksh, I needed to push data through pipes in the background in HamLab, and like Steve, I settled on PIPE: and AsyncRun(). I would have preferred to avoid arp.library completely, but it offers about the only reliable method of running processes asynchronously short of 2.0. I was pleasantly surprised to find that ARP 1.3 AsyncRun() apparently works under 2.0, so I don't regret the decision. Fortunately, I only use AsyncRun() for the pipe: writer, so I haven't run into the problems that Steve has. Ed Hanway uunet!sisd!jeh
peter@sugar.hackercorp.com (Peter da Silva) (09/08/90)
In article <1990Sep6.201155.22739@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes: > peter@sugar.hackercorp.com (Peter da Silva) writes: > >Every time I've switched to ARP I've run into problems... > Is it really necessary to "switch" to ARP to run programs like sksh? No, but after past experience I am extremely loath to trust it. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
d6b@psuecl.bitnet (09/09/90)
.com> Organization: Engineering Computer Lab, Pennsylvania State University Lines: 23 In article <6528@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > > Plus, it's in assembly. I would rather put up with a bit of code bloat and > minimise the amount of assembly used in the system. Yes, I'd rather BCPL to > assembly. Why? Because that's where most of the bugs are. Wrong. Exec, the only major part of the OS to be written completely in assembly (aside from the device drivers) has proven to be the most bug-free, by far. > Finally, ARP doesn't (or didn't, I haven't looked at the last couple of > releases) come with source. So I can't fix it. How many of Commodore's OS releases came with source? How many commercial products come with source? Of course they *should* come with source, but they don't. This isn't a peculiar feature of ARP. Actually, I have yet to hear an argument for not including (for an added charge, of course) source code with a product that makes any sense. IMHO they are just throwing away money, because a lot of people would be willing to pay twice the usual price (perhaps more) to get the source code too. -- Dan Babcock
thyssen@batserver.cs.uq.oz.au (Anthony Thyssen) (09/10/90)
First of all let me say - I am not a SKsh user but a ARP shell user
which I find does the job admariablly. I am using the newcon: handler for
all my shell windows to provide history etc.
The thing is I also have conman mounted to provide the PIP: device
used by the ARP shell! I would love a version of conman which only
contains the PIP: device and none of the other console handling stuff
it provides and that I never use.
Can anyone help?
Anthony Thyssen - (Dragon Computing!) thyssen@batserver.cs.uq.oz.au
-------------------------------------------------------------------------------
Think of it as `Evolution in Action'! -- Larry Niven
-------------------------------------------------------------------------------peter@sugar.hackercorp.com (Peter da Silva) (09/10/90)
In article <20573.26e8ef86@psuecl.bitnet> d6b@psuecl.bitnet writes: > In article <6528@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > > Yes, I'd rather BCPL to > > assembly. Why? Because that's where most of the bugs are. > Wrong. Exec, the only major part of the OS to be written completely in > assembly (aside from the device drivers) has proven to be the most bug-free, > by far. A single counterexample proves nothing. Let's consider the device drivers. Even in 2.0 there are (reportedly) bugs in trackdisk.device. What in the original O/S was neither (a) in Assembly, nor (b) ported from Tripos? > > Finally, ARP doesn't (or didn't, I haven't looked at the last couple of > > releases) come with source. So I can't fix it. > How many of Commodore's OS releases came with source? (a) They're not as broken (in some cases by definition, since the bugs were things like incompatibilities). (b) There wasn't an alternative. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) (09/11/90)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ASyncRun() doesn't work with pipe:xxx!
Summary:
Expires:
References: <13920086@hpfelg.HP.COM> <2156@trlluna.trl.oz> <6516@sugar.hackercorp.com> <57200@microsoft.UUCP> <6528@sugar.hackercorp <20573.26e8ef86@psuecl.bitnet>
Sender:
Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson)
Followup-To:
Distribution:
Organization: Jet Propulsion Laboratory, Pasadena, CA
Keywords:
d6b@psuecl.bitnet writes:
How many of Commodore's OS releases came with source? How many commercial
products come with source? Of course they *should* come with source, but
they don't. This isn't a peculiar feature of ARP. Actually, I have yet
to hear an argument for not including (for an added charge, of course)
source code with a product that makes any sense. IMHO they are just
throwing away money, because a lot of people would be willing to pay
twice the usual price (perhaps more) to get the source code too.
---------------------
I strongly disagree with the notion that commercial software products
should come with the source. Virtually all about the program that would be
evident through the source code (ideas, methods, algorithms, concepts, etc)
are not copyrightable. The copyright laws governing software are very relaxed.
For heaven sakes - you can only copyright the dam text! Plus, the CopyRight
people say that they presently do not hunt through previously submitted works
for a possible clone. All that someone else would have to do is perhaps just
change the wording and possibly rearrange the code a little bit - and as far
as copyrights go - it'd be theirs!
I take my hat off (I don't wear one, but if I did...) to persons like
Matt Dillon who do freely distribute the source. I can't and won't do that
and obviouly neither will alot of other persons.
Jeffkoren@hpfelg.HP.COM (Steve Koren) (09/13/90)
> products come with source? Of course they *should* come with source, but > they don't. This isn't a peculiar feature of ARP. Actually, I have yet > to hear an argument for not including (for an added charge, of course) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > source code with a product that makes any sense. IMHO they are just ^^^^^^^^^^^ > throwing away money, because a lot of people would be willing to pay For commercial products I can see many arguments for not including source code. However, I think there are still several for FD (freely distributable, which is not = to PD) software. The reasons I have not and will not publicly release source code to SKsh until the "last" release are: * As soon as I do, modified versions will show up and be distributed. Some of these will be fine, likely better than the original. Some will introduce bugs and break things that currently work right. It is the second class that I'm worried about, as 1) you can bet that people will call me when the modified versions break, even if someone else introduced the bug, and 2) they still have my name on them, and someone running a modified version which does something traumatic will likely avoid any future versions, even unmodified ones. If I had an infinite amount of time to dedicate to the project (and others like it), I would be more inclined to release source right away. * I need to do alot of work yet to remove system specific dependancies from the code. For example, the test scripts currently assume that certain things are in certain directories. This is true for my system but not in general. These things need to be hunted down, eliminated, and then tested on a system which doesn't "look" like mine before I can release the source. This would require *alot* of time and energy which I don't have right now. * The source code is currently nearly 23000 lines spread across multiple directories. As such, it is very complex, and since only one person wrote it in the first place, others are not likely to forsee strange problems which might crop up with certain changes. There are test scripts which try to guarantee a certain level of robustness and upward compatibility, but I can guarantee, with 100% certainty, that some people will not run the test scripts before releasing another version. Thus noncompibilities would be introduced between multiple parallel versions, which is an ugly problem if I want to release subsequent versions. (It is actually an ugly problem anyway, but if I say "this is the last version from me", I can also say, "you're on your own with custom modified versions). I can guarantee a similar thing for documentation updates, keeping the Check?.? scripts up to date, etc. There are many "grunt-work" tasks to be done which are not fun at all, but must be done to give the software a quality feel. My solution to these, and other similar problems is to simply not give out the source code until I think I am *done* with the project. Even though the software is free, I would for the moment like to retain a certain amount of control over what happens to it. Giving away the source also gives away this control to a certain extent. I'm sure other people who release FD software with no source have similar thoughts. I hope this doesn't seem like an unreasonable philosophy! I would like very much to give my software a "professional" feel. There are certainly problems with it (for example, it doesn't currently run on 3000's for an unknown reason). But I think I can, for the moment, keep the quality higher with this policy. - steve (koren@hpfela.HP.COM)