🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #9401

Re: Lattice 4.0 forkl() problem

#9401
From: Daniel S. Riley
Date: Thu, 28 Jul 1988 13:20
42 lines
2602 bytes
In article <1222@questar.QUESTAR.MN.ORG> brent@questar.QUESTAR.MN.ORG (Brent Nordquist) writes:
>I am trying to get the Lattice 4.0 forkl() function to work "as
>advertised" in the manual, to no avail.
>
>I need to be able to start up another program with its stdin redirected
>from somewhere else.  For example, the first process opens a file, sets
>the stdin of the second process to be that file descriptor, and then
>forks; then the second process, when reading from stdin, would be
>reading from the file.
>
>When I call forkl() with (struct ForkEnv *)NULL it works fine, with
>the new process inheriting stdin from the current process.  Now, the
>manual says I should also be able to pass a (struct ForkEnv *) whose
>*fields* are NULL, and any NULL field will receive a default value.
>So, I tried it, and I get the Guru.

I'd recommend filling in all the fileds if you're passing a ForkEnv at
all.  I get much more reliable results that way.

>Also, the .h file
>says they're BPTR's and not long's.  Are these 'file handles' returned
>by open(), or is this something Amiga-specific?  (Can you say, "naive-
>Amiga-programmer-used-to-mainframe-C?"  :-)

The manual also says that they are "file handles", which means that
these are AmigaDOS file handles as returned by the AmigaDOS Open()
(note capitalization) command, or Input() and Output().  You can also
use the Lattice _dopen() call, but note that (1) I believe it's _dopen,
not dopen, and (2) it returns a BPTR, not an int (the .h file says
long, which is better, but it should be BPTR).

>Perhaps forkl() isn't the best way to start up another process; can
>someone give me some help?  Short example code would be invaluable!

If you have arp, and can assume that anyone running will have arp,
you might look into AsyncRun, which I find to be a little more robust.
Otherwise, forkl() is probably the way to go (unless you want to run
BCPL commands in c:, in which case both AsyncRun and forkl will fail
miserably).

-Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-Wilson Lab, Cornell U.
Technical Details
Message-ID: <5673@batcomputer.tn.cornell.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!riley
References: <1222@questar.QUESTAR.MN.ORG>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Lattice 4.0 forkl() problem
Message-ID: <5673@batcomputer.tn.cornell.edu>
Date: 28 Jul 88 13:20:31 GMT
References: <1222@questar.QUESTAR.MN.ORG>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 42