Attract-Mode Support Forum
Attract-Mode Support => General => Topic started by: 8bitsdeep on February 26, 2017, 01:18:48 PM
-
See attached image. The smaller window is the AM console. Larger is me manually typing the same command into the command prompt from the AM directory. Manual command works, AM doesn't.
Is this a bug or am I missing something here?
-
Working directory is "..\Emulators\Dolphin". "..\Emulators\Dolphin\Dolphin.exe" from there would be "..\Emulators\Emulators\Dolphin\Dolphin.exe" which is not what you want.
In your test command prompt, change your working directory (cd "..\Emulators\Dolphin") to reproduce your command line accurately.
-
OK, I'm confused.
This didn't work:
executable ..\emulators\dolphin\dolphin.exe
args "[romfilename]"
rompath ..\games\gamecube
romext .zip;.iso
But when I moved the dolphin folder up one directory, this worked:
executable ..\dolphin\dolphin.exe
args "[romfilename]"
rompath ..\games\gamecube
romext .zip;.iso
Shouldn't those be functionally the same thing?
-
Your working path is already .\Emulators\Dolphin, ergo, you're already in the Emulators\Dolphin directory. so:
..\dolphin\dolphin.exe
works, or simply:
dolphin.exe
would also work. :)
..\emulators\dolphin\dolphin.exe will NOT work, because that translates to Emulators\Emulators\Dolphin\Dolphin.exe. "..\emulators" doesn't exist one level up from Dolphin.
-
I thought the executable's directory defined the working directory, if it isn't specified. Is that not the case?
-
Ah, I didn't know you didn't specify one. Now I see the "bug" you're referring to. :)
Yes according to the code it does use the program name to determine it:
std::string work_dir = cwork_dir;
if ( work_dir.empty() )
{
// If no working directory provided, try to divine one from the program name
//
size_t pos = prog.find_last_of( "/\\" );
if ( pos != std::string::npos )
work_dir = prog.substr( 0, pos );
}
So yes, that will create a mess if you have a relative path that is not the same number of levels down as up. If you want to use relative paths you'll probably need to explicitly specify the executable name (without the path) and the working dir separately, so it doesn't try to navigate the relative paths twice (one when it changes the working dir, and again with the actual process name).
This could be fixed in the code by removing the path from the executable path, if it was "divined".