On Fri, Apr 8, 2016 at 7:01 PM, Jamie Zawinski <[email protected]> wrote: > On Fri Apr 08 2016 02:12:12, Tormod Volden wrote: > >> But let me be clear, I am only talking about the part "let's start the >> hack with name X". For running helpers etc it would be nice to have a >> reasonable PATH so xscreensaver-get-images & friends can be found >> without that we force full paths on them, or clumsy soft links in >> /usr/lib/xscreensaver - this would get messy since "friends" can >> involve a lot of dependencies. Is it not possible to say, when X is a >> name in preferences that has no path, to run /usr/lib/xscreensaver/X >> but with full (unmodified) PATH? > > Sorry, I don't understand what you're proposing. Can you give some examples? > > Why do you object to "just set $PATH in whatever script launched > xscreensaver"? That seems simple to me.
I don't object to setting PATH, it seems simple and it would help against the name clashes in /usr/games like zoom. I am just thinking of possible clashes with other programs in /usr/bin as well. There are like 10000 packages in Debian and new ones coming all the time, so it can make sense to "protect" the screensaver from conflicts. Because some hacks execute utilities we are placing in /usr/bin, for instance xscreensaver-get-image (and I think some of these call other utilities also), a modified PATH will still have to include /usr/bin. Since we are placing all hacks into /usr/lib/xscreensaver, we can also restrict the spawning of hacks to this path. Then PATH can be left unmodified, for whatever the hacks need to execute. And in the few cases the user wants to add another executable to his configuration file, he will just have to provide the full path to it. We would simply check hack->command for a starting slash and if none, prepend /usr/lib/xscreensaver. So if the configuration file says "zoom -bla" we would run "/usr/lib/xscreensaver/zoom -bla". If it says "/usr/games/zoom -bla" we would run that. It would be more restrictive but also more fail proof. Tormod
