From: Karsten Z. <kar...@t-...> - 2011-03-26 19:09:19
|
Hi everyone, what do I have to do to get the keyboard sticky? I've tried xkbset sticky twokey latchlock but here the stickyness is gone everytime when I reboot the system. As a workaround I tried to put it in the crontab and repeated it every minute, but that didn't work, I don't know why, I inserted '* * * * * xkbset sticky twokey latchlock' after I typed 'crontab -e' I think it's the normal command to give in a cronjob. So can anybody give me a hint what I made wrong? -- Mit freundlichen Grüßen Karsten Zarth PS: Die Antwort ist Linux! Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ |
From: Jonathan M. <jma...@fa...> - 2011-03-26 19:35:25
|
On 03/26/2011 12:09 PM, Karsten Zarth wrote: > what do I have to do to get the keyboard sticky? I've tried > > xkbset sticky twokey latchlock > > but here the stickyness is gone everytime when I reboot the system. ... I think the right place to do this would be in your ~/.profile or maybe ~/.xsession file or similar, so that it is run each time you log in. I suspect that, when run from cron, there is no X session involved, so xkbset can't set any X related things at that point. You can also look at editing /etc/default/console-setup or /etc/default/keyboard to set the relevant XKBOPTIONS so that the change is remembered across reboots. Jonathan |
From: Stephan S. <gma...@sp...> - 2011-03-27 06:04:54
|
Of course, but why bother when the correct solution is to just run the tool once each time an LXDE session is started. On 27/03/11 01:57 AM, Dan Muresan wrote: >> Jonathan, the "no X session involved" part with cron is actually more >> correct than you might have guessed. Not only is cron launched before >> X-related environment variables are set, I think I remember reading that >> most cron implementations actually limit the environment passed to >> cronjobs for security reasons. > > You could always save the relevant variables ($DISPLAY, $XAUTHORITY, > $XDG_SESSION_COOKIE, $DBUS_SESSION_BUS_ADDRESS -- depends on what you > need) in a file at X session startup, and load that file from your > cronjob. Doesn't work if you might have multiple Xs running (then > again most window / desktop managers don't support that either). > > So that would not be an obstacle... > |
From: <u-l...@ae...> - 2011-03-27 13:42:53
|
Hi Dan, On Sun, Mar 27, 2011 at 09:25:46AM +0300, Dan Muresan wrote: > > Of course, but why bother when the correct solution is to just run the > > tool once each time an LXDE session is started. > > "For the benefit of future searchers" as they say. Of course, in this I am quite convinced that it is crucial for the benefit of future searcher to point out that crontab is a _wrong_ tool and approach for configuration of X-sessions. Otherwise you encourage people to think wrong. The future searchers :) please do not use cron for X-session configuration. It is like using of a pot of flowers for a door stop. It may work somehow if you insist but it should never be used. There are tools in place which are door stops. A pot of flowers will be a bad door stop no matter what. > case there's a simpler solution. Your previous comment made it appear > that it was impossible to control X from a cron job, so I just wanted > to straighten out the record -- someone might need that and think it's > not possible. It is possible of course but a wrong approach. There are zillions of ways to do wrong and just few ones which are reasonable. Dan, you apparently have insight in the many possibilities. Alas, without such insight (which a casual searcher lacks) even correct information may become misleading. Best regards, Rune |
From: Dan M. <da...@gm...> - 2011-03-27 14:13:56
|
My original reply was only meant as a side note, and definitely not to hijack this thread... Rune, I was NOT referring to any kind of X configuration which may be accomplished properly. I was, instead, describing how to control (or launch) X programs from outside the X session -- be it from a separate console login, from a cron job, from a daemon, or from anywhere else. It can be a useful and proper trick, and it's a nice feature of Unix/X. As Linux is becoming more and more packaged in standard-sized boxes and wrapped in shiny colored paper, it's good to be aware that one still CAN do this kind of stuff (which doesn't necessarily mean one SHOULD do it). If you're arguing that advanced information should only be provided to the "undiscerning masses" with proper context, I see no danger of that -- this thread already contains the proper solution. Phew... </rant>. Other than that, of course I agree with you (and Stephan) -- use the best, most reliable and simplest tool for the job. Best, Dan |
From: Stephan S. <gma...@sp...> - 2011-03-27 03:28:10
|
Karsten, the simplest solution would be to either create or edit ~/.config/lxsession/autostart and add "@xkbset sticky twokey latchlock" (Replace the "LXDE" portion with "Lubuntu" if on Lubuntu) Jonathan, the "no X session involved" part with cron is actually more correct than you might have guessed. Not only is cron launched before X-related environment variables are set, I think I remember reading that most cron implementations actually limit the environment passed to cronjobs for security reasons. On 26/03/11 03:35 PM, Jonathan Marsden wrote: > On 03/26/2011 12:09 PM, Karsten Zarth wrote: > >> what do I have to do to get the keyboard sticky? I've tried >> >> xkbset sticky twokey latchlock >> >> but here the stickyness is gone everytime when I reboot the system. ... > > I think the right place to do this would be in your ~/.profile or maybe > ~/.xsession file or similar, so that it is run each time you log in. > > I suspect that, when run from cron, there is no X session involved, so > xkbset can't set any X related things at that point. > > You can also look at editing /etc/default/console-setup or > /etc/default/keyboard to set the relevant XKBOPTIONS so that the change > is remembered across reboots. > > Jonathan > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar |
From: Martin B. / b. <br...@bs...> - 2011-03-29 22:47:14
|
On Sat, 26 Mar 2011, Stephan Sokolow wrote: > I think I remember reading that > most cron implementations actually limit the environment passed to > cronjobs for security reasons. yes. to see this in action add a cron job that dumps the environment to a file * * * * * env > /tmp/hello -- /brother http://martin.bagge.nu Albert Einstein wears Bruce Schneier pajamas |
From: Dan M. <da...@gm...> - 2011-03-27 05:57:43
|
> Jonathan, the "no X session involved" part with cron is actually more > correct than you might have guessed. Not only is cron launched before > X-related environment variables are set, I think I remember reading that > most cron implementations actually limit the environment passed to > cronjobs for security reasons. You could always save the relevant variables ($DISPLAY, $XAUTHORITY, $XDG_SESSION_COOKIE, $DBUS_SESSION_BUS_ADDRESS -- depends on what you need) in a file at X session startup, and load that file from your cronjob. Doesn't work if you might have multiple Xs running (then again most window / desktop managers don't support that either). So that would not be an obstacle... -- Dan Muresan http://alumnus.caltech.edu/~muresan/ |
From: Dan M. <da...@gm...> - 2011-03-27 06:25:54
|
> Of course, but why bother when the correct solution is to just run the > tool once each time an LXDE session is started. "For the benefit of future searchers" as they say. Of course, in this case there's a simpler solution. Your previous comment made it appear that it was impossible to control X from a cron job, so I just wanted to straighten out the record -- someone might need that and think it's not possible. -- Dan Muresan http://alumnus.caltech.edu/~muresan/ |