View Bug Activity | Format For Printing
Following discussion at http://cygwin.com/ml/cygwin-xfree/2009-06/msg00010.html, change to using a login bash shell to execute the commands started from the tray menu
Created an attachment (id=4031) Patch to use login bash shell for tray menu commands
Thanks; patch added to the queue for the next release.
Shipped in 1.6.2-1; closing.
Trying the tray menu for the first time in a while, I see that using a login shell is expensive in terms of launch times. If I understand the thread correctly, the problem is only if XWin is launched directly from Windows. Maybe startxwin.{bat,sh} should launch XWin via "bash -l -c" instead, so the environment initialization need occur only once?
Created an attachment (id=4237) patch for ports/xorg/xinit Here is what I am thinking for this bug and bug 10598. Can we use this instead, and revert the patch to xserver?
(In reply to comment #5) > Created an attachment (id=4237) > patch for ports/xorg/xinit > > Here is what I am thinking for this bug and bug 10598. Can we use this > instead, and revert the patch to xserver? Looks good to me. Don't forget that this adds run2 to the dependencies for xinit
(In reply to comment #6) > Looks good to me. > > Don't forget that this adds run2 to the dependencies for xinit That means we depend on both run and run2. Unfortunately run2 is not a drop-in replacement for run (run2 uses XML files instead of command-line arguments), so we'll have to live with that for now.
While I'm at it, I noticed that startxwin.sh (but not the .bat) contains: rm -rf /tmp/.X11-unix Doing that while another XWin display is running is a bad idea. e.g. I use :1 for multiwindow, leaving :0 open for startx launching, and testing startxwin.sh causes clients to be unable to connect to my :1 since the socket no longer exists. I'm going to change that to: rm -f /tmp/.X11-unix/X0 Just like in the .bat, since we explicitly set DISPLAY=127.0.0.1:0.0 earlier in the script.
Shipped in xinit-1.1.1-5 and xorg-server-1.6.4-1; closing.
Created an attachment (id=4253) Tidy ups for system.Xwinrc Dropping this patch has dropped some tiding up in system.Xwinrc; here's a respun patch with just that in it... http://cygwin.com/ml/cygwin-xfree/2009-10/msg00023.html
Oh, and xterm started from the tray menu doesn't seem to inherit the correct environment :-(
(In reply to comment #11) > Oh, and xterm started from the tray menu doesn't seem to inherit the correct > environment :-( Hmm.. mysterious: comparing the output of running 'C:\cygwin\bin\run bash -l -c "env | sort >/tmp/env"' in a DOS shell, and "env | sort >/tmp/Xenv" from system.Xwinrc, the only significant difference seems to be PS1...
(In reply to comment #10) > Created an attachment (id=4253) > Tidy ups for system.Xwinrc > > Dropping this patch has dropped some tiding up in system.Xwinrc; here's a > respun patch with just that in it... FWIW, the default fd.o desktop menu entries launch xterm w/o any options. I'm not sure that we need to cater to anyone's preferences in system.XWinrc; users should be customizing their ~/.XWinrc or ~/.Xdefaults to their tastes. Patch, minus the '-sb' addition, added to the queue.
(In reply to comment #13) > (In reply to comment #10) > > Created an attachment (id=4253) > > Tidy ups for system.Xwinrc > > > > Dropping this patch has dropped some tiding up in system.Xwinrc; here's a > > respun patch with just that in it... > > FWIW, the default fd.o desktop menu entries launch xterm w/o any options. I'm > not sure that we need to cater to anyone's preferences in system.XWinrc; users > should be customizing their ~/.XWinrc or ~/.Xdefaults to their tastes. > > Patch, minus the '-sb' addition, added to the queue. Yes, that's probably the right thing to do. Thanks.
(In reply to comment #12) > (In reply to comment #11) > > Oh, and xterm started from the tray menu doesn't seem to inherit the correct > > environment :-( > > Hmm.. mysterious: comparing the output of running 'C:\cygwin\bin\run bash -l -c > "env | sort >/tmp/env"' in a DOS shell, and "env | sort >/tmp/Xenv" from > system.Xwinrc, the only significant difference seems to be PS1... Learnt something new today: PS1 gets unset by non-interactive bash shells http://git.savannah.gnu.org/cgit/bash.git/tree/shell.c, around line 600 So setting in in /etc/profile and trying to inherit it everywhere isn't going to work :-(
Patch shipped in 1.6.5-1; closing.