GNU bug report logs -
#18698
Our WindowMaker wrapper pollutes PATH in the entire X session
Previous Next
Reported by: Mark H Weaver <mhw <at> netris.org>
Date: Mon, 13 Oct 2014 00:51:02 UTC
Severity: normal
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18698 in the body.
You can then email your comments to 18698 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Mon, 13 Oct 2014 00:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mark H Weaver <mhw <at> netris.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Mon, 13 Oct 2014 00:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Mark
Reply sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
You have taken responsibility.
(Thu, 13 Nov 2014 08:00:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mark H Weaver <mhw <at> netris.org>
:
bug acknowledged by developer.
(Thu, 13 Nov 2014 08:00:04 GMT)
Full text and
rfc822 format available.
Message #10 received at 18698-done <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> netris.org> skribis:
> 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’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 11 Dec 2014 12:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
to
control <at> debbugs.gnu.org
.
(Tue, 10 Feb 2015 10:59:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Tue, 10 Feb 2015 11:03:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 18698 <at> debbugs.gnu.org (full text, mbox):
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.
~~ Ricardo
Information forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Wed, 11 Feb 2015 12:33:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 18698 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <ricardo.wurmus <at> 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.
#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?
Information forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Thu, 12 Feb 2015 20:16:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 18698 <at> debbugs.gnu.org (full text, mbox):
宋文武 <iyzsong <at> gmail.com> skribis:
> Ricardo Wurmus <ricardo.wurmus <at> 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?
> #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?
Thanks,
Ludo’.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 14 Feb 2015 05:16:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Sat, 14 Feb 2015 05:23:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 18698 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> 宋文武 <iyzsong <at> gmail.com> skribis:
>
>> Ricardo Wurmus <ricardo.wurmus <at> 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).
>
>> #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.
>
> Thanks,
> Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#18698
; Package
guix
.
(Sun, 01 Mar 2015 14:40:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 18698 <at> debbugs.gnu.org (full text, mbox):
宋文武 <iyzsong <at> gmail.com> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> 宋文武 <iyzsong <at> gmail.com> skribis:
>>
>>> Ricardo Wurmus <ricardo.wurmus <at> 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 the
global config makes it easy; we need to find a middle ground where we
don’t end up allowing services to do anything. Food for thought...
>>> #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, is
the least undesirable solution.
Thoughts?
Ludo’.
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Tue, 13 Oct 2020 14:44:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mark H Weaver <mhw <at> netris.org>
:
bug acknowledged by developer.
(Tue, 13 Oct 2020 14:44:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 18698-done <at> debbugs.gnu.org (full text, mbox):
Hello,
Mark H Weaver <mhw <at> netris.org> writes:
> 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.
>
> Mark
I tested with the following modifications to our lightweight-desktop
template:
--8<---------------cut here---------------start------------->8---
modified gnu/system/examples/lightweight-desktop.tmpl
@@ -2,6 +2,7 @@
;; for a "desktop" setup without full-blown desktop
;; environments.
+(use-modules (gnu packages gnustep))
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules bootloaders certs ratpoison suckless wm xorg)
@@ -42,7 +43,7 @@
;; the log-in screen with F1.
(packages (append (list
;; window managers
- ratpoison i3-wm i3status dmenu
+ windowmaker
;; terminal emulator
xterm
;; for HTTPS access
--8<---------------cut here---------------end--------------->8---
And I cannot reproduce this. I believe the fix Ludo did 6 years ago in
be05e643ae4d62dc25aa88b7fbdb0eae9cf10eb0 combined with the use of a
xsession file added in commit 537fe4568f4 by Kei resolved this issue for
good.
Closing.
Thanks,
Maxim
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 11 Nov 2020 12:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.