dewi@druca.UUCP (WilliamsD) (02/20/86)
I'd like to bring up an issue that was discussed some time back -- finding the current directory under AmigaDOS. As I remember it, the consensus was that passing a null string would work. Looking at some PD C programs that do "ls" style things, this seems to be what everybody does. There's only one problem, though -- this doesn't work on the RAM disk! This is what happens: 1> cd df0:/s 1> cd "" 1> cd df0:/s 1> cd ram:c 1> cd "" Can't find I'm waiting for my Manx C compiler to arrive and only have the assembler package to play with at the moment (with no ROM Kernel docs yet!) so the scope of my experimentation is limited -- especially with the worthless assembler package documentation (I seem to have purchased a debugger called romWack but it's not mentioned anywhere!). Some of the data structures in libraries/dosextens.i seem to hold a lock on the current directory (from memory, there's a field called pr_Currentdir or somesuch). The only problem is getting at it -- does anybody know if DeviceProc can return info on the *calling process* ? How about putting a GetCurrentDir() call into the dos library in the next release -- trying to figure it out by relying on side effects is kind of silly. Dewi Williams ..!ihnp4!druca!dewi -- ---------------------------------------------------------------------- Dewi Williams. uucp: ..!ihnp4!druca!dewi phone: (303) 538 4884
robp@amiga.UUCP (Robert A. Peck) (02/26/86)
In response to questions about:
cd something
cd ""
cd
cd ram:something
cd ""
cd
FIRST, an answer:
YES, there is a bug in the RAM: handler that will not execute
the ParentDir command correctly. The bug exists in version 1.0
and 1.1, ... wasnt found till 1.1, and is being fixed now.
Also, the null-string handling of the 'cd' command is different
when executed from df0:anything or from ram:. Again this is
being addressed for the next release.
The only proper workaround for RAM: files is to proceed down
from the top, rather than up from the bottom. Sorry.
Re other questions about the current directory.... here are some tidbits
for your consideration. The items shown here are described in the
AmigaDOS Developers' Manual, though do not include this sample code.
The current directory under AmigaDOS can be found by one of several different
means, not always relying on side effects.
Here are three different methods, all of which yield the same result, that is,
the value of the lock on the current directory. The difference between the
first one and the other two is that the first one provides the lock value
but does not actually lock the directory itself, thus is less desireable.
NOTE: CODE FRAGMENTS, NOT NECESSARILY COMPLETE EXAMPLES
/* doesnt_lock.c */
#include "libraries/dosextens.h"
extern struct Task *FindTask();
struct Lock *cdlockvalue; /* actually is a BPTR */
struct Process *myprocess;
myprocess = (struct Process *)FindTask(0); /* where is my own
* process control
* block? */
cdlockvalue = (struct Lock *)myprocess->pr_CurrentDir;
fragment? #2:
/* GetCurrentDir.c */
#include "libraries/dosextens.h"
struct Lock *GetCurrentDir()
{
struct Lock *oldlock, *currentlock;
/* make the root directory the current one, returns a lock to
* the current directory that you were in before */
currentlock = CurrentDir(0);
/* now you can use this value for anything that a lock can
* do, such as Examine and so on.
*/
rootlock = CurrentDir(currentlock);
/* change back to the current directory again, getting the
* lock value on the root as you do so. (side effect). Notice
* that this side effect is appropriate when moving around in a
* hierarchical file system.
*/
Unlock(rootlock); /* undo the side effect */
return(currentlock);
}
/* notice that you have to Unlock() the value you receive
* when you are finished with it.
*/
fragment? #3
#define GetCurrentDir() {(struct Lock *)Lock("",ACCESS_READ)}
struct Lock *currentlock;
currentlock = GetCurrentDir();
/* again, unlock whatever you lock */
and thats about all there is to it.