www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - getcwd behaves inconsistent?

reply "Stephen Jones" <siwenjo gmail.com> writes:
I recently switched from Eclipse to monoD and found that all my 
code to images etc was invalid because getcwd returns the 
directory that contains the main entry code in Eclipse, but 
returns the directory that contains the executable in 
MonoDevelop. Is there a universally consistent way of accessing 
files?
Jun 17 2012
next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On Jun 17, 2012 6:42 PM, "Stephen Jones" <siwenjo gmail.com> wrote:

 I recently switched from Eclipse to monoD and found that all my code to


images etc was invalid because getcwd returns the directory that contains
the main entry code in Eclipse, but returns the directory that contains the
executable in MonoDevelop. Is there a universally consistent way of
accessing files?

This depends on the directory your executable is run in.  I don't know off
the top of my head but I'm sure there is a setting.  Look in run settings
for something along the lines of execution directory.  Set it to the
directory you want.
Jun 17 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 18, 2012 00:38:59 Stephen Jones wrote:

 I recently switched from Eclipse to monoD and found that all my
 code to images etc was invalid because getcwd returns the
 directory that contains the main entry code in Eclipse, but
 returns the directory that contains the executable in
 MonoDevelop. Is there a universally consistent way of accessing
 files?


Yeah. They're called absolute paths and knowing where on the box the files are 
that you need to mess with.

But the reason that you're running into problems is that your IDEs are running 
your programe from different places. getcwd returns the current working 
directory, so if you don't change the directory while your program is running, 
it'l be where the program was started from. And if your IDE is controlling 
that, then you're going to have to figure out how to tell it start the program 
from where you wanted it started from,  which means finding the appropriate 
setting in the IDE (it's probably in the same spot where you tell it what 
arguments to give your program when it runs it).

- Jonathan M Davis
Jun 17 2012
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:

 I recently switched from Eclipse to monoD and found that all my 
 code to images etc was invalid because getcwd returns the 
 directory that contains the main entry code in Eclipse, but 
 returns the directory that contains the executable in 
 MonoDevelop. Is there a universally consistent way of accessing 
 files?


As mentioned, it is not reliable to use the current working 
directory for making a relative path absolute.

The approach I use is GetModuleFileNameA on Windows 
(GetModuleFileNameA(null, Buffer.ptr, MAX_PATH)) and 
readLinkPosix for /proc/self/exe on Linux 
(readLinkPosix("/proc/self/exe", Buffer.ptr, Buffer.length)).
Jun 17 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Kapps" <opantm2+spam gmail.com> wrote in message 
news:jikemjmapclwcufpwnjz forum.dlang.org...

 On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:

 I recently switched from Eclipse to monoD and found that all my code to 
 images etc was invalid because getcwd returns the directory that contains 
 the main entry code in Eclipse, but returns the directory that contains 
 the executable in MonoDevelop. Is there a universally consistent way of 
 accessing files?


 As mentioned, it is not reliable to use the current working directory for 
 making a relative path absolute.


Right. "Current Working Directory" and "Directory of Executable" should 
never be confused:

- The working directory should be assumed to always be different, as it's 
whatever directory the user just happens to be in when they run your 
program.

- If you want to load files that are relative to the exe's path, then you 
need the directory of the executble. The working directory won't help at 
all. Note that args[0] is *not* good for this either, as that gets screwed 
up by symlinks and all sorts of other stuff. args[0] is unreliable.


 The approach I use is GetModuleFileNameA on Windows 
 (GetModuleFileNameA(null, Buffer.ptr, MAX_PATH)) and readLinkPosix for 
 /proc/self/exe on Linux (readLinkPosix("/proc/self/exe", Buffer.ptr, 
 Buffer.length)).


Yea, that's definitely the way to go. Here are ready-to-go functions that 
should handle that on Windows, Linux and OSX (untested on OSX as I don't 
have a working Mac, but theoretically *should* work):

