most efficient way to consistantly monitor an event?


im running a laptop with a docking station, and found a command that will switch between monitors. ‘xrandr’ to be precise.

instead of assigning it to a key, or a script file thats manually run and toggles the command, i’m thinking of either having a command/script ran on a system even (ie: detection of an external monitor), or to be constantly (every few seconds?) ran to monitor external display connectivity.

‘xrandr | grep …’ will report if it detects an external monitor.

im not sure whats possible with linux since i am fairly new to it, but im thinking a cron job that is ran every x seconds. that would be the most straight forward. if there is a way to have the system trigger a script file on an event, this would be even better as it saves on system resources and is probably the cleaner way of doing so.

i hope what i want todo makes sense - can anyone give me a guiding light please?


There may be a thread here that can help you : auto-turn off LCD with ext. display (what does this script actually do?)

Hope it can help. :wink:

thats my thread :wink:

command didnt work for me; no effect at all!
plus that has the downside of only be effective at boot stage.

i currently have 2 .sh files on my desktop that i run manually - i can do so at any time i wish. and although very buggy (either gnome or xrandr doesnt refresh the screen and i have to use crtl+alt+backspace to recover) it does work! would be useful if i could get SUSE to auto detect when the external screen is connected so it’s a completely hands-off process.

i’ll do some more digging about the gnome/xrandr crash issue… it’s also beyond the scope of this thread…

Oh, sorry, I didn’t notice it was the same poster… :stuck_out_tongue:

When you would have read

man crontab

you would have seen that the specification of time in cron is in minutes. Thus your whish to do this every few seconds can not be fullfilled by cron.

I do not know if it would increase my understanding of your problem, but what is a *.sh *file (of which you say you have two of them)?

Do you see an event in the logs (/var/log/) when the switch occurs or
you undock?

Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel
up 21:16, 3 users, load average: 0.16, 0.11, 0.11
GPU GeForce 8600 GTS Silent - Driver Version: 256.35

.sh = shell script (could be wrong on that though). i beleive it’s to replace the aging BASH shell.

looks like /var/log/messages could detect docking station activity.

Jul 15 22:14:37 linux-2z24 kernel:  2910.611512] usb 1-4: USB disconnect, address 3
Jul 15 22:14:37 linux-2z24 kernel:  2910.611520] usb 1-4.4: USB disconnect, address 5
Jul 15 22:14:37 linux-2z24 kernel:  2910.611525] usb 1-4.4.1: USB disconnect, address 6
Jul 15 22:14:37 linux-2z24 kernel:  2910.976192] tg3 0000:85:00.0: eth0: Link is down
Jul 15 22:14:38 linux-2z24 kernel:  2911.772958] Monitor-Mwait will be used to enter C-2 state
Jul 15 22:14:38 linux-2z24 kernel:  2911.772985] Monitor-Mwait will be used to enter C-3 state
Jul 15 22:14:42 linux-2z24 avahi-daemon[2630]: Withdrawing address record for on eth0.
Jul 15 22:14:42 linux-2z24 avahi-daemon[2630]: Leaving mDNS multicast group on interface eth0.IPv4 with address
Jul 15 22:14:42 linux-2z24 avahi-daemon[2630]: Interface eth0.IPv4 no longer relevant for mDNS.

is what happens when laptop physically disconnects from docking station.

i think i’ll do some more checking though; not sure what happens with i add/remove USB devices from the docking station ports, or if the EXACT same thing happens all the time (usb ports disconnect in a different order?). the messages file seems to be the only one with docking station activity…

It is a bit OOT, but I think you lost the way here. When something is a shell script, one calls this “shell script” or better “bash/sh/ksh/zsh/csh script”. In Linux bash is most often used as shell, but sh (the POSIX shell) is also available, like the others mentioned above.

I do not think there is any sign of BASH “aging”. In any case when you think you have a shell script (got/downloaded somewhere) and want to know which shell it is written for, you look at the first line of the file. It should contain the shebang (Shebang (Unix) - Wikipedia, the free encyclopedia) and for bash it is


And when you have written it yourself, you will have put the correct shebang in it if you know any basics about shell script writing.

thanks for clarifying for me hcvv. I’m still very new to linux; learning plenty and no doubt got plenty of wires crossed along the way :slight_smile:

You are welcome.
As an afterthought, it may be that you called them .sh files because somebody gave them file names ending in those three characters. I found that also in another thread. When this is the case, be aware of the fact that giving them any name is OK, thus also when the name ends in .sh. But it may onlu serve in reminding people that there is a shell script of some sort inside because they have bad memories. The system does not care at all. An illustration:

henk@boven:~>  l script.jpeg
-rwxr--r-- 1 henk wij 41 jul 16 11:36 script.jpeg*
henk@boven:~> cat script.jpeg
echo "I am a JPEG (or not?)"
henk@boven:~> ./script.jpeg
I am a JPEG (or not?)

It is only some dumb applications that jump to the wrong conclusion. Like Dolphin, it says the above* script.jpeg *is a JPEG-image rotfl!