First of all why don't you see output? As pointed out by Sergiy Kolodyazhnyy in the comments, scripts started by udev "don't inherit all the same environment variables, which means they have no way of knowing where and which GUI session you are running." In simpler terms, udev is ignorant when it comes to your desktop GUI.
I currently do something similar to what you've asked for USB devices that are plugged into my system. For an application I'm running, I need to know if the USB has a valid serial number. Anyway, here's how I made it happen.
- I start a helper script that creates a named pipe and watches that named pipe for "messages" traveling across it.
- I have udev configured to "send messages" (write lines) to my named pipe (in my case USB sn and partition info).
- My helper script sees each line of text come in and I use notify-send to dump the message on my screen in the form of a notification.
If you just want to see it in a terminal window, you could tell your helper script to simply echo text from the named pipe in the terminal window.
#This script should be called once without an argument to get it running in a "service" mode
#Successive calls to this script by UDEV sould pass a string as the first argument.
# These strings will then be displayed in the window running in service mode.
if [ "$1" == "" ]; then
[ ! -e "$pipe" ] && mkfifo "$pipe"
while true # this loop continuously reads new lines and echos them
# you won't reach this line unless you call this script with one argument
echo "$1" >> "$pipe"
Running this script:
- Save the above in a file
/tmp/sample_script.sh (will be deleted on reboot)
- Make the script executable
chmod +x /tmp/sample_script.sh
- Call the script to get it running in service mode (ie. without any arguments)
- From another terminal window/script/udev, run
/tmp/sample_script.sh "message to send" (notice we're passing the string argument, "message to send", here)
- Look back at the service window, and you'll see that the string, "message to send", has appeared in the window.
When running the script from udev, you won't be able to get the second instance to output anything on the screen directly without redirecting it through the named pipe because your udev script is called from an environment that is completely separate from the environment your GUI is running in. The named pipe created in the script and utilized in both environments acts like a bridge between the two, allowing you to pass information from the udev environment to the GUI environment you're looking at.