Working directory <> application directory

[WaterKnight]

Hi,

This basic problem keeps nagging me. My applications do not consist of a single file but draw in further script data and other media from the file system (Windows) dynamically. To find these assets, ofc I do not want to use absolute paths but relative paths according to the directory structure. But all the io functions (in Windows at least) base the given relative paths on the current working directory of the process. So when I load in a script file from another directory, the working directory no longer matches the path the now executing file resides in and therefore I cannot specify the paths relative to the executing file anymore. Moreover, even the entry points can be launched from another location, which is why it seems to me, to have any integrity at all, you have to change the working directory when starting an application.

The solution I have been using to this date is to either do that or to include a method to determine the local directory + transformation functions. But it's annoying to have to add this method everywhere, in each and every single entry point. Also it's language-dependent and e.g. in Lua, you cannot statically link it, so the option is to directly inline the implementation in the same file (which does not work either because in this case I need the help of a dll) or to specify the location of the library explicitly, just so I can draw in these basic functions.

An alternative is to set global environment variables, especially PATH, but well, it implies to pollute and expose to the global space and then I would have to instruct any user of my applications to set it up or I need to provide an installer.

It's very rare that I actually want to reference the working directory. On the other hand, there were countless times where I generated files in places they were not meant to be. I have written lots of small tools that call each other. Spanning new processes is recommendable but requires interface work. When calling jasshelper, I really have to wonder why it's in my domain to know that it must be started from the JNGP main directory in order to find its dlls and other stuff.

 

[GhostWolf]

The correct way to expose executables is with the Path variable. If you don't like it, you are welcome to create a new OS that can magically find things.
Or you can probably do the sane thing of having all of the relevant executables together, if there are indeed many.

 

[WaterKnight]

Yet few applications register in the Path variable since they were not designed to be called from elsewhere. If everyone did that, name clashes were inevitable.

Magic is not required. The OS could attach the source location to the executing code as meta data and if not automatically use it in relative paths for io as default, it would already be helpful as simple standard functions/extra parameter to io.

While I agree that standalone executables may be addressed globally (or in my case, I let the user specify the lookup path in a config file), that does not suffice the following kind of problem:

I have shared, dynamic libraries/modules lying somewhere in their own repository. My applications A, B, C request them to make use of the functionality they provide. The libraries ofc are not loaded in new processes because they should actively communicate with and participate in the client applications, no networking. Finding the entry point of those libraries may succeed but how are those libraries supposed to find their own stuff from their own repositories? The working directory is still within the application or elsewhere, so either the application would have to tell the library or the library would have to read its own global address, which seems ridiculous. Then we could scrap relative paths altogether. The issue propagates when the library draws in further scripts from its subdirectories or itself comes across the need of higher libraries.

Reminder: It's not only about finding script files/dlls. Even a library can have its own belonging media and should directly control urls, not randomly browse lookup paths.

Even if there is no good solution or things have to be this way, I seem to be the only one struggling with that and that riddles me if I am doing something fundamentally wrong.

 

[GhostWolf]

Most applications don't need the Path variable, because most applications do what I said - put everything in the same directory (also, most applications have one executable).
Whenever one needs to start using fragmented things, like compilers, Path is there for you.

Can't really suggest anything, because I have no idea what you're doing.

Then again, if I remember correctly, you already opened this same thread in the past, and got the same responses.