Arronax entrypoint assumes it will be called with `sys.argv[0]` contained in the directory where the entrypoint resides.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Arronax |
Confirmed
|
Undecided
|
Unassigned | ||
arronax (Arch Linux) |
Opinion
|
Undecided
|
Unassigned |
Bug Description
Executing `python setup.py install` in some cases (an installation in Arch Linux, for example), create a script at `/sbin/arronax`, which is what is first executed, and then call the main entrypoint with `/sbin/arronax` as `sys.argv[0]`, while all the other arronax files (ui files, other python files, etc) reside in `/usr/share/
The `settings.py` file calculates this DATA_DIR based on `sys.argv[0]` (Line 57), resulting in `editor.py` trying to load `/share/
```
Traceback (most recent call last):
File "/sbin/arronax", line 33, in <module>
sys.
File "/usr/lib/
editor = Editor(args.path, args.stype, args.dir)
File "/usr/lib/
self.
File "/usr/lib/
self.
gi.repository.
```
I've attempted hardcoding `sys.argv[0]` to `/usr/share/
This was discovered on the comment section of the AUR package which bundles this program for Arch Linux. This is the URL of the comment section: https:/
Update: I've found the root source of the bug
Under some systems,including Arch, `/sbin` is a symlink to `/usr/bin`, which means that this program, when installed, can be called from multiple locations. The fix is simply to resolve the real path of the executable before traversing directories to find the DATA_DIR.
I've packaged a solution as a git patch that can be applied to the current main branch.
Changed in arronax: | |
status: | New → Confirmed |
Essentially changes a single line, removing the unnecessary `os.abspath` call, and wrapping the inner `sys.argv[0]` in a `os.path.realpath` call.