Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Getting the current directory

0 views
Skip to first unread message

M Gordon

unread,
Aug 5, 1991, 9:18:17 AM8/5/91
to
Is there an approved way for a process to get its current directory?

At the moment I'm doing a FindTask(NULL) to find the process structure,
following the pr_CLI pointer in that to find the CommandLineInterface
structure and examining the cli_SetName member. This works but seems
an extremely nasty way of doing things.

Any suggestions or pointers to the right bit of TFM appreciated.


--
_ _ _ _ _
Michael Gordon - m...@castle.ed.ac.uk OR ee.ed.ac.uk | |_| |_| |__| |_| |
| . . . . . . |
It's not an optical illusion, it just looks like one |_________|~~|_____|

Eddy Carroll

unread,
Aug 5, 1991, 2:07:45 PM8/5/91
to
In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
>Is there an approved way for a process to get its current directory?
>
>At the moment I'm doing a FindTask(NULL) to find the process structure,
>following the pr_CLI pointer in that to find the CommandLineInterface
>structure and examining the cli_SetName member. This works but seems
>an extremely nasty way of doing things.
> _ _ _ _ _
>Michael Gordon - m...@castle.ed.ac.uk OR ee.ed.ac.uk | |_| |_| |__| |_| |

The following should give you a lock on the current directory in DirLock.

BPTR templock, dirlock;

templock = CurrentDir(0);
dirlock = DupLock(templock);
CurrentDir(templock);

Don't forget to UnLock(dirlock) when you're finished with it. If you're
really looking for the text name of the current directory, then you have
to walk backwards from dirlock, calling Examine() and ParentDir() until
ParentDir() returns NULL, building up the path one step at a time.

Eddy
--
Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until
ADSPnet: cbmuk!cbmuka!quartz!ecarroll | you've died in MUD!"
Internet: ecar...@maths.tcd.ie | -- Richard Bartle

Olaf'Rhialto'Seibert

unread,
Aug 5, 1991, 9:58:11 PM8/5/91
to
In article <1991Aug5.1...@maths.tcd.ie> ecar...@maths.tcd.ie (Eddy Carroll) writes:
>The following should give you a lock on the current directory in DirLock.
The following is even simpler:

> BPTR dirlock;

dirlock = Lock("", SHARED_LOCK);

but I don't exactly recall if this is required to work if you have a
(BPTR)0 current directory.

>Don't forget to UnLock(dirlock) when you're finished with it.

-Olaf.
--
Olaf 'Rhialto' Seibert rhi...@cs.kun.nl
How can you be so stupid if you're identical to me? -Robert Silverberg

Jeff Dickson

unread,
Aug 6, 1991, 12:31:46 PM8/6/91
to
In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
The current directory lock is stored in the pr_CurrentDir field of
the process structure. Send an ACTION_COPY_DIR DOS packet to the message
port identified within the lock as fl_Port with DOS argument 1 (I think)
set to the lock (pr_CurrentDir) you want a shared copy of. The value stored
in the pr_CurrentDir field is a BPTR, so you'll have to converted it to C
before dereferencing it.

-jeff

Walter Mildenberger

unread,
Aug 6, 1991, 7:43:25 PM8/6/91
to
In article <1991Aug5.1...@maths.tcd.ie>,

|>ecar...@maths.tcd.ie (Eddy Carroll) writes:
|>In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
|>>Is there an approved way for a process to get its current directory?
|>>
|>>At the moment I'm doing a FindTask(NULL) to find the process structure,
|>>following the pr_CLI pointer in that to find the CommandLineInterface
|>>structure and examining the cli_SetName member. This works but seems
|>>an extremely nasty way of doing things.
|>
|>The following should give you a lock on the current directory in DirLock.
|>
|> BPTR templock, dirlock;
|>
|> templock = CurrentDir(0);
|> dirlock = DupLock(templock);
|> CurrentDir(templock);
|>
|>Don't forget to UnLock(dirlock) when you're finished with it. If you're
|>really looking for the text name of the current directory, then you have
|>to walk backwards from dirlock, calling Examine() and ParentDir() until
|>ParentDir() returns NULL, building up the path one step at a time.

Er, why do people always reinvent the wheel ?

Just let the c.lib do the hard work! Try:

int error;
char path[128];
error = getcd(0,path);

or int error
char *path;
path = getcwd(path,128);
[...]
if(path) free(path);

(At least SAS/C has them ...)

Regards
--
Walter Mildenberger, Morgenstr. 55, W-7500 Karlsruhe 1,FRG, (0721)385090
Sub/UseNet: wa...@chumly.ka.sub.org -or- Bitnet: UK...@DKAUNI2.Bitnet
Goethe ist tot, Einstein ist tot, und ich fuehl mich auch schon ganz schlecht!

Jeff Dickson

