Trenchbroom: /usr/bin/defaults executable causes TB to crash when launched from the installed .deb

[ericwa]

This is a weird one, but I installed kde-standard on my Ubuntu 20.04 system which pulled in an executable /usr/bin/defaults. This causes TB to crash with an uncaught exception, only if TB is installed in /usr/bin (i.e. if I install the .deb and launch it.) The welcome window comes up but it crashes when I try to create a new map.

(gdb) bt 
#0  0x00007ffff6ac4762 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00005555556eb83f in TrenchBroom::IO::Disk::getDirectoryContents (path=...) at /home/ericwa/TrenchBroom/common/src/IO/DiskIO.cpp:123
#2  0x00005555556eacd3 in TrenchBroom::IO::Disk::fixCase (path=...) at /home/ericwa/TrenchBroom/common/src/IO/DiskIO.cpp:82
#3  0x00005555556eb2ee in TrenchBroom::IO::Disk::fixPath (path=...) at /home/ericwa/TrenchBroom/common/src/IO/DiskIO.cpp:102
#4  0x00005555556eb515 in TrenchBroom::IO::Disk::directoryExists (path=...) at /home/ericwa/TrenchBroom/common/src/IO/DiskIO.cpp:109
#5  0x0000555555848bd4 in TrenchBroom::Model::GameFileSystem::addDefaultAssetPaths (this=0x555556805668, config=..., logger=...)

In frame #1 path is {m_components = std::vector of length 3, capacity 3 = {"usr", "bin", "defaults"}, m_absolute = true}
In frame #4 path is {m_components = std::vector of length 4, capacity 4 = {"usr", "bin", "defaults", "assets"}, m_absolute = true}

It seems like it's looking for the directory called "defaults" next to the TB executable (which is supposed to contain defaults/assets/textures/__TB_empty.png) but not expecting it to be a file instead of a directory, which causes an exception to be thrown

[hemebond]

Same issue on Debian GNU/Linux bullseye/sid.

Just out of curiosity, why is Trenchbroom installing its executable in /usr/bin/ instead of /usr/local/bin/?

[ericwa]

Not sure really, for standalone .deb's is /usr/local/bin more common?

[hemebond]

/usr/local/bin/ is for non-system binaries (user applications, etc). /bin/ and /usr/bin/ should be for system utilities.

[daxim]

/usr/local/bin/ is for non-system binaries

This is true only for unpackaged (i.e. manually compiled) software. The separate hierarchy under local exists so that files installed from manually compiled software do not accidentally trample over the system.

By virtue of packaging, the program becomes system software (that is to say, it is tracked by the package manager) and /usr/bin is the correct place.

I am a packager. See man 7 hier and https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html