I used bold to get your attention. It worked! I wasn't sure if your project was live because I did a test github push to your ldglite repo back in February that drew no response. So I didn't want to write a lot here if nobody was listening. I don't know of any other working solution on linux, so I'm happy to hear your project is alive.
Anyhow, I'm currently trying to incorporate the LDrawIni code into ldglite to homogenize the part search strategy between it, LDView, and L3p. That code has some "typical" fallback paths for various platforms and I noticed the linux fallback paths are different from the paths used in your wrapper. The LDrawIni code uses /usr/local/share/LDRAW and ~/LDRAW. Your wrapper uses /usr/share/ldraw for the ldraw install and then softlinks ~/.ldraw to that. Personally I prefer the setup in your wrapper because UPPERCASE is a royal pain and should be avoided. And I really like the idea of using softlinks from the home directory to the ldraw installation in the system directory. I've decided that I have to modify the LDrawIni code to make it work for ldglite because of the uppercase thing, so while I'm in there I'll add your paths to the "typical" fallback list (mostly just for me so I can run things without a wrapper).
But I'd like to make some suggestions concerning the ~/.ldraw softlink. I think it'd work better if ~/.ldraw was a real directory and inside it you could make softlinks to the files and directories inside the /usr/share/ldraw directory. That way users could easily override some of the softlinks to point at their own personal files and directories instead. They could have their own personal color setup, personal directories for Unofficial and lsynth parts, etc. For example, I prefer the brighter candy colors in ldcfgalt.ldr so I softlink ~/.ldraw/ldconfig.ldr to that instead of the standard file.
Also, ldglite in LEDIT mode uses the models directory to as the default storage location for the model you're working on. And it uses the bitmaps directory as the default screendump location. So I've softlinked them to point them at ~/Documents and ~/Pictures on my LMDE linux laptop. I suspect nobody uses LEDIT mode but me, but somebody out there could possibly be using ldglite to dump images. LPub3D also creates temporary/working files in the models directory. I don't know about the older lpub4 code, but it might as well.
Here's what I've tried so far on my puppy linux netbook.
# ls -laptr ~/.ldraw/
total 138
drwxrwxrwx 1 root root 135168 2016-03-26 17:30 ../
drwxrwxrwx 1 root root 0 2016-03-26 17:30 bitmaps/
drwxrwxrwx 1 root root 0 2016-03-26 17:31 models/
drwxrwxrwx 1 root root 0 2016-03-26 17:35 unofficial/
-rwxrwxrwx 1 root root 294 2016-03-26 17:52 ldraw.ini
lrwxrwxrwx 1 root root 42 2016-03-26 17:54 p -> /usr/share/ldraw/p
lrwxrwxrwx 1 root root 50 2016-03-26 17:54 parts -> /usr/share/ldraw/parts
lrwxrwxrwx 1 root root 76 2016-03-26 19:30 ldconfig.ldr -> /usr/share/ldraw/ldcfgalt.ldr
drwxrwxrwx 1 root root 4096 2016-03-26 19:30 ./
Hmm, I suppose this could all be in a directory like ~/ldraw and ~/.ldraw could still be a softlink that points either there or at /usr/share/ldraw depending on the users preference for customization. I think that would work with the current wrapper script as is. What do you think?
Don
Anyhow, I'm currently trying to incorporate the LDrawIni code into ldglite to homogenize the part search strategy between it, LDView, and L3p. That code has some "typical" fallback paths for various platforms and I noticed the linux fallback paths are different from the paths used in your wrapper. The LDrawIni code uses /usr/local/share/LDRAW and ~/LDRAW. Your wrapper uses /usr/share/ldraw for the ldraw install and then softlinks ~/.ldraw to that. Personally I prefer the setup in your wrapper because UPPERCASE is a royal pain and should be avoided. And I really like the idea of using softlinks from the home directory to the ldraw installation in the system directory. I've decided that I have to modify the LDrawIni code to make it work for ldglite because of the uppercase thing, so while I'm in there I'll add your paths to the "typical" fallback list (mostly just for me so I can run things without a wrapper).
But I'd like to make some suggestions concerning the ~/.ldraw softlink. I think it'd work better if ~/.ldraw was a real directory and inside it you could make softlinks to the files and directories inside the /usr/share/ldraw directory. That way users could easily override some of the softlinks to point at their own personal files and directories instead. They could have their own personal color setup, personal directories for Unofficial and lsynth parts, etc. For example, I prefer the brighter candy colors in ldcfgalt.ldr so I softlink ~/.ldraw/ldconfig.ldr to that instead of the standard file.
Also, ldglite in LEDIT mode uses the models directory to as the default storage location for the model you're working on. And it uses the bitmaps directory as the default screendump location. So I've softlinked them to point them at ~/Documents and ~/Pictures on my LMDE linux laptop. I suspect nobody uses LEDIT mode but me, but somebody out there could possibly be using ldglite to dump images. LPub3D also creates temporary/working files in the models directory. I don't know about the older lpub4 code, but it might as well.
Here's what I've tried so far on my puppy linux netbook.
# ls -laptr ~/.ldraw/
total 138
drwxrwxrwx 1 root root 135168 2016-03-26 17:30 ../
drwxrwxrwx 1 root root 0 2016-03-26 17:30 bitmaps/
drwxrwxrwx 1 root root 0 2016-03-26 17:31 models/
drwxrwxrwx 1 root root 0 2016-03-26 17:35 unofficial/
-rwxrwxrwx 1 root root 294 2016-03-26 17:52 ldraw.ini
lrwxrwxrwx 1 root root 42 2016-03-26 17:54 p -> /usr/share/ldraw/p
lrwxrwxrwx 1 root root 50 2016-03-26 17:54 parts -> /usr/share/ldraw/parts
lrwxrwxrwx 1 root root 76 2016-03-26 19:30 ldconfig.ldr -> /usr/share/ldraw/ldcfgalt.ldr
drwxrwxrwx 1 root root 4096 2016-03-26 19:30 ./
Hmm, I suppose this could all be in a directory like ~/ldraw and ~/.ldraw could still be a softlink that points either there or at /usr/share/ldraw depending on the users preference for customization. I think that would work with the current wrapper script as is. What do you think?
Don