Is there a way to get the working directory of the lime project?


#1

I’m invoking my project like this:

/path/to/hello> haxelib run lime test windows

I’d like to get the path /path/to/hello, the place where I was when I invoked the compiler, but it doesn’t seem like there’s a way to do it.

I tried Sys.getCwd but it returns /path/to/hello/bin/windows/cpp/release/ which isn’t helpful.

I can’t find any other relevant method in the documentation. Have I missed it?


#2

Further testing shows that a correct pwd path is returned for windows if you invoke the executable by hand. So presumably on windows it’s either haxelib or lime that is changing the working directory which is a little unwanted but whatever.

On OSX, I can’t find any workaround. Even if you run the app from the terminal it seems that getCwd() will ignore your pwd and just report the app’s own directory no matter where you are.


#3

If you want to compile this information into the app, try using a macro:

public static macro function getProjectDirectory():String {
    return macro $v{Sys.getCwd()};
}

Then call getProjectDirectory(). Note: I haven’t tested this, so I don’t know if it’ll work.


#4

It doesn’t build.

Anyway I definitely don’t want to compile that information into the app, that’s the opposite of what I want. I want whatever folder the terminal was in when it invoked the app. I want the working directory, not the project directory.


#5

Oh, oops. It should return haxe.macro.Expr, not String.

Then Sys.getCwd() is your only option. (Short of spawning a subprocess that attempts to look at the state of all active Command Prompt instances.)

Since Lime calls cd before running your project, you’ll have to work around Lime. Run your project manually, typing out “bin/windows/cpp/release/AppFile.exe” (or whatever the correct path happens to be).


#6

I’d be happy with that workaround. I suppose in this case the way that lime executes the program isn’t really a problem for me in this case.

My biggest problem is that even bypassing lime doesn’t work on mac because the app clobbers its own cwd when it starts up.

I couldn’t find a workaround for this so I ended up writing a shell script to pass in the cwd as an argument.


#7

We need the current working directory to be the same as the executable to resolve relative asset paths, but if we make improvements to ensure that this is no longer necessary, then leaving the current working directory alone may be a better default behavior. Is this an OpenFL, or a Lime project?

The only concern I have is in user code that assumes the working directory is the same as the project, and therefore makes assumptions about reading and writing files outside of lime.utils.Assets