unread,
Aug 7, 1991, 1:21:51 PM8/7/91
to
In article <b89...@chumly.ka.sub.org> wa...@chumly.ka.sub.org (Walter Mildenberger) writes:
>In article <1991Aug5.1...@maths.tcd.ie>,
>|>ecar...@maths.tcd.ie (Eddy Carroll) writes:
>|>In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
>|>>Is there an approved way for a process to get its current directory?
>|>>
>Er, why do people always reinvent the wheel ?
>
> Just let the c.lib do the hard work! Try:
>
I'll tell you why people reinvent the wheel. Some of us (i.e. me) can
produce smaller, tighter code when we do something on our own. The standard
C library routines can be bulky and CPU wasteful. For instance, some C lib-
raries offer a function to send an AmigaDOS packet. The way they're done,
at least in my C library, is that it has to build an AmigaDOS packet each
time it is to send one. But of course, if you write your own, you can pass
the AmigaDOS packet structure as an argument or better yet - know it as global.
Also, in some instances the DOS library cannot be used (i.e. from tasks).
Bet the C library makes avid use of DOS library.

-jeff

Frank J. Edwards

unread,
Aug 7, 1991, 10:51:37 AM8/7/91
to
In article <1991Aug6.1...@jato.jpl.nasa.gov> jdic...@jato.Jpl.Nasa.Gov (Jeff Dickson) writes:
>In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
>>Is there an approved way for a process to get its current directory?
>>--
>>Michael Gordon - m...@castle.ed.ac.uk OR ee.ed.ac.uk | |_| |_| |__| |_| |
>
> The current directory lock is stored in the pr_CurrentDir field of
>the process structure. Send an ACTION_COPY_DIR DOS packet to the message
>port identified within the lock as fl_Port with DOS argument 1 (I think)
>set to the lock (pr_CurrentDir) you want a shared copy of. The value stored
>in the pr_CurrentDir field is a BPTR, so you'll have to converted it to C
>before dereferencing it.
>-jeff

And once you've got the lock, you can use NameFromLock() under 2.0 to get
the pathname of the lock'd object.

Now that I think about it, I imagine this doesn't work reliably for HARD
links or SYMBOLIC links... Although you *will* get a pathname back (the
block on disk has back-pointers to parent directories in it) it might not
be the same as you started with (!) Hmmm, that's interesting. I wonder
how I could use that "feature" in my next program!! ;-) ;-) ;-) ;-)
--
Frank J. Edwards | "I did make up my own mind -- there
2677 Arjay Court | simply WASN'T ANY OTHER choice!"
Palm Harbor, FL 34684-4505 | -- Me
Phone (813) 786-3675 (voice) | Only Amiga Makes It Possible...

Walter Mildenberger

unread,
Aug 7, 1991, 7:20:01 AM8/7/91
to
In article <b89...@chumly.ka.sub.org>, I wrote:
[...]

or int error
char *path;

Oops, there was a NULL missing !
char *path = NULL;

path = getcwd(path,128);
[...]
if(path) free(path);

Regards

Walter Mildenberger

unread,
Aug 8, 1991, 1:55:59 PM8/8/91
to
In article <1991Aug7.1...@jato.jpl.nasa.gov>,

jdic...@jato.jpl.nasa.gov (Jeff Dickson) writes:
In article <b89...@chumly.ka.sub.org> wa...@chumly.ka.sub.org (Walter Mildenberger) writes:
>In article <1991Aug5.1...@maths.tcd.ie>,
>|>ecar...@maths.tcd.ie (Eddy Carroll) writes:
>|>In article <12...@castle.ed.ac.uk> m...@castle.ed.ac.uk (M Gordon) writes:
>|>>Is there an approved way for a process to get its current directory?
>|>>
>Er, why do people always reinvent the wheel ?
>
> Just let the c.lib do the hard work! Try:

I'll tell you why people reinvent the wheel. Some of us (i.e. me) can
produce smaller, tighter code when we do something on our own.

Sure ! But this is an argument pro Assembly :-)

And <almost> every argument contra assembly applies here also ;-)

The standard C library routines can be bulky and CPU wasteful.

CAN BE, not HAVE TO ...

For instance, some C libraries offer a function to send an AmigaDOS packet.


The way they're done, at least in my C library, is that it has to build an
AmigaDOS packet each time it is to send one. But of course, if you write your
own, you can pass the AmigaDOS packet structure as an argument or better yet -
know it as global.

Well, if you want to use the packets etc. more often, you are right, but if
you really want to get the problem solved without hazzle, the clib often
gives you an easy solution.
Unfortunately not everytime: I'm really frustrated that I have to deal with
devices, SendIO, Wait() and.friends only to have a timeout-option which
normally would be implemented via signal() and alarm() !

Also, in some instances the DOS library cannot be used (i.e. from tasks).
Bet the C library makes avid use of DOS library.

You are kidding, aren't you ? This guy asked how to get a CurrentDir - don't
you think DOS is involved in this problem in one way or the other ? :-)))

And the not-dos clib-functions doesn't use dos.library at all.

0 new messages