Get the path of the current process

does tango.sys.Environment.exePath() not provide this kind of thing?

No, exePath requires specifying the command that ran the process. Not that it can't be had via argv[0], but it would be awkward to get it inside a library function. You'd have to either use the OS utilities at your disposal to get the current executable, or ask the caller to pass it in.

I think this feature could be added into tango.sys.Environment.exePath by getting the current running process path when a null string is passed in, then make the signature default to null. i.e.:

struct Environment
{
  static FilePath exePath(char[] path = null)
  {
...

// usage
auto myProcesPath = Environment.exePath;

-Steve

Replying to kris:

does tango.sys.Environment.exePath() not provide this kind of thing?

No it doesn't. The following is needed with exePath:

1. The name of the executable must be known
2. It has to be in the PATH
3. I'm not sure but symlinks don't seem to work

I've attached an updated version with freebsd support also

steve, you want to take this one? but be careful with additional dependencies (I assume carbon framework may be ok though).

I have absolutely no experience with Mac, so I'm not sure how to verify or test that one. However, if you say it's ok...

Replying to doob:

Replying to kris:

does tango.sys.Environment.exePath() not provide this kind of thing?

No it doesn't. The following is needed with exePath: 1. The name of the executable must be known
2. It has to be in the PATH
3. I'm not sure but symlinks don't seem to work
I've attached an updated version with freebsd support also

Here are some results for windows (actually WinXPpro SP3 / dmd 1.041 / tango r4408).

I took process.d and added:

import tango.sys.Environment;
import tango.io.Stdout;
import tango.util.PathUtil;
void main(char[][] args)
{
    char[] exePath;
    char[] proPath;
    
    auto fp = Environment.exePath(args[0]);
    if(fp is null)
        exePath = "-- null --";
    else
        exePath = fp.toString;
    
    proPath = getProcessPath;
    Stdout.formatln("Environment.exePath: '{}'", exePath);
    Stdout.formatln("         normalized: '{}'", normalize(exePath));
    Stdout.formatln("getProcessPath:      '{}'", proPath);
    Stdout.formatln("         normalized: '{}'", normalize(proPath));
}

and got these results:

C:\Temp>
C:\Temp>processpath
Environment.exePath: 'C:/Temp/processpath.exe'
         normalized: 'C:/Temp/processpath.exe'
getProcessPath:      'C:\Temp\processpath.exe'
         normalized: 'C:/Temp/processpath.exe'

C:\Temp>cd sub_böse

C:\Temp\sub_böse>..\processpath
Environment.exePath: 'C:/Temp/sub_böse/../processpath.exe'
         normalized: 'C:/Temp/processpath.exe'
getProcessPath:      'C:\Temp\processpath.exe'
         normalized: 'C:/Temp/processpath.exe'

C:\Temp\sub_böse>cd \

C:\>temp\sub_böse\..\processpath
Environment.exePath: 'C://temp/sub_böse/../processpath.exe'
         normalized: 'C:/temp/processpath.exe'
getProcessPath:      'C:\temp\processpath.exe'
         normalized: 'C:/temp/processpath.exe'

C:\>

So, I don't think that the name of the executable must be known (to the programmer) and neither does it need to be in the path.

Environment.exepath does provide this kind of thing, but differently.

PathUtil?.normalize does a good job ;-)

Replying to HeiHon:

You're right, PathUtil.normalize does a good job. I tried various cases with your test code and almost all cases worked except one and some cases did return slightly different results.

The case that didn't work was when I run the code with a shebang (perhaps not that important), works with getProcessPath but returns null with exePath.

If I create a symlink to the app and run the symlink exePath returns the path to the symlink and getProcessPath returns the path to the actual executable.

If I put the executable in a bundle and runs the bundle getProcessPath returns the path to the bundle and exePath returns the path to the actual executable. This is mac specific but I think it's a little more useful to get the path to the bundle.

A problem I see with exePath is that you have to send args[0] to the function. I noticed a problem with getProcessPath when I tried it together with dwt cocoa. DWT crashes and I think it's because both getProcessPath and dwt link to the Carbon framework. getProcessPath uses tango.sys.SharedLib but with dwt you have to manually link with the -framework flag.

All above tests performed on Mac OS X.

Could/can -framework be added via pragma(lib) ?

No, I can't get it to work and if I remember correctly gdc doesn't support pragma(lib). Isn't pragma(lib) only for static libraries? Frameworks are dynamic libraries. It works with rebuild's pragma(link) though.

GDC does quite correctly not support pragma(lib) atm, but it should if it is ever updated again.

I think dynamic libs should work just fine, but even in DMD the pragma(lib) functionality is castrated atm, see http://d.puremagic.com/issues/show_bug.cgi?id=2776

I added an entry to bugzilla about adding a pragma(framework): http://d.puremagic.com/issues/show_bug.cgi?id=2968

I've added patches for both of the above mentioned issues.

whatever happens here, it really shouldn't be bound into Environment.exePath() as default behaviour ... please isolate new dependencies elsewhere :)

Removed dependency on Carbon on Mac OS X

I no longer am contributing to Tango, please assign to someone else.