dosbox-pure
dosbox-pure copied to clipboard
Directrories with extensions
Maybe I'm doing things wrong, but I'm trying to load a game from the command line, and I expect to get the start menu if I don't have any dosbox.bat file or equivalent to be launched automatically. I'm using Linux, on an ext4 file system to host my games (if that is of any importance).
- When the game folder is called
robocopfor example: I launch it as an argument through the retroarch command line and on start-up I correctly have the start menu and can select anyROBOCOP.EXEorROBOCOP.COMin that list. All good. - If I rename the folder to
robocop.pc, I get "No executable file found" on the start menu. That's my issue, I would expect to see the.EXEand.COMfiles listed here, for directories that have extensions on my Linux filesystem. - What is weird is: if I load the upper directory where my
robocop.pcfolder is located (for example with/userdata/roms/dos/robocop.pc, if I load/userdata/roms/dos/from the retroarch command line) I can correctly see all the sub-directories in the start menu, includingROBOCOP.PC\ROBOCOP.COMandROBOCOP.PC\ROBOCOP.EXE.
My retroarch command line:
/usr/bin/retroarch -L /usr/lib/libretro/dosbox_pure_libretro.so --config /userdata/system/configs/retroarch/retroarchcustom.cfg /userdata/roms/dos/robocop.pc
While it's not possible with the RetroArch user interface to run to the core with a directory, I recently realized that it is possible with the command line and made it so it at least doesn't crash anymore. But as of now the distinction between directory and file is only done by checking if a dot is found in the name. We could attempt to use anything with an unrecognized file extension as a directory but then someone might have a directory named "game.zip" so I guess to properly handle this we need to ask the file system if the passed path is a file or a directory before doing anything.
Maybe define a list of acceptable directory extensions like .dir. and .pc... Of course if someone creates a directory ending up in .zip or .exe, they will run into trouble... but that's not entirely unexpected.
This has been fixed in #382 which is now in the latest 0.9.8 release.