Why does -f or --config need the full path to config file?

[StusBrainDump]

Running 5.7.3 on macOS

If I run Amiberry from command line (Amiberry.app/Contents/MacOS/Amiberry) with -f or --config I have to specify the path to the config file. Should this be the case? Surely if amiberry.conf contains a valid path to your configs folder it would make sense to just be able to specify a config name (even without the .uae) and Amiberry look in your defined configs folder first?

[giantclambake]

This is a corollary of amiberry's direct-load logic me thinks...ie; amiberry --help

Additional options:
amiberry <file>         Auto-detect the type of file and use the default action for it.
                                    Supported file types are: .uae config, .lha WHDLoad, CD images and disk images.

I get what you're saying, but the above demonstrates how we use the file extension(s) to determine the default action. In effect, you could invoke amiberry someconfig.uae ...without the need for -f or --config, and the config.uae doesn't actually need to be in the /conf/ path...and amiberry will load that config.uae file and process it accordingly....

....if you do that however, then the Amiga file(s) specified within that 'someconfig.uae' must exist in paths specified therein... which is typically OK as folks tend not to move those files about, however, if they have moved the Amiga file(s) somewhere else, this is going to fail for obvious reasons (disk not found =)

It's when you use the other possible invocations of amiberry <file> that the contents of the /conf/ directory play a part.

For example, if I invoke amiberry somegame.lha at cmdline, amiberry determines to handle the file as a whdload.lha gamepak (based on the .lha extension), then searches in /conf/ to see if there's a somegame.uae configuration to use, and if not search the XML for a match to somegame.lha (sha1sum) and use that...and if no match is found, spawn the whdbooter autoconfig process.

The thing to note here, is the file itself, somegame.lha , can be anywhere on the filesystem...$HOMEDIR, $Desktop, /tmp, USB removable media ..anywhere, amiberry is going to follow the above process regardless of file location.

The same premise exists for floppy/CD image files...if I invoke amiberry Sysinfo.adf then amiberry will load it as a floppy disk image (based on file extension), then searches in /conf/ to see if there's a Sysinfo.uae configuration to use, and if not, boot the image using the default basic A500 Quickstart machine profile. In the CD image case, the handling is much the same, however amiberry also scans the filename for the text hints CD32/CDTV to determine which Amiga model to use.

The same note applies here as well ~ once a config.uae file exists in /conf/ for a specific Amiga title, the actual location of that Amiga file no longer matters...it's path agnostic if you like ;) The defined paths wrt amiberry, allow this to be so. In a full desktop integration scenario, it allows user to drag'n'drop an Amiga file on the amiberry desktop icon, and launch the emulation directly, using the defaults for the machine types built into amiberry, or instead, use an existing config.uae for that Amiga file.

Operationally, we already have the situation wherein the user can direct-launch a whdload.lha or floppy/CD image, and it's going to work, no further configuration is necessary. I have my action hotkeys set to enable fullscreen toggle & quit functions, so for a title that runs correctly, I don't have to do anything -- this Amiga title does not require an associated config.uae file... simply put ;)

OTOH there will always be cases where that is not so ~ further changes in the emulation setup are required to get that title to run correctly on your setup....and this can be all the way from some whdload.lha titles that need some display tweaks, to dropping an AGA only floppy image direct into amiberry, which is going to start as an A500 =) In any case, if/when this happens, you can just hit the F12 key, make changes in the amiberry GUI, save the config.uae for this title (it will be automatically named correctly in the Configurations panel), then the next time you direct-launch this Amiga file with amiberry, it'll work as expected.

Interestingly, back when we were discussing this, I had made the point that IF a config.uae file existed for any particular Amiga file, then we should be able to do amiberry <filename.ext> ... without impacting upon established cmdline options, and that's very much what's been done...ie; setups that rely on the amiberry cmdline launching are as they've always been ; the invocation of amiberry <filename.ext> is like a shorthand way to use existing configurata that best matches the filename.ext, else proceed with any detected Amiga machine types, and launch the emulation...you only use the GUI, if you need/want to...minimalist stance ;)

The equivalent to using the -f or --config /path/to/config.uae invocation for direct launching, is ie; ./amiberry conf/somename.uae

