Retroarch CLI does not handle tilde (~) expansion properly for --libretro argument. I have not thoroughly checked other arguments, but --config does also seem affected. Using -L instead of --libretro works as expected.
It should handle tilde expansions properly.
Commands used:
# This craps out
/usr/bin/retroarch --libretro=~/.config/retroarch/cores/mednafen_psx_hw_libretro.so psxgame.iso
# This works perfectly
/usr/bin/retroarch --libretro=/home/user/.config/retroarch/cores/mednafen_psx_hw_libretro.so psxgame.iso
# This also works
/usr/bin/retroarch -L ~/.config/retroarch/cores/mednafen_psx_hw_libretro.so psxgame.iso
This is the error log:
[ERROR] Frontend is built for dynamic libretro cores, but path is not set. Cannot continue.
[ERROR] Fatal error received in: "init_libretro_symbols()"
Run retroarch on the command line with --libretro argument and specify a "tilde-d" path within your home directory. Please refer to the commands I used above.
Parameter expansion is supposed to be the shell job so i have little clue why yours is screwing up. It probably shouldn't, but regardless, this is the definition of 'not a (retroarch) bug'.
Are you sure you're not single quoting on the cases it fails?
The problem of this case:
# This craps out
/usr/bin/retroarch --libretro=~/.config/retroarch/cores/mednafen_psx_hw_libretro.so psxgame.iso
Is that there is a = symbol directly in front of the ~. The tilde only works when there is a blank before it:
$ echo ~/
/home/user/
$ echo =~/
=~/
Perhaps you want this?
/usr/bin/retroarch --libretro ~/.config/retroarch/cores/mednafen_psx_hw_libretro.so psxgame.iso
EDIT: for completeness, note that variable assignment does work (even though is not related to the issue):
$ some=~/
$ echo $some
/home/user/
Does retroarch expand paths in the config files btw?
I know that the shell is the one handling expansion, and I am aware of the alternatives recommended by @hhromic, but I was under the impression that the actual parsing of command line arguments and values are up to the programmers' discretion as well.
In any case, my mistake was my false memories of instances like --arg=~/value working as expected. When I tried it on other commands, they did not work, so I guess it is normal for programmers not to support the handling of tilde's in those cases. Anyway, thank you for your help. I will close this issue now.
Most helpful comment
The problem of this case:
Is that there is a
=symbol directly in front of the~. The tilde only works when there is a blank before it:Perhaps you want this?
EDIT: for completeness, note that variable assignment does work (even though is not related to the issue):