Our WindowMaker wrapper pollutes PATH in the entire X session

OpenSubmitted by Mark H Weaver.
Details
4 participants
  • 宋文武
  • Ludovic Courtès
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
normal
M
M
Mark H Weaver wrote on 13 Oct 2014 02:48
(address . bug-guix@gnu.org)
877g04iyku.fsf@yeeloong.lan
We install a wrapper script around WindowMaker that prepends/gnu/store/XXX-windowmaker-XXX/bin to $PATH. This setting is propagatedto all subprocesses in the entire X session, which is suboptimal. Itwould be nice to find another solution, preferably by using absolutepathnames when launching subprocesses run by WindowMaker.
Mark
L
L
Ludovic Courtès wrote on 13 Nov 2014 08:59
(name . Mark H Weaver)(address . mhw@netris.org)(address . 18698-done@debbugs.gnu.org)
87r3x7o7jf.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:
Toggle quote (6 lines)> We install a wrapper script around WindowMaker that prepends> /gnu/store/XXX-windowmaker-XXX/bin to $PATH. This setting is propagated> to all subprocesses in the entire X session, which is suboptimal. It> would be nice to find another solution, preferably by using absolute> pathnames when launching subprocesses run by WindowMaker.
Fixed in be05e64.
Ludo’.
Closed
R
R
Ricardo Wurmus wrote on 10 Feb 2015 11:57
bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session
(address . control@debbugs.gnu.org)
idj61ba6nkh.fsf@bimsb-sys02.mdc-berlin.net
unarchive 18698
R
R
Ricardo Wurmus wrote on 10 Feb 2015 12:01
(address . 18698@debbugs.gnu.org)
idjzj8m58t9.fsf@bimsb-sys02.mdc-berlin.net
The fix may have resulted in unintended side-effects. On a freshinstallation of the System Distribution v0.8.1 WindowMaker is installedby default, but it is not completely functional.
For example, the attempt to change the style via the menu results inthis error to be displayed:
Could not execute command: setstyle /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style
Likewise, selecting "Configure Window Maker" from the right-click menuresults in this error:
Could not execute command: exec WPrefs
The "setstyle" executable is located in/gnu/store/...windowmaker.../bin/, but is not in the PATH.
~~ Ricardo
宋文武 wrote on 11 Feb 2015 13:32
Re: bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session
(address . 18698@debbugs.gnu.org)
87egpwd3wt.fsf@gmail.com
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
Toggle quote (17 lines)> The fix may have resulted in unintended side-effects. On a fresh> installation of the System Distribution v0.8.1 WindowMaker is installed> by default, but it is not completely functional.>> For example, the attempt to change the style via the menu results in> this error to be displayed:>> Could not execute command:> setstyle /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style>> Likewise, selecting "Configure Window Maker" from the right-click menu> results in this error:>> Could not execute command: exec WPrefs>> The "setstyle" executable is located in> /gnu/store/...windowmaker.../bin/, but is not in the PATH.
Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.
Instead of wrapping every executable of session-type, we can:
#1: Add the package to system profile ('packages'). It's not clear to me how to do it now, until we have something like the NixOS's module system.
#2: Make SLiM use '/run/current-system/profile/share/xsessions' as session_dir. So simply add a package providing xsession file to 'packages' should make it available to SLiM. And all DE and many window-managers provide xsession files already (eg: openbox, sawfish, xfce), we can patch the rest (eg: WindowMaker) to install one.
I would like to go #2, WDYT?
L
L
Ludovic Courtès wrote on 12 Feb 2015 21:15
(name . 宋文武)(address . iyzsong@gmail.com)(address . 18698@debbugs.gnu.org)
87y4o2q439.fsf@gnu.org
宋文武 <iyzsong@gmail.com> skribis:
Toggle quote (27 lines)> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:>>> The fix may have resulted in unintended side-effects. On a fresh>> installation of the System Distribution v0.8.1 WindowMaker is installed>> by default, but it is not completely functional.>>>> For example, the attempt to change the style via the menu results in>> this error to be displayed:>>>> Could not execute command:>> setstyle /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style>>>> Likewise, selecting "Configure Window Maker" from the right-click menu>> results in this error:>>>> Could not execute command: exec WPrefs>>>> The "setstyle" executable is located in>> /gnu/store/...windowmaker.../bin/, but is not in the PATH.> Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.>> Instead of wrapping every executable of session-type, we can:>> #1: Add the package to system profile ('packages').> It's not clear to me how to do it now, until we have something> like the NixOS's module system.
What I have in mind is to add a ‘packages’ field in ‘service’. Thatwould allow service implementations to contribute packages to the globalprofile. Thoughts?
Toggle quote (7 lines)> #2: Make SLiM use '/run/current-system/profile/share/xsessions' as> session_dir.> So simply add a package providing xsession file to 'packages' should> make it available to SLiM. And all DE and many window-managers provide> xsession files already (eg: openbox, sawfish, xfce), we can patch> the rest (eg: WindowMaker) to install one.
IIUC the bug initially reported here would remain: the user’s $PATHwould be polluted with the window manager’s stuff, no?
Thanks,Ludo’.
宋文武 wrote on 14 Feb 2015 06:22
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 18698@debbugs.gnu.org)
87h9upm5ih.fsf@gmail.com
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (32 lines)> 宋文武 <iyzsong@gmail.com> skribis:>>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:>>>>> The fix may have resulted in unintended side-effects. On a fresh>>> installation of the System Distribution v0.8.1 WindowMaker is installed>>> by default, but it is not completely functional.>>>>>> For example, the attempt to change the style via the menu results in>>> this error to be displayed:>>>>>> Could not execute command:>>> setstyle /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style>>>>>> Likewise, selecting "Configure Window Maker" from the right-click menu>>> results in this error:>>>>>> Could not execute command: exec WPrefs>>>>>> The "setstyle" executable is located in>>> /gnu/store/...windowmaker.../bin/, but is not in the PATH.>> Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.>>>> Instead of wrapping every executable of session-type, we can:>>>> #1: Add the package to system profile ('packages').>> It's not clear to me how to do it now, until we have something>> like the NixOS's module system.>> What I have in mind is to add a ‘packages’ field in ‘service’. That> would allow service implementations to contribute packages to the global> profile. Thoughts?
It's fine, but we may also need a 'dbus-service' field (for wicd).
Toggle quote (10 lines)>>> #2: Make SLiM use '/run/current-system/profile/share/xsessions' as>> session_dir.>> So simply add a package providing xsession file to 'packages' should>> make it available to SLiM. And all DE and many window-managers provide>> xsession files already (eg: openbox, sawfish, xfce), we can patch>> the rest (eg: WindowMaker) to install one.>> IIUC the bug initially reported here would remain: the user’s $PATH> would be polluted with the window manager’s stuff, no?
I think the 'polluted' means we have a $PATH contains: /gnu/store/xxx-windowmaker/bininstall it to profile doesn't have this issue.
Toggle quote (3 lines)>> Thanks,> Ludo’.
L
L
Ludovic Courtès wrote on 1 Mar 2015 15:39
(name . 宋文武)(address . iyzsong@gmail.com)(address . 18698@debbugs.gnu.org)
874mq4g4t0.fsf@gnu.org
宋文武 <iyzsong@gmail.com> skribis:
Toggle quote (36 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> 宋文武 <iyzsong@gmail.com> skribis:>>>>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:>>>>>>> The fix may have resulted in unintended side-effects. On a fresh>>>> installation of the System Distribution v0.8.1 WindowMaker is installed>>>> by default, but it is not completely functional.>>>>>>>> For example, the attempt to change the style via the menu results in>>>> this error to be displayed:>>>>>>>> Could not execute command:>>>> setstyle /gnu/store/...windowmaker.../share/WindowMaker/Styles/Black.style>>>>>>>> Likewise, selecting "Configure Window Maker" from the right-click menu>>>> results in this error:>>>>>>>> Could not execute command: exec WPrefs>>>>>>>> The "setstyle" executable is located in>>>> /gnu/store/...windowmaker.../bin/, but is not in the PATH.>>> Yes, the $out/bin of windowmaker is not in $PATH, and same for sawfish.>>>>>> Instead of wrapping every executable of session-type, we can:>>>>>> #1: Add the package to system profile ('packages').>>> It's not clear to me how to do it now, until we have something>>> like the NixOS's module system.>>>> What I have in mind is to add a ‘packages’ field in ‘service’. That>> would allow service implementations to contribute packages to the global>> profile. Thoughts?> It's fine, but we may also need a 'dbus-service' field (for wicd).
Hmm right. And dbus policy, and policykit something, and...
Clearly the NixOS way where each service can change anything in theglobal config makes it easy; we need to find a middle ground where wedon’t end up allowing services to do anything. Food for thought...
Toggle quote (13 lines)>>> #2: Make SLiM use '/run/current-system/profile/share/xsessions' as>>> session_dir.>>> So simply add a package providing xsession file to 'packages' should>>> make it available to SLiM. And all DE and many window-managers provide>>> xsession files already (eg: openbox, sawfish, xfce), we can patch>>> the rest (eg: WindowMaker) to install one.>>>> IIUC the bug initially reported here would remain: the user’s $PATH>> would be polluted with the window manager’s stuff, no?> I think the 'polluted' means we have a $PATH contains:> /gnu/store/xxx-windowmaker/bin> install it to profile doesn't have this issue.
Right, but WindowMaker is not necessarily in the user’s profile.
Still, maybe the initial solution, which added WindowMaker to $PATH, isthe least undesirable solution.
Thoughts?
Ludo’.
?