LAC is sensitive to the way it's started (0 argument), which is unexpected

[vasya novikov]

Currently, LAC's behavior depends on how it is started: lac or /usr/bin/lac or otherwise. In case of /usr/bin/lac started from the home directory, it will fail at startup, with an error description that might not be immediately obvious to new users (it wasn't understandable to me):

Info: Dirs::Dirs() Function entry:
Info: Dirs::Dirs() myfile = 
Info: .//LAC
Fatal: Binary file has no context to the data files.
Are you attempting to run LAC without first running our install.sh script? 
Please consult online documentation for proper installation details.

This behaviour is surprising to me because I'm used to a different behavior from tools like rm, chmod, text editors, IDEs, desktop applications etc. Additionally, it's noteworthy that LAC itself stores its configs in ~/.LAC, which is only dependent on HOME. The reason why the textual path to the binary alters its behavior is not very clear.

Perhaps we could switch the logic to instead always behave identically?

[bbosen]

I remember creating that message. It was related to my need to unify the "AppImage" version and the "standard" version of LAC.

Before early 2023 I maintained separate source code for the AppImage version and for the regular version of LAC, but it became tedious to maintain two versions. (Whenever I fixed a bug or added a new feature to one version, I had to do it again for the other version.) In early 2023 I merged both of those code trees into a unified, single one. This made my life as a developer MUCH easier.

The design of AppImages demands special treatment. Among the restrictions: No "absolute" library or resource references are allowed. Every library or other filesystem resource must be referenced relative to the location, in RAM, of the running executable. This required me to write a sophisticated new function, which I named "GetExePath()", to determine the absolute location, in RAM, of LAC's executable image at run-time (which can be different every time LAC is started). Thereafter, every resource reference must be relative to that location, or the AppImage logic (which has to find its copies of many references from resources packed within the AppImage) breaks down. If I recall correctly, when LAC is directly invoked from an absolute filesystem location like "/usr/bin/lac, my "GetExePath()" function can't properly figure out its own location in RAM.

I can't remember all of the details right now, but I do remember that after I merged the source code for the AppImage version of LAC with the standard (non-AppImage) version of LAC, the resulting, unified code retained those AppImage-related restrictions.

The error message:

"Are you attempting to run LAC without first running our install.sh script? 
Please consult online documentation for proper installation details." 

...was intended to urge the user to employ the install script that always accompanies LAC to install everything, further ensuring that all of LAC's required resources are located in places that can be found by the unified code, whether AppImage or not.

As I examine that error message right now, I can see that it doesn't clearly explain what is going on. I will improve it for better clarity in a future version.

[vasya novikov]

Hi @bbosen, thanks for the reply and for the explanation!

Given what you say, would it be an idea to do exactly what the AppImage format asks: use relative paths? E.g. the relative path ../share/file.txt to /usr/bin/lac is /usr/share/file.txt, the relative path to /home/user/bin/lac is /home/user/share/file.txt, and so forth. That's the typical approach for relative handling of absolute paths if I understand it correctly.

This way, you'd be able to run the same binary lac in however way you want, but the relative path resolution will just boringly do that: find the relative other path.

Programmatically, this is easy to do by first converting the 0 argument to the absolute canonical path -- or do it at resolution time of the relative files if preferred

Thoughts?

[bbosen]

Sorry vasya. I'm not clear on your language there. The AppImage tools I use never permit me to reference anything with a path commencing with "/". It sounds like you are trying to teach me something different, but I am not following.

...and I'm not entirely sure if we are solving a real problem with this discussion. Do you foresee some real problem developing from the current, working method?