Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote: On 12/13/13, Zenaan Harkness z...@freedbms.net wrote: Clearly consolekit is started (logout, as well as reboot etc now work), my keyboard shortcuts work etc. This seems ideal - no per-user configuration, and it just works (TM)(C)(R). This stopped working after a recent upgrade, since I too quickly allowed apt to overwrite my change in /etc/pam.d/common-session Practise safe upgrading; always say 'no'. From pam-auth-update(8): If the user specifies that pam-auth-update should override local configuration changes, the locally-modified files will be saved in /etc/pam.d/ with a suffix of .pam-old. Any sign of .pam-old files? Is there any reason that the following, from /usr/share/doc/xfce4-session/README.Debian : * install libpam-ck-connector * put: session optional pam_loginuid.so *before* pam_ck_connector.so in /etc/pam.d/common-session. is _not_ part of the default install for Debian? Consolekit may not be on the system. $ dpkg -S /etc/pam.d/common-session dpkg-query: no path found matching pattern /etc/pam.d/common-session I guess it must be generated by a script or something. What's the process or rather command line command for determining which script created a particular file such as this one? brian@desktop:~$ dpkg -S common-session libpam-runtime: /usr/share/pam/common-session.md5sums libpam-runtime: /usr/share/pam/common-session-noninteractive.md5sums libpam-runtime: /usr/share/pam/common-session libpam-runtime: /usr/share/pam/common-session-noninteractive libpam-runtime's postinst script copies /usr/share/pam/common-session to /etc/pam.d/common-session. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103111927.gj5...@copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 1/3/14, Brian a...@cityscape.co.uk wrote: On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote: On 12/13/13, Zenaan Harkness z...@freedbms.net wrote: Clearly consolekit is started (logout, as well as reboot etc now work), my keyboard shortcuts work etc. This seems ideal - no per-user configuration, and it just works (TM)(C)(R). This stopped working after a recent upgrade, since I too quickly allowed apt to overwrite my change in /etc/pam.d/common-session Practise safe upgrading; always say 'no'. :) My thinking is usually I'm running sid, feedback re default config is sometimes useful to the project and therefore benefits go beyond myself, for a little short term pain. From pam-auth-update(8): If the user specifies that pam-auth-update should override local configuration changes, the locally-modified files will be saved in /etc/pam.d/ with a suffix of .pam-old. Any sign of .pam-old files? Yes, common-session.pam-old is right there, with the missing line. Is there any reason that the following, from /usr/share/doc/xfce4-session/README.Debian : * install libpam-ck-connector * put: session optional pam_loginuid.so *before* pam_ck_connector.so in /etc/pam.d/common-session. is _not_ part of the default install for Debian? Consolekit may not be on the system. That's the point - this line: session optionalpam_ck_connector.so nox11 was already there; I had to add the following line: session optionalpam_loginuid.so I'm wondering why this line (directly above) cannot be included by default - it does say optional after all ??? $ dpkg -S /etc/pam.d/common-session dpkg-query: no path found matching pattern /etc/pam.d/common-session I guess it must be generated by a script or something. What's the process or rather command line command for determining which script created a particular file such as this one? brian@desktop:~$ dpkg -S common-session Ahh thank you. dpkg -S, but with basename not fully qualified path. libpam-runtime: /usr/share/pam/common-session.md5sums libpam-runtime: /usr/share/pam/common-session-noninteractive.md5sums libpam-runtime: /usr/share/pam/common-session libpam-runtime: /usr/share/pam/common-session-noninteractive libpam-runtime's postinst script copies /usr/share/pam/common-session to /etc/pam.d/common-session. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSSZOdZ9fYgPPpU=d-W40Y31xEc2u=+aRs_d2W=ctt6...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 12/13/13, Zenaan Harkness z...@freedbms.net wrote: On 12/13/13, Brian a...@cityscape.co.uk wrote: On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote: What seemed like a good idea, at, the, time ... is longer looking so good. Any ideas why this odd behaviour would appear as it does? You could try following the advice given in /usr/share/doc/xfce4-session/README.Debian This is excellent advice. Please Note: before these experiments, I simply had ~/.xinitrc, and startx worked. However, I was inspired by what is the new/current debian way. On a whim, I removed ~/.xinitrc and ~/.xsession and I have no ~/.xsessionrc . So now things work as well as they did with ~/.xinitrc , but without any ~/.x* files! This is good. Clearly consolekit is started (logout, as well as reboot etc now work), my keyboard shortcuts work etc. This seems ideal - no per-user configuration, and it just works (TM)(C)(R). This stopped working after a recent upgrade, since I too quickly allowed apt to overwrite my change in /etc/pam.d/common-session Is there any reason that the following, from /usr/share/doc/xfce4-session/README.Debian : * install libpam-ck-connector * put: session optional pam_loginuid.so *before* pam_ck_connector.so in /etc/pam.d/common-session. is _not_ part of the default install for Debian? $ dpkg -S /etc/pam.d/common-session dpkg-query: no path found matching pattern /etc/pam.d/common-session I guess it must be generated by a script or something. What's the process or rather command line command for determining which script created a particular file such as this one? TIA Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSSjOzuGbyf=2d=B3RkcCuHmtcnWjb91BPGmOs=4+hp...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 2013-12-12 00:21:18 -0700, Bob Proulx wrote: 2.1 xdm graphical login manager (or gdm, or kdm, or lightdm, or other) Runs /etc/X11/Xsession Redirects output to .xsession-errors [...] Not for gdm3 3.5.2+. $XDG_CACHE_HOME/gdm/session.log is now used, but this is currently a bit confidential. :) See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691498 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729574 about the changes that need to be done in the documentation. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131229003255.ga32...@xvii.vinc17.org
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, Dec 12, 2013 at 02:23:48PM +, Brian wrote: On Thu 12 Dec 2013 at 00:21:18 -0700, Bob Proulx wrote: The man page for Xsession documents ~/.xsessionrc and ~/.xsession. It says that ~/.xsessionrc is only for setting variables and the ~/.xsession is for executing commands. (But in reality this is a grey area.) Let's attempt to get a colour transformation to black and white. :) Firstly: .xsessionrc is for holding ***global environment*** variables. The emphasis is mine. Secondly: 40x11-common_xsessionrc in /etc/X11/Xsession.d is sourced before 50x11-common_determine-startup. So .xsessionrc is read before .xsession and any environment variables set will become available to applications run by the commands in .xsession. Thirdly: Everyone likes a test to do. :) Create .xsessionrc with contents similar to these: xterm TZ='GST-10' ; export TZ exec a window manager Now execute 'startx'. You have a functioning system? Execute 'date'. Putting commands in .xsessionrc is very naughty. Are you still there, Charlie? For your own good, please stop doing it. JFTR, I am running FVWM and have the following: tal% less .xsessionrc /home/chrisb/background.sh xterm -fn 10x20 -xrm XTerm.vt100.background: #CCA8AA -xrm \ XTerm.vt100.foreground: blue -geom 120x15 tal% I use startx. If I rename .xsessionrc to .xsession then X bails out on starting and I am returned back to the prompt. I had to change .xinitrc to .xsessionrc at some stage in the past when some system change was altered. I can't remember whether it was an upgrade of FVWM or an upgrade of X which caused this. I do remember this issue in the past, a google was not very helpful - and may even have been misleading - e.g. suggesting that .xsessionrc was the correct file to use. And since .xsession or .xinitrc didn't work I must have assumed it was correct. So it seems I'm going to have to go through the startup sequence *again* and try to figure out why X/FVWM won't start with a .xsession file. :( Thanks Brian for putting me on the right path, although it is with mixed blessings :) -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131214172952.GC9143@tal
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Sun, 15 Dec 2013 06:29:52 +1300 Chris Bannister sent: I do remember this issue in the past, a google was not very helpful - and may even have been misleading - e.g. suggesting that .xsessionrc was the correct file to use. And since .xsession or .xinitrc didn't work I must have assumed it was correct. That would have been the reason why I also changed to ~/.xsessionrc. Because I was using FVWM at the time and recall that it was documented somewhere to get X working was to change the file name. On another note, same topic. In Xfce4 which I'm now using, something strange happened. To get my printer working, I changed a few things and then logged out on the application menu drop down list Log Out Then logged back in as user. All the things that my ~/.xsession file loaded, came up again as I would expect. However, they came up twice. Two of everything? I thought it was a glitch. Stopped the computer, did a hard reboot and it did the same, everything came up twice. So I commented everything out of my ~/.xsession file except: exec startxfce4 So my system starts as it always did, loading all the applications as it did when they were so directed in the ~/.xsession file. Nicer in fact, as it places kalarm in the panel rather than on the desktop from whence I placed it into the panel. But they were all commented out?? So, it seems using the Xfce4 logout, wrote a file that gets loaded automagically which returns everything to as it was when X is started again? But what file? There is no duplicate ~/.xsession file so there must be a file elsewhere in the system that Log Out wrote or edited before exiting? It works well as long as I comment out everything I want loaded at startup in my ~/.xsession file. But is it a feature or a bug if I don't know where the file that does is all this is located? I have been looking through this thread to try to find which file might be changed but had no luck yet. Charlie -- Registered Linux User:- 329524 *** Christmas is not a date. It is a state of mind. - Mary Ellen Chase *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131215071705.44f71947@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Sun 15 Dec 2013 at 06:29:52 +1300, Chris Bannister wrote: JFTR, I am running FVWM and have the following: tal% less .xsessionrc /home/chrisb/background.sh xterm -fn 10x20 -xrm XTerm.vt100.background: #CCA8AA -xrm \ XTerm.vt100.foreground: blue -geom 120x15 tal% You start an xterm. Remember that a script executes each line sequentially and only moves on to the next line if the previous command completes. The xterm is put in the background; the command has completed. There is no next line in .xsessionrc so /etc/X11/Xsession moves on from 40x11-common_xsessionrc to 50x11-common_determine-startup. Here it first looks for ~/.xsession. You haven't got one so it goes on to investigate /usr/bin/x-window-manager. This file links to x-window-manager in /etc/alternatives. I bet this points to fvwm in your case! All is right with the world; so you think :). I use startx. If I rename .xsessionrc to .xsession then X bails out on starting and I am returned back to the prompt. From xinit(1) The xinit program is used to start the X Window System server and a first client program . . . Once that client program completes execution xinit exits; that is, X goes away. Your .xsession contains a single backgrounded command. Guess what? [Snip] So it seems I'm going to have to go through the startup sequence *again* and try to figure out why X/FVWM won't start with a .xsession file. :( Put exec fvwm after the xterm command in .xsession. This command does not complete and .xsession doesn't close. You've summoned X, give it a chance to show off what it can do :). Thanks Brian for putting me on the right path, although it is with mixed blessings :) Bob Proulx posts were the inspiration. Although I had sorted out the use of startx to my satisfaction many years ago, his recent mails caused me to look again at how Debian handled it. MORAL: ,xsession - good. .xinitrc or .xessionrc - bad (unless you really know what you are doing and have special needs). EXERCISE: You decide 'exec fvwm' is a splendid idea but decide to keep your .xsessionrc and put the extra line in it. Discuss the consequences. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131214202556.gn5...@copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 12/12/13, Bob Proulx b...@proulx.com wrote: Hi Bob, your detailed replies are appreciated. I have been trying to get a setup that works properly with startx, as well as with kdm. Do you have a recommendation as to how best to achieve this - the amount of pathways and possibilities is not conducive to holding in my mind at the same time to answer this question. I have experimented with a couple combinations, but there are too many. I have at the moment, startx working well, with .xinitrc and .xsession both linking to the same file (bash script, with my exec ... line). When I log in, sudo service start kdm, then login to graphical desktop from kdm, I again have this reduced functionality. It would be good if there were a consistent, single, way, to get both startx after linux terminal login, as well as kdm/etcdm graphical login working as well. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSQP1Q_FrZHY29r76aZtAXtkTSgnX4nqsR=p33etmc-...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
I wonder, in Debian does a path exist so that if a user wants to install a g.u.i. environment without gdm and with startX so that they can run in console mode by default and when they want to go g.u.i. they run startX to do it and have orca start up after that automatically? If so, I'd like to learn how to do that. jude jdash...@shellworld.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.bsf.2.01.1312120327170.4...@freire1.furyyjbeyq.arg
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 12/12/13, Jude DaShiell jdash...@shellworld.net wrote: I wonder, in Debian does a path exist so that if a user wants to install a g.u.i. environment without gdm and with startX so that they can run in console mode by default and when they want to go g.u.i. they run startX to do it and have orca start up after that automatically? If so, I'd like to learn how to do that. Perhaps re-read this thread (and the other similar one) again in detail. This is exactly what I'm doing. Or if you want simple answer: create ~/.xinitrc or ~/.xsession and make the file look like mine (see earlier in this or the other similar thread), and put those things you want to auto-start prior to exec line. Also, you should perhaps have started a new thread, given that your question is a new topic. Hopefully the above answers your question, if not, start a new thread please. But first have a go, and if you fail to achieve what you want, then tell in your thread, what you wanted, what you did, and what the error or failure was. It looks much more appealing to others when you have already had a go, and failed. Good luck Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSQODHSujvjej1Y0ES6=6ozj9v+k0gktl-xfbksbyro...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, 12 Dec 2013 00:28:54 -0700 Bob Proulx sent: No it really should be ~/.xsession. This can be deduced by inspecting the /etc/X11/Xsession.d/50x11-common_determine-startup file. Or see the man page such as these snippets from it. That's what I had for years but then something must have come up to make me rename the file to~/.xsessionrc Maybe it was when I booted and it said it couldn't read ~/.xsessionrc? It had to be something on the system that demanded it, and it had to be Debian of one version or another because that's all I have used for about 10 years? I might just revert it back to ~/.xsession and see what error messages I receive, if any? Thanks Charlie -- Registered Linux User:- 329524 *** Of the whole rabble of thieves, fools are the worst; for they rob you of both time and peace of mind. - Goethe *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131212221831.512c8d64@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, 12 Dec 2013 00:28:54 -0700 Bob Proulx sent: /etc/X11/Xsession.d/40x11-common_xsessionrc Source global environment variables. This script will source anything in $HOME/.xsessionrc if the file is present. This allows the user to set global environment variables for their X session, such as locale information. Maybe that's what I read? Anyway, I renamed the file ~/.xsession and the system booted without problems. I thought it took a little longer but that was probably my imagination as I expected it to fail. Thanks for the good information. Charlie -- Registered Linux User:- 329524 *** Of the whole rabble of thieves, fools are the worst; for they rob you of both time and peace of mind. - Goethe *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013121849.12886d19@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu 12 Dec 2013 at 00:21:18 -0700, Bob Proulx wrote: The man page for Xsession documents ~/.xsessionrc and ~/.xsession. It says that ~/.xsessionrc is only for setting variables and the ~/.xsession is for executing commands. (But in reality this is a grey area.) Let's attempt to get a colour transformation to black and white. :) Firstly: .xsessionrc is for holding ***global environment*** variables. The emphasis is mine. Secondly: 40x11-common_xsessionrc in /etc/X11/Xsession.d is sourced before 50x11-common_determine-startup. So .xsessionrc is read before .xsession and any environment variables set will become available to applications run by the commands in .xsession. Thirdly: Everyone likes a test to do. :) Create .xsessionrc with contents similar to these: xterm TZ='GST-10' ; export TZ exec a window manager Now execute 'startx'. You have a functioning system? Execute 'date'. Putting commands in .xsessionrc is very naughty. Are you still there, Charlie? For your own good, please stop doing it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12122013134425.ed01b12c8...@desktop.copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote: What seemed like a good idea, at, the, time ... is longer looking so good. Any ideas why this odd behaviour would appear as it does? You could try following the advice given in /usr/share/doc/xfce4-session/README.Debian Selectively quoting we have * only use startx, without any argument * don't use a .xinitrc, use .xsession and later Then you need to fine-tune your pam installation so ConsoleKit can be sure that your user is correctly authenticated. For that, you need to: * install libpam-ck-connector * put: session optional pam_loginuid.so *before* pam_ck_connector.so in /etc/pam.d/common-session. This works for me. In the meantime, it looks like I'll have to go back to using .xinitrc Then your X session is probably not set up correctly so you will have to deal with that in the .xinitrc. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12122013162850.a92e51918...@desktop.copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
May we look a little closer at one or two of the things you say? On Wed 11 Dec 2013 at 23:36:51 -0700, Bob Proulx wrote: Because startx does not use .xsession. You have things criss-crossed. 1. Running startx basically runs xinit. 2. startx first looks for ~/.xinitrc which, unless there is a very good reason, should not be on a Debian system. 3. startx now searches for the system xinitrc in /etc/X11/xinit/. This contains the line . /etc/X11/Xsession and Xsession will use ~/.xsession if it exists. So startx on Debian uses .xsession :). However, it does not consult it directly. $ grep xsession /usr/bin/startx ... nothing shown ... grep xinit /usr/bin/startx The xsession script is only used by the xdm, gdm, gdm3, kdm, lightdm X Display Manager graphical login manager programs because they all call the /etc/X11/Xsession script. Please see above. Yes, because startx does use xinitrc. Indeed it does. It goes on to use /etc/X11/Xsession. :) If you are using startx then yes you should use xinitrc. Only use the xsession or xsessionrc file (either one) if you are using one of the graphical login managers such as xdm, gdm, gdm3, kdm, lightdm. Should some of the xs have a '.' in front of them? startx and .xsession should (except in exceptional circunstances) be found together. A good way to foul a system up is to use .xinitrc or .xsessionrc by itself with startx because the files in /etc/X11/Xsession.d then do not get used. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131212175255.gl5...@copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu 12 Dec 2013 at 19:06:41 +1100, Zenaan Harkness wrote: I have been trying to get a setup that works properly with startx, as well as with kdm. Do you have a recommendation as to how best to Your original query concerned startx only. You have now escalated the problem to include kdm :). I'm unsure that helps. I have experimented with a couple combinations, but there are too many. Keep .xsession as a contant. You know it makes sense. I have at the moment, startx working well, with .xinitrc and .xsession both linking to the same file (bash script, with my exec ... line). The mind boggles! :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12122013183708.45a193383...@desktop.copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu 12 Dec 2013 at 22:18:31 +1100, Charlie wrote: [When talking about .xsessionrc versus .xsession] I might just revert it back to ~/.xsession and see what error messages I receive, if any? You won't get any error messages. The system will execute valid commands in .xessionrc just as well as does those in .xsession. Whether the system is at rights with itself is a different matter. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12122013190637.267509b6e...@desktop.copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu 12 Dec 2013 at 17:47:12 +1100, Charlie wrote: I'm happy with what happens when I boot my system - same as when I used .xsessionrc with FVWM. But will look into it and read a bit when time permits. I could be doing the wrong thing entirely. You are. But you will never know until you encounter a problem and don't recognise it as a misunderstanding of what Debian's X configuration is intended to do. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12122013192326.d4bc8a2b1...@desktop.copernicus.demon.co.uk
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, 12 Dec 2013 14:23:48 + Brian sent: Putting commands in .xsessionrc is very naughty. Are you still there, Charlie? For your own good, please stop doing it. I've renamed the file to ~/.xsession after reading the information Bob kindly supplied and it's all working great, as normal. Thanks, Charlie -- Registered Linux User:- 329524 *** A dream grants what one covets when awake. - German proverb *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213082604.2a2e5ae2@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, 12 Dec 2013 19:13:50 + Brian sent: [When talking about .xsessionrc versus .xsession] I might just revert it back to ~/.xsession and see what error messages I receive, if any? You won't get any error messages. The system will execute valid commands in .xessionrc just as well as does those in .xsession. Whether the system is at rights with itself is a different matter. As your say, no errors. Charlie -- Registered Linux User:- 329524 *** One reason I don't drink is that I want to know when I'm having a good time. - Lady Astor *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131213083104.3abb6e8c@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On 12/13/13, Brian a...@cityscape.co.uk wrote: On Thu 12 Dec 2013 at 17:23:31 +1100, Zenaan Harkness wrote: What seemed like a good idea, at, the, time ... is longer looking so good. Any ideas why this odd behaviour would appear as it does? You could try following the advice given in /usr/share/doc/xfce4-session/README.Debian This is excellent advice. Please Note: before these experiments, I simply had ~/.xinitrc, and startx worked. However, I was inspired by what is the new/current debian way. On a whim, I removed ~/.xinitrc and ~/.xsession and I have no ~/.xsessionrc . So now things work as well as they did with ~/.xinitrc , but without any ~/.x* files! This is good. Clearly consolekit is started (logout, as well as reboot etc now work), my keyboard shortcuts work etc. This seems ideal - no per-user configuration, and it just works (TM)(C)(R). Thanks Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSQKciExJDwZB12QTbQQ1Md2JsJMYkYyH0==-ij=vls...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
Brian wrote: May we look a little closer at one or two of the things you say? Bob Proulx wrote: Because startx does not use .xsession. You have things criss-crossed. Oops! I was definitely wrong with that statement. 1. Running startx basically runs xinit. 2. startx first looks for ~/.xinitrc which, unless there is a very good reason, should not be on a Debian system. 3. startx now searches for the system xinitrc in /etc/X11/xinit/. This contains the line . /etc/X11/Xsession and Xsession will use ~/.xsession if it exists. So startx on Debian uses .xsession :). However, it does not consult it directly. Yes. My bad. I was confused! :-( Thanks for the correction. Bob signature.asc Description: Digital signature
startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
My .xsession is mode 755 and contains: --- #!/bin/bash --login exec ck-launch-session startxfce4 --- When I run startx, my xfce4 session starts, but Restart, Shutdown, Suspend and Hibernate are all disabled, only Logout is enabled. When I do: cd; cp .xsession .xinitrc startx my xfce4 session starts, and all the Restart, Logout etc options are now enabled. What seemed like a good idea, at, the, time ... is longer looking so good. Any ideas why this odd behaviour would appear as it does? In the meantime, it looks like I'll have to go back to using .xinitrc TIA Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caosgnsqaxchwyy33us+vshgzmrxxbkdpjtuuq-cejmyfmra...@mail.gmail.com
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
Zenaan Harkness wrote: My .xsession is mode 755 and contains: --- #!/bin/bash --login exec ck-launch-session startxfce4 --- When I run startx, ... Because startx does not use .xsession. You have things criss-crossed. $ grep xsession /usr/bin/startx ... nothing shown ... The xsession script is only used by the xdm, gdm, gdm3, kdm, lightdm X Display Manager graphical login manager programs because they all call the /etc/X11/Xsession script. $ grep -rl xsession /etc/X11/Xsession* /etc/X11/Xsession /etc/X11/Xsession.d/40x11-common_xsessionrc /etc/X11/Xsession.d/50x11-common_determine-startup /etc/X11/Xsession.options my xfce4 session starts, but Restart, Shutdown, Suspend and Hibernate are all disabled, only Logout is enabled. I remember reading about people complaining about that happening but I don't remember the detail as to why. When I do: cd; cp .xsession .xinitrc startx my xfce4 session starts, and all the Restart, Logout etc options are now enabled. Yes, because startx does use xinitrc. $ grep xinitrc /usr/bin/startx # interface than xinit. It looks for user .xinitrc and .xserverrc # files, then system xinitrc and xserverrc files, else lets xinit choose # its default. The system xinitrc should probably do things like check userclientrc=$HOME/.xinitrc sysclientrc=/etc/X11/xinit/xinitrc What seemed like a good idea, at, the, time ... is longer looking so good. Any ideas why this odd behaviour would appear as it does? Frankly it is exactly as I wrote in the previous message about this. :-) Really! :-) In the meantime, it looks like I'll have to go back to using .xinitrc If you are using startx then yes you should use xinitrc. Only use the xsession or xsessionrc file (either one) if you are using one of the graphical login managers such as xdm, gdm, gdm3, kdm, lightdm. Bob signature.asc Description: Digital signature
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Thu, 12 Dec 2013 17:23:31 +1100 Zenaan Harkness sent: My .xsession is mode 755 and contains: --- #!/bin/bash --login exec ck-launch-session startxfce4 I may be wrong but shouldn't that be .xsessionrc? Charlie -- Registered Linux User:- 329524 *** When a stupid man is doing something he is ashamed of, he always declares that it is his duty. - George Bernard Shaw *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131212173618.6fbda8d3@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
On Wed, 11 Dec 2013 23:36:51 -0700 Bob Proulx sent: If you are using startx then yes you should use xinitrc. I use startx and have an .xsessionrc file that loads all manner of things for me at start up. [gkrelm,terminals,kalarm etc.,] It works for me, copied from FVWM. Now using Xfce4 as FVWM on AMD64 isn't all that nice, and I can't configure it to make it nice again. My problem and no time to work with it at the moment. I didn't realise that xinitrc is the way to go? I'm happy with what happens when I boot my system - same as when I used .xsessionrc with FVWM. But will look into it and read a bit when time permits. I could be doing the wrong thing entirely. Thanks for the information. Charlie -- Registered Linux User:- 329524 *** A dream grants what one covets when awake. - German proverb *** Debian GNU/Linux - just the best way to create magic - -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131212174712.58246bf8@taogypsy.wildlife
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
Charlie wrote: Bob Proulx sent: If you are using startx then yes you should use xinitrc. I use startx and have an .xsessionrc file that loads all manner of things for me at start up. [gkrelm,terminals,kalarm etc.,] It works for me, copied from FVWM. Now using Xfce4 as FVWM on AMD64 isn't all that nice, and I can't configure it to make it nice again. My problem and no time to work with it at the moment. I am not quite following. You say you have startx and a .xsessionrc file. And this is working for you? Sounds like it is. In which case I don't know how. But then you say that you can't configure it so I am not sure. I didn't realise that xinitrc is the way to go? Not quite. There are many layers and many choices available. With startx the documented interface is ~/.xinitrc or ~/.xsessionrc or ~/.xsession. The man page only documents the ~/.xinitrc file. man startx But since startx chains off to /etc/X11/xinit/xinitrc which chains off to /etc/X11/Xsession then all of the customization of Xsession is also available through the daisy chain. man Xsession The man page for Xsession documents ~/.xsessionrc and ~/.xsession. It says that ~/.xsessionrc is only for setting variables and the ~/.xsession is for executing commands. (But in reality this is a grey area.) In order to get the entire list of possibilities you would need to connect across from one man page to the next as one references the next one in the next layer. Or you could keep it simple and use the one that the command documents first. But the reality is that one chains to the other and so both are possible. I'm happy with what happens when I boot my system - same as when I used .xsessionrc with FVWM. But will look into it and read a bit when time permits. I could be doing the wrong thing entirely. The choice of customization file is not an attribute of the window manager. It isn't tied to fvwm nor xfce. The choice of customization file is tied to how X is started. After X is started then any of the window managers or desktop sessions may be started after that point. Let me try to explain this in a slightly different way. 1.1. xinit command line Uses ~/.xinitrc 1.2. startx command line (wrapper around xinit for reasonable defaults) Uses ~/.xinitrc if exists Otherwise uses /etc/X11/xinit/xinitrc /etc/X11/xinit/xinitrc sources /etc/X11/Xsession Redirects output to .xsession-errors sources ~/.xsessionrc if exists executes ~/.xsession if executable, sources if not, if exists 2.1 xdm graphical login manager (or gdm, or kdm, or lightdm, or other) Runs /etc/X11/Xsession Redirects output to .xsession-errors sources ~/.xsessionrc if exists executes ~/.xsession if executable, sources if not, if exists These are all scripts so very easy to trace through. I highly recommend that if anyone is still confused that they simply read through the scripts and see for themselves what they do. Then there is nothing between the scripts and your understanding of them. The /usr/bin/startx script is a relatively small and simple script. I would not call it beautiful. But it is easy reading. I suggest that if there anyone is wondering what is going on with startx that it is easier to browser the script and look. Then all doubt can be removed. less /usr/bin/startx Or they could trace through the running of the script when they start it. sh -x /usr/bin/startx 21 | tee startx.out That will show all of the commands run by the script and will save them to the file. Then browsing the file should reveal all that is happening in the script. Being a script is an advantage at times like this because it makes it simple to see what it is doing. How did I know it was a script? It has been one forever. And I always look. Because may commands are scripts. If they then I browse through them to see what is in them. Bob signature.asc Description: Digital signature
Re: startx + ~/.xsession and no ~/.xinitrc, results in reduced functionality (xfce4, sid)
Charlie wrote: On Thu, 12 Dec 2013 17:23:31 +1100 Zenaan Harkness sent: My .xsession is mode 755 and contains: --- #!/bin/bash --login exec ck-launch-session startxfce4 I may be wrong but shouldn't that be .xsessionrc? No it really should be ~/.xsession. This can be deduced by inspecting the /etc/X11/Xsession.d/50x11-common_determine-startup file. Or see the man page such as these snippets from it. $ man Xsession /etc/X11/Xsession.d/40x11-common_xsessionrc Source global environment variables. This script will source anything in $HOME/.xsessionrc if the file is present. This allows the user to set global environment variables for their X session, such as locale information. /etc/X11/Xsession.d/50x11-common_determine-startup Determine startup program. The X client to launch as the con- trolling process (the one that, upon exiting, causes the X server to exit as well) is determined next. If a program or failsafe argument was given and is allowed (see above), it is used as the controlling process. Otherwise, if the line ‘allow-user-xsession’ is present in Xsession.options, a user-specified session program or script is used. In the latter case, two historically popular names for user X session scripts are searched for: $HOME/.xsession and $HOME/.Xsession (note the difference in case). The first one found is used. If the script is not executable, it is marked to be executed with the Bourne shell interpreter, sh. Finally, if none of the above succeeds,thefollowing programs are searched for: /usr/bin/x-session-manager,/usr/bin/x-window-manager,and /usr/bin/x-terminal-emulator. The first one found is used. If none are found, Xsession aborts with an error. And so we see that ~/.xesssionrc is intended to be used to set variables. Therefore almost anything in the .profile or .bashrc should be reasonable. But for X session scripts such as starting xfce then the ~/.xsession script is the documented interface. (However I would be the first to volunteer that the above is a complicated description! It is accurate. But now you know why I think reading the script itself is simpler than the documentation of it.) Bob signature.asc Description: Digital signature
