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?

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.

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

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)).

"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;

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.

Is there any chance of this code being added to Phobos? I think it would get a fair bit of use.

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.