indigodarkwolf / box16

A fork of the official X16 emulator, converted to C++20 and with a bunch of features tweaked and added.
MIT License
41 stars 19 forks source link

Error in relative path handling #20

Closed indigodarkwolf closed 3 years ago

indigodarkwolf commented 3 years ago

Copied from Discord:

JimmyDansbo — Today at 3:05 PM When starting box16 with the -rom option it assumes that the path provided is from the box16 executables directory instead of the current directory

Sepia — Today at 3:54 PM Well, it had been the other way at one point, assuming the path provided was relative to where the command line was located, but the original emulator assumes the path is the box16 executables directory, so that was a compatibility-breaking change and I put it back. So you can bug it on Github, but unfortunately it's not going to be fixed unless I decide to intentionally break compatibility with the official emulator.

ZeroByte — Today at 4:07 PM what happens if you specify an absolute path on the cmdline? e.g. -rom ./myrom.bin or -rom /home/user/somedir/myrom.bin ok - decided to just test it... @JimmyDansbo - absolute paths beginning with / will use any location. at least it does in Linux

JimmyDansbo — Today at 4:12 PM Sure, absolute paths will always work, but normal behavior for a program is to use current working directory as a reference instead of using the directory where the binary is located. In my home directory, I have x16-rom directory and box16 directory. If start box16 from my home directory with the following command: box16/build/box16/box16 -rom x16-rom/build/x16/rom.bin it will not work

ZeroByte — Today at 4:14 PM hmm - gonna try the official emu in a similar vein

JimmyDansbo — Today at 4:14 PM official emu works as every other linux program :wink:

ZeroByte — Today at 4:18 PM hahaha - I just found a bug in the official emu x16emu -rom . it boots the emu with null ROM instead of giving "cannot open rom.bin" error msg. it tries to open the directory itself as if it were the ROM file okay, so the official emu's behavior is as follows: if -rom is specified, search relative to the PWD at execution time else look in exe directory

JimmyDansbo — Today at 4:20 PM hehe Yeah, that would be the normal way of doing it for any binary on linux

DesertFish — Today at 4:27 PM if -rom is specified, search relative to the PWD at execution time else look in exe directory I think it now always looks in exe dir regardless of parameter (I requested the change to look in exe dir for the rom.bin as default)

ZeroByte — Today at 4:46 PM I've tried a bazillion permutations on the official emu. If -rom is not specified, then it looks in the exe directory, and only there. If -rom is specified on the cmd line, then that is opened relative to the PWD.

JimmyDansbo — Today at 4:47 PM Yes, but box16 does not try to open rom relative to current working directory

ZeroByte — Today at 4:49 PM Sepia stated that he didn't want to break compatibility so I thought I'd give it a thorough putting through its paces just to make sure.

DesertFish — Today at 4:50 PM My use case is the situation where -rom is not specified

ZeroByte — Today at 4:53 PM And for a final check - I ran box16 from somewhere different than either the specified ROM or the specified PRG arguments, using only relative paths to reach each one. box16 clearly builds rom path relative to the exe in all cases, and prg path relative to PWD Sepia - just so you don't miss this in the TL;DR thread above- the official emu uses PWD-relative path for the -rom argument if provided, else EXE directory if not specified.

Sepia — Today at 5:01 PM I see. Okies, that's totally a valid bug then. I'll see if I can fix it properly this time. :stuck_out_tongue:

indigodarkwolf commented 3 years ago

Hopefully fixed with 40b0e36d0be2fc2f7287e0779dfb05eb6233760c

indigodarkwolf commented 3 years ago

Seems to be fixed, closing.