bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (02/16/88)
Funny how it just takes years to notice some things. Although I've had my hard disk for a while now and my command search path has grown accordingly, I only recently noticed that the CLI launched by popCLI doesn't inherit the 'right' path information. Since each CLI has its own path, I surmise that the CLI launched from the workbench icon gets its path from the CLI in which LoadWB was executed. Since that CLI may no longer be around, the workbench must presumably save the path somewhere. PopCLI (III), however, passes the minimal path to its CLIs. I've been getting around this problem by using popcli newcli ... from s:initcli where s:initcli rebuilds the path (and starts Matt's/Steve's shell, of course :-)). The question is, how to make popCLI remember the path of its parent CLI, and pass this to its 'children.' How does one pass environments around in AmigaDOS in general? Can you tell that, in what little time I have for programming, I avoid AmigaDOS like a Botulent can of Spam? 8-} ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___ |____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___| ___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
keithd@cadovax.UUCP (Keith Doyle) (02/19/88)
In article <10373@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: > > Funny how it just takes years to notice some things. Although I've had >my hard disk for a while now and my command search path has grown accordingly, >I only recently noticed that the CLI launched by popCLI doesn't inherit the >'right' path information. We just ran into a related problem recently. Try this: main() { Execute("cd",0L,0L); } No matter where you run this program from, the result is *always* DF0:. Even if everything has been reassigned elsewhere and there is not even a disk in drive 0. We wondered where it was getting the DF0: from, and found that it is hard coded in the CD program. It is also hard coded in the Assign program and probably a few others. What we wanted to do, was to have a program that did a: Execute("Assign foo: stuff",0L,0L); such that no matter where the program was, no matter how deeply nested into hard-disk subdirectories it might be, it will always find "stuff" relative to the current directory as percieved by the "Execute"ing program. We discovered: You can't get there from here. As far as I know, there is no way to get an Executed command to use the current programs current directory as its current directory. Or anything but DF0: for that matter. I'd like to be proven wrong. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
andy@cbmvax.UUCP (Andy Finkel) (02/23/88)
In article <1943@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <10373@ut-sally.UUCP> bryan@mothra.cs.utexas.edu writes: >> >> Funny how it just takes years to notice some things. Although I've had >>my hard disk for a while now and my command search path has grown accordingly, >>I only recently noticed that the CLI launched by popCLI doesn't inherit the >>'right' path information. > >We just ran into a related problem recently. > >Try this: > >main() >{ > Execute("cd",0L,0L); >} > >No matter where you run this program from, the result is *always* DF0:. >Even if everything has been reassigned elsewhere and there is not even >a disk in drive 0. > >We wondered where it was getting the DF0: from, and found that it is >hard coded in the CD program. It is also hard coded in the Assign program >and probably a few others. > Right problem, wrong answer. The hardcoded DF0: in CD is to deal with the situation that happens before you CD anywhere, before you have a lock on anything, ie when you've just booted. Now, the answer: Execute (which calls on the RUN program) gives you a shiny new Process to play in. This means it has no idea of where you're CD'd to. >As far as I know, there is no way to get an Executed command to use >the current programs current directory as its current directory. Or >anything but DF0: for that matter. What I generally do it one of the following, depending on what I'm doing: a) before I call Execute I make a temporary Assign to where my application program lives, and use that in the command. b) If I'm running a script file I build a CD command to my current location, and feed my script file to Execute via the input handle, while Executing the CD command c) And, you can use the + option of run to string commands together, even in an Execute statement, ie Execute("run cd+\ncd df0:l+\ncd",0,0) fine. BTW, I did try it with Execute() inheriting some things from the starting process...a lot of programs broke. The solution it to have a new, more elaborate Execute call for V1.4, I guess. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
cks@radio.toronto.edu (Chris Siebenmann) (02/24/88)
In article <1943@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: ... >We wondered where it was getting the DF0: from, and found that it is >hard coded in the CD program. It is also hard coded in the Assign program >and probably a few others. DF0: is what CD and ASSIGN have hard-coded as the name for directory lock 0, which is the root device you booted from. I suspect that Execute() is running things in a process environment with the current directory set to a 'default' value of zero. I can't imaging why it would do that; I suppose it's Yet Another Reason to use SyncRun from arp.library. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cks