With no switches, amiberry treats it as amiberry <file> and uses the builtin direct-load logic to figure out how to handle the object (filename.ext), and proceed accordingly. In this case, provided any Amiga image files paths specified in the config.uae file exist, the emulation will start immediately using that config. In use, amiberry doesn't care about where the object is...ie; you can copy your config.uae files into the same directory as amiberry, and do amiberry somename.uae and it's going to happen ;) In linux on the desktop, you can have a config.uae icon, and simply 'open with amiberry' and it works (even though the actual path to the file is $HOMEDIR/Desktop/somename.uae)...

...the only time it matters to amiberry, is when the file object is something other than a config.uae file. In this case, amiberry will only check in the configured Configuration files: $path, to see if there's a match for that filename{.ext} with which to proceed with ; this is a lot of the purpose of this path element, when it comes to direct-loading Amiga titles ~ it gives you a chance to use a custom, pre-configured emulator config, to best suit how you want to run/use any Amiga softwarez... =)

In the GUI context, we also use this $path as the default placeholder for what's displayed in the GUI -> Configurations panel, and this is also the default Save location for creating/loading config.uae files...and a launch-point for that matter ;)

To be fair though, I don't own any Mac hardware, and haven't tested how this pans-out wrt macOS ~ I've given you the linux example of how I understand amiberry to work (for me 8). Might you please try direct-loading some config.uae files, and let us know if you get the same results on your setup?

[StusBrainDump]

Wow... thanks very much for the detailed explanation. I'll have to read that several times to fully digest it, but it's very much appreciated.

So as a quick test/explanation....

From a terminal session in my home directory, I can execute the following to start the A1200-WHD config without showing the UI:

amiberry /Users/myusername/Amiberry/Configurations/A1200-WHD.uae -G

Works a charm. But if I try any of the below, it just shows the default A500 WB 1.3 hand screen:

amiberry A1200-WHD.uae -G
amiberry conf/A1200-WHD.uae -G
amiberry /conf/A1200-WHD.uae -G

amiberry --config A1200-WHD.uae -G
amiberry --config conf/A1200-WHD.uae -G
amiberry --config /conf/A1200-WHD.uae -G

amiberry -f A1200-WHD.uae -G
amiberry -f conf/A1200-WHD.uae -G
amiberry -f /conf/A1200-WHD.uae -G

My expectation is that amiberry would say "oh look, a .uae file with no path specified, I'll look in the path that's specified in amiberry.conf for config_path and try and load it from that folder"

It seems this "intelligence" doesn't exist, or am I doing something wrong?

I either have to be within my Configurations folder when I don't specify a path, or I have to specify a full (or I guess partial would work too) path.

[giantclambake]

I either have to be within my Configurations folder when I don't specify a path, or I have to specify a full path.

It's the same in linux ~ macOS has a different packaging arrangement...and TBH, the pathing in macOS has always driven me nuts. As said, I gave you the linux example ~ the macOS case is different (why the commands I exampled don't work for you ;). It's been over a decade since I touched macOS....I kinda remember some of it...

In macOS, amiberry is installed in Amiberry.app/Contents/MacOS/Amiberry/ ... this establishes a 'user path', and is why you can issue amiberry at the cmdline (without a leading ./ ) and the amiberry executable is found.

As you note above, the configuration files path in macOS is /Users/myusername/Amiberry/Configurations/

I believe when you login to your account on macOS, your $CWD (current working directory) is /Users/myusername/

If that's correct, then you should be able to copy a config.uae into your $CWD ...ie;

cp /Users/myusername/Amiberry/Configurations/A1200-WHD.uae /Users/myusername/A1200-WHD.uae

Then you should be able to issue the cmd amiberry A1200-WHD.uae -G

IF that works, then in theory you could ...

mkdir /Users/myusername/amiberryconfs
cp /Users/myusername/Amiberry/Configurations/A1200-WHD.uae /Users/myusername/amiberryconfs/A1200-WHD.uae

Then... amiberry amiberryconfs/A1200-WHD.uae -G ...should also work I think....

Edit: Wrt what you're suggesting here, and AFAIK, the Configuration files: path can be anywhere you have permissions to create a directory for this purpose..ie; my example being /Users/myusername/amiberryconfs but you can name the directory anything that you want. If this doesn't hold true for macOS, then maybe a hardcoded path of /Users/myusername/Amiberry/Configurations/ is compiled in...

[StusBrainDump]

Thanks again for the reply .... but I think we have a crossed wire here....

I know I can specify paths, partial paths etc to the configuration file. I could copy the configuration .uae files to different places and then use paths or change my CWD folder to the folder containing the config and then use no path.

