I want to make a some kind of alert to let me know when the charger has disconnected (the cable doesn't fit into the socket well).
I have this to detect the status of the charger:
cat /sys/class/power_supply/ADP1/online
it returns 1 when charging and 0 when on battery.
and this to request a pop-up window:
zenity --info --text="Charger unplugged!"
I figured some kind of if statement would do the job, having to run it infinitely every second or so.
Then I remembered my days of Arduino where you could program an interrupt, that could trigger the script to run, rather than having to run it all the time.
Not sure what the best way to achieve this is. Does anybody know?
Many thanks.
You could create a service, or you can do it in a more simple and primitive way: create a script that will create a fork, redirect it's own stdout and stderr to /dev/null and execute an infinite loop that will be constantly checking your /sys/class/power_supply/ADP1/online file. When the value is 0 it will redirect the stdout and stderr to the original, in order to show the prompt. To make this an autonomous script, you would have to execute it with crontab #reboot.
I think that in the CLI it should work, but I don't know if it would work in a Graphical Desktop Interface
Related
I want a notification in desktop that a particular USB device is inserted.Hence the following is the udev rule.
KERNEL=="sd*",SUBSYSTEMS=="usb",ACTION=="add",RUN+="/home/username/Desktop/notify_script"
notify_script is as follows
#!/bin/sh
su username -c 'notify-send "USB Inserted"'
echo USB_inserted >> /home/username/Desktop/test_file
Problem :
The above script works perfectly if it is executed as root from command line but, notify-send in script is not working if executed from udev.
Question:
How to make notify-send work from udev? or
Is there any other way by which I can achieve notification ?
Is it possible to invoke any GUI from udev?
Thank you.
The main problem is, that the udev-rule will not run in any xorg-related environment per default, thus not knowing which DISPLAY to use. Therefore it will always fail, if You want to echo something into a terminal like a gnome-terminal for example. The script, which shall be executed on the udev-rule-match, must prior to any ui-related execution first export the DISPLAY.
This is done via
export DISPLAY=:0
I assume, that this also will be the problem, and notify-send will just run against the wall.
I am actually also playing with udev-rules, and I managed it to work, though i am acting as root, similar to my answer and this one found already here :
https://unix.stackexchange.com/questions/80882/udev-running-a-shellscript-that-accesses-an-x-display
And also here
Scripts launched from udev do not have DISPLAY access anymore?
You might want also to check zenity. Very helpful for small notifications
Trying to make a small script and cron job it in order to automate a task. Said script runs another script which has already been created, grabs the output, emails to specified recipients, and cleans up the output. I've got it almost down however am running into one major issue. The script that mine is running has a menu on the outset. That is to say, running the script by itself manually, i would have to select option 1 in order to get the output i want (the only other option, 2, is quit.)
How can I automatically enter (or simulate entering) the value 1 into the other script, so it does not hang when in a cron job waiting for user input?
Is there a sane way to do this?
Thanks in Advance.
You could try something as simple as using yes | command if answering yes is all that is needed. Otherwise you probably want to use expect to drive the imaginary keyboard for you.
http://expect.sourceforge.net/
Using autoexpect to record your session is a convenient way to come up with rough draft expect scripts as well.
EDIT, the question might have not been totally clear, short version:
How to popup a dialog asking for user input if the script is running in the background and not in an active console?
/EDIT
When I run a bash script from udev or cron, it usually runs quietly somewhere in the background. Example could be plugging in an external harddrive runs rsync for data backup. So not every time I plug in the harddrive do I want to launch this action.
What is the most minimal way to fire up some user input dialog and ask yes or no? I could write some interface with PyQt but I want as little dependencies as possible, ideally cross window manager and maybe even without window manager.
Thanks!
EDIT 2: The lightweight (and hence as ugly as expected) version is xmessage, this would probably be the answer to the question, unless you have a better one:
xmessage "Do you want to run the backup script?" -buttons yes,no
http://linux.byexamples.com/archives/87/using-gui-dialog-box/
EDIT: So there's KDialog for kde, is there something really lightweight for X?
http://www.linux-magazine.com/Issues/2009/99/Zenity-and-KDialog
kdialog --title "Do you want to run the backup script?"
--yesno "Do you want to run the backup script?"
I'm currently leaning towards zenity, only trouble is it pulls in a whole array of gtk dependencies on kde, but is cross platform and works on windows. In essence, this is exaclty what I was looking for:
if zenity --question --text="Please press a button."; then
zenity --info --text="You pressed Yes\!"
else
zenity --error --text="You pressed No\!"
fi
But was hoping it would be a lot lighter on the resources / dependencies. Any alternative suggestions?
A simple approach would be for the automated script to simply email you, or perhaps alert with wall with instructions (containing the location of the real script).
Another approach would be for the automated script to touch a file in /var/lib and proceed if the file is still present after 5 minutes. This gives the user the option to stop the process (by removing the file), but maintains some automation.
This is not something you should have cron or udev handling in the first place. Write a userland daemon that listens for the appropriate D-Bus messages and performs the appropriate actions.
This should be post in linux or superuser or serverfault.
But, the number one google search on linux read user input links back here to StackOverflow:
https://www.google.com/search?q=linux+read+user+input&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb
so I guess it's not too off base.
Again, the third or so google result for linux invoke command usb device plugin links to ServerFault:
https://serverfault.com/questions/399698/execute-a-command-when-a-device-is-connected-via-usb
I'll leave combining those two as an exercise.
I am using Putty to connect to a remote server. What I want to know is if there is any way to write my commands and allow them to keep running after I close the session with Putty. The reason for this is that I do not want to keep the computer ON all the time. Is there any way to do this?.
Update with the solution
For my question as it is presented the best solution is use one of the commands provided such as nohup, because you do not have to install any additional software. But if you are in the same problem use screen, install it and use it. It is amazing.
I have selected the answer of Norman Ramsey as favourite because propose several solutions using commands and screen. But please check the other answers specially the one of PEZ, then you get an insight of what screen is able todo.
screen! It's the best thing since sliced bread. (Yeah, I know others have already suggested it, but it's so good the whole world should join in and suggest it too.)
screen is like, like, ummmm ... like using VNC or the like to connect to a GUI destop, but for command shell windows. You can have several shell "windows" open at once in the same screen session. You can do stuff like:
Start a screens session using "screen -dR" (get used to using -dR)
run some commands in one window
press CTRL-A,C to create a new window open a file there in vim
press CTRL-A,0 to go back to the first window and issue some command on the file you just edited
CTRL-A, 1 to go back to your vim session
CTRL-A, C for yet another window and maybe do "sudo - su" (because you just happen to need a full root shell)
CTRL-A, 0 and start a background process
CTRL-A, C to create yet a new window, "tail -f" the log for that background process
CTRL-A, d to disconnect your screen then CTRL-D to disconnect from the server
Go on vacation for three weeks
Log on to the server again and issue "screen -dR" to connect to your existing screen session
check the log in the the fourth window with CTRL-A, 3 (it's like you've been there watching it all the time)
CTRL-A, 1 to pick up that vim session again
I guess you're starting to get the picture now? =)
It's like magic. I've been using screen for longer than I can remember and I'm still totally amazed with how bloody great it is.
EDIT: Just want to mention there's now also tmux. Very much like screen, but has some unique features, splitting the windows being the most prominent one.
nohup, disown, and screen are all good but screen is the best because unlike the other two, screen allows you to disconnect from the remote server, keep everything running, and then reconnect later to see what is happening. With nohup and disown you can't resume interacting.
Try using GNU Screen. It allows you to have several shells open at once. And you can disconnect from those running shells (i.e. close session with Putty) and they will keep doing their thing.
What you are looking for is nohup.
See the wiki link for how to use it.
screen is the best.
Try:
screen -dmS "MyTail" tail -f /var/log/syslog
This start command in background.
Use screen -r to list, and or screen -r Mytail to enter session.
If more users need access same session, use: screen -rx MyTail, and both or more users share the session.
If you can't use screen (because, for instance, your SSH session is being programmatically driven), you can also use daemonize to run the program as a daemon.
One way that works well for me is at.
at works like cron, but for a one-time job. I used it today to download a large file without having to keep my session alive.
for example:
$ at 23:55
at> wget http://file.to.download.com/bigfile.iso
at> ^D
You pass at a time (in the future) and it gives you a prompt. You enter the commands you want to run at that time and hit ctrl+d. You can exit out of your session and it will run the commands at the specified time.
Wikipedia has more info on at.
./command & disown
ssh localhost && ./command && exit
I have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.