Recommended Way to locate executable folder and preferences folder on Linux

[foxesden]

> That is what I have been trying to do. I managed to get the plugin
> working on LMS on piCorePlayer but that was by using a symlink script on
> startup that mapped the links each time. I thought it was quite a neat
> hack . But I would prefer a solution which worked out of the box so to
> speak.

I must be missing something... are you trying to get a binary working
that ships with your plugin? You shouldn't have to move it anywhere. I'm
simply creating a Bin/<platform> sub-folder inside my Plugin hierarchy.
Then I do something like (inside the Plugin.pm):

my $pluginData = Slim::Utils::PluginManager->dataForPlugin($class);
Slim::Utils::Misc::addFindBinPaths(catdir($pluginD ata->{basedir}, 'Bin',
<platform>));

Thereafter you should be able to get the binary:

my $binary = Slim::Utils::Misc::findbin('spotty');

[foxesden]

Recommended Way to locate executable folder and preferences folder on Linux

I am trying to troubleshoot an issue that a user has installing Inguz plugin on their QNAP Server, which seems to have a proprietary file structure.

The code that I inherited, isn't too fussed about where the executable is installed, but expects the preferences to be saved into a folder /usr/share/InguzEQ

I can amend this, but was wondering if there are any environment variables that are available irrespective of platform that I should use or whether there is a convention that I should be adhering to. My reading indicates that installed applications should have details held in /opt e.g.
/opt/InguzEQ.

Any advice appreciated.

[mherger]

Recommended Way to locate executable folder andpreferences folder on Linux

In LMS there's Slim::Utils::Misc::getBinPaths() which would return the
list of folders it's looking for executable binaries.

[foxesden]

Thanks

[foxesden]

Sorry - still not resolved the issue I was trying to sort out, and is there a recommended location to save a plugins own settings? I am supporting some old code and on linux it expects config data to be written to /usr/share which is off limits to a lot of more recent installs. I would assume it needs to be somewhere on the plugin path, but not sure exactly where.

[mherger]

Recommended Way to locate executable folder andpreferences folder on Linux

> Sorry - still not resolved the issue I was trying to sort out, and is
> there a recommended location to save a plugins own settings? I am
> supporting some old code and on linux it expects config data to be
> written to /usr/share which is off limits to a lot of more recent
> installs. I would assume it needs to be somewhere on the plugin path,
> but not sure exactly where.

You can get the prefs folder and store things there. This folder must
alway be writable to the LMS user, or LMS would not start:

my $prefsDir = Slim::Utils::Prefs::dir();

I'd recommed you create a sub-folder for your plugin there.

[foxesden]

Thanks for the great support

[gordonb3]

I'm not sure what kind of Perl knowledge is required to access these functions from command line but the result can be found on the LMS settings -> information page. Should relocation of the folders be required to circumvent OS specific write blocks you can redefine the paths either as command line parameters to the slimserver service or by editing the file <LMS-path>/Slim/Utils/OS/Custom.pm (if it exists - you can create one yourself but it may be hard to distil a working config from the predefined overrides in that folder). As an alternative you could create a symlink to a writeable destination but personally I would avoid such hacks.

[foxesden]

Should relocation of the folders be required to circumvent OS specific write blocks you can ... As an alternative you could create a symlink to a writeable destination but personally I would avoid such hacks.

That is what I have been trying to do. I managed to get the plugin working on LMS on piCorePlayer but that was by using a symlink script on startup that mapped the links each time. I thought it was quite a neat hack . But I would prefer a solution which worked out of the box so to speak.

I used to do a lot of coding, but I have been managing software development teams/projects rather than coding these days. I am trying to get up-to-speed with perl, which I have never used professionally.

I have been working on the Inguz plugin, and tidied up the front end a couple of years ago, then I update the c# binaries to Visual Studio on .Net Core 6 (i.e. latest version) and this can be compiled as a standalone runtime on pretty much any modern device (crucially this can be cross-compiled on windows).

The thing that trips people up is getting the binaries installed and then getting the preferences file located in the correct place, and to sort this out I need to revisit the plugins perl code. From my perspective, the code is a bit spaghetti and does not have enough comments and it is tricky to setup a perl dev environment for maintaining plugins, as they rely on the whole Squeezebox platform.

I have managed to get Ralphy's Strawberry perl port running on my desktop, with my plugin working. So maybe I can get somewhere...

[foxesden]

You are not really missing anything. When I started updating the front-end and rebuilding the c# binary I didn't want to touch the perl code as I only wanted to change one thing at a time, and perl is the thing I know the least about.
I think the original inguz programme had been written so it could be used stand-alone like sox for example, and as such it has its own configuration folders. Added to this the plugin installer did not really work properly, so it requires the user to hack around setting up folders and downloading binaries, in order to work.

So literally the 2 areas that I want to standardise are, where to put the binary and where to locate the plugin preferences.

If I can get this working, I might ditch Inguz as the binary and replace it with CamillaDSP as this seems more flexible and uses less resources. But

[foxesden]

I had an extended run at this today, and have managed to move the install location of the executable and the preferences folder so that they both now sit in the plugin folder structure as suggested.
I had to amend the program code too in order to correctly pick up the path and saved configurations folder. I have thought of a more elegant way of handling this but will leave that for another day.
I also need to do some testing on linux and may need to rebuild binaries too.

I have an a couple of questions regarding the helper path and the custom.conf file.

The plugin script generates a custome.conf file which embeds Inguz into the workflow. At the moment I am setting the application variable to the full path/binary-filename. If I add the file location to the Helper folders can I just use the binary-filename without the full path? I was assuming that the the server was shelling out to the operating system and that the OS wouldn't know about the path.

[foxesden]

I had an extended run at this today, and have managed to move the install location of the executable and the preferences folder so that they both now sit in the plugin folder structure as suggested.
I had to amend the program code too in order to correctly pick up the path and saved configurations folder. I have thought of a more elegant way of handling this but will leave that for another day.
I also need to do some testing on linux and may need to rebuild binaries too.

I have an a couple of questions regarding the helper path and the custom.conf file.

The plugin script generates a custome.conf file which embeds Inguz into the workflow. At the moment I am setting the application variable to the full path/binary-filename. If I add the file location to the Helper folders can I just use the binary-filename without the full path? I was assuming that the the server was shelling out to the operating system and that the OS wouldn't know about the path.

Answering my own question, as long as the binary is contained in a helper folder location then it will be picked up, so no need to use the full path.