https://bitbucket.org/Abscissa/semitwistdtools/src/8123e04b593c/src/semitwist/util/io.d#cl-168

(Ignore the commented out function - that's just a remenant from the 
D1/Tango days, I should probably just delete that.)

Use those functions like this:

// Assuming the exe is "C:\Foo\Bar\App.exe"
assert(getExec() == `C:\Foo\Bar\App.exe`);
assert(getExecName() == `App.exe`);
assert(getExecPath() == `C:\Foo\Bar\`);

You should be able to rip those functions right out of that file and plop 
them into any util module you have, just make sure you also include these 
import lines:

version(Win32)
    import std.c.windows.windows;
else version(OSX)
    private extern(C) int _NSGetExecutablePath(char* buf, uint* bufsize);
else
    import std.c.linux.linux;
Jun 18 2012
next sibling parent "Stephen Jones" <siwenjo gmail.com> writes:
On Monday, 18 June 2012 at 20:53:27 UTC, Nick Sabalausky wrote:

 "Kapps" <opantm2+spam gmail.com> wrote in message
 news:jikemjmapclwcufpwnjz forum.dlang.org...

 On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:

 I recently switched from Eclipse to monoD and found that all 
 my code to images etc was invalid because getcwd returns the 
 directory that contains the main entry code in Eclipse, but 
 returns the directory that contains the executable in 
 MonoDevelop. Is there a universally consistent way of 
 accessing files?


 As mentioned, it is not reliable to use the current working 
 directory for making a relative path absolute.


 Right. "Current Working Directory" and "Directory of 
 Executable" should
 never be confused:

 - The working directory should be assumed to always be 
 different, as it's
 whatever directory the user just happens to be in when they run 
 your
 program.

 - If you want to load files that are relative to the exe's 
 path, then you
 need the directory of the executble. The working directory 
 won't help at
 all. Note that args[0] is *not* good for this either, as that 
 gets screwed
 up by symlinks and all sorts of other stuff. args[0] is 
 unreliable.


 The approach I use is GetModuleFileNameA on Windows 
 (GetModuleFileNameA(null, Buffer.ptr, MAX_PATH)) and 
 readLinkPosix for /proc/self/exe on Linux 
 (readLinkPosix("/proc/self/exe", Buffer.ptr, Buffer.length)).


 Yea, that's definitely the way to go. Here are ready-to-go 
 functions that
 should handle that on Windows, Linux and OSX (untested on OSX 
 as I don't
 have a working Mac, but theoretically *should* work):

 https://bitbucket.org/Abscissa/semitwistdtools/src/8123e04b593c/src/semitwist/util/io.d#cl-168

 (Ignore the commented out function - that's just a remenant 
 from the
 D1/Tango days, I should probably just delete that.)

 Use those functions like this:

 // Assuming the exe is "C:\Foo\Bar\App.exe"
 assert(getExec() == `C:\Foo\Bar\App.exe`);
 assert(getExecName() == `App.exe`);
 assert(getExecPath() == `C:\Foo\Bar\`);

 You should be able to rip those functions right out of that 
 file and plop
 them into any util module you have, just make sure you also 
 include these
 import lines:

 version(Win32)
     import std.c.windows.windows;
 else version(OSX)
     private extern(C) int _NSGetExecutablePath(char* buf, uint* 
 bufsize);
 else
     import std.c.linux.linux;


That was what I was after. Thanks.
Jun 18 2012
prev sibling parent reply "BLM768" <blm768 gmail.com> writes:
Is there any chance of this code being added to Phobos? I think 
it would get a fair bit of use.
Jun 19 2012
parent Kevin Cox <kevincox.ca gmail.com> writes:
On Jun 19, 2012 11:03 PM, "BLM768" <blm768 gmail.com> wrote:

 Is there any chance of this code being added to Phobos? I think it would


get a fair bit of use.


+1  I think locating the executable is a common task.



 Jun 19 2012