The point I'm trying to make, albeit not very clearly I think, is...

If in amiberry.conf I have a path configured as such

config_path=/Users/myuserdir/Amiberry/Configurations/

Why does Amiberry not look IN THAT SPECIFIED PATH by default when i launch Amiberry with no path to the config .uae file, by using the below invocations for example.

amiberry A1200-WHD.uae -G
amiberry --config A1200-WHD.uae -G
amiberry -f A1200-WHD.uae -G

If it "knows" from the amiberry.conf file where to expect my config .uae files to be located, why not look where they are expected to be located by default when just a config name is specified.

I.E behind the scenes do amiberry what_config_path_is_set_to/A1200-WHD.uae -G

[midwan]

I think this should be doable without too much hassle, but I need to check.

[midwan]

I've added this logic in the current preview, though I didn't have time to test it much so far.

[giantclambake]

Just tested on preview/x86-64 ~ doesn't seem to work...

./amiberry conf/ClassicWB-P96-test.uae //works as expected, pops GUI with config.uae loaded
./amiberry conf/ClassicWB-P96-test.uae -G //works as expected, starts emulation with specified config.uae

./amiberry ClassicWB-P96-test.uae //does not work, pops GUI without config.uae loaded
./amiberry ClassicWB-P96-test.uae -G //does not work, starts emulation with default config (boots to ks1.3 insert disk screen)

[midwan]

It's meant to be used with the -f or --config parameter, so try it like this:
amiberry -f ClassicWB-P96-test.uae -G and it should work

[giantclambake]

I'm so totally blind sometimes... yes, works correctly with -f/--config ...apols =/

[giantclambake]

Why does Amiberry not look IN THAT SPECIFIED PATH by default when i launch Amiberry with no path to the config .uae file

The simple answer is, amiberry's not designed to work that way =) Like I said, I do understand what you're getting at, I'm merely pointing out the options available to you.

The first thing, is there is natural cmdline ordering... ie; amiberry A1200-WHD.uae -G would need to check $CWD first (in case user was trying to launch from there), and if A1200-WHD.uae is not found, check the $configurations path setting instead. It would need to be a two-step like that...(I'm not sure if you could exclude $CWD conditional on the -f or --config switches being present)....

...the second thing is, perhaps I don't quite appreciate your usage scenario ; macOS is different. For instance... if I think macOS, I think desktop environment ..ie; the iMac machine bought for me back circa 2010, I'd be using amiberry from menu launchers, not an xterm. I know all about xcode & friends (you had to working with WINE on macOS)...but I'm just curious why you're on cmdline?

I suppose I should mention the white rabbit special case, just in case you find it useful...

cp /Users/myusername/Amiberry/Configurations/A1200-WHD.uae /Users/myusername/Amiberry/Configurations/default.uae

Then when you issue amiberry -G the emulation will start directly using that copy of the A1200-WHD.uae file. I sometimes use this trick to set the machine type to A1200, when I know I'm checking out AGA demo disks etc. You need to delete the default.uae file to return things to normal.

FWIW, I do very much checkout/test amiberry from a xterm window as well, but not from cmdline so much ... midnight commander... I've edited the extensions file, so I can just hit enter on any config/CD/floppy/whdload file, and it fires up amiberry using whatever it was I threw at it =) When I'm testing whdload.lha titles, I'm even too lazy to to open an xterm ~ I just launch the links2 browser pointed at the turran ftp site...ie; links2 -g -mode 1024x768 http://ftp.grandis.nu/turran/FTP as a desktop launcher, and just click on whatever Retroplay whdload gamepak is there, and it launches amiberry (and thus the Amiga title) for me...I rarely see the amiberry GUI at all, if the titles work as expected. Of course, the file associations in links2 config have been edited to make it so...end of the day however, these are edits I only have to type out once, and it's done. Gives me time to type about other stuffs. I keep cmdline mainly for debugging/testing....

I of course have no idea how midwan views this aspect.... I can't think of it being of any immediate benefit in linux, but past personal experience tells me, one can get sick/and/tired/of/nested/paths/in/macOS really...really quickly, so what you suggest makes total sense to me, 'coz I have felt your pain...lol.. =) Likewise however, I can't immediately think of any contra-case wherein such a change would conflict with sop ...especially if it was only a macOS tweak.

Little doubt, midwan will weigh in here when he gets to it ;)