You can now execute a command right after waking up from suspend as well as substitute the suspend command for something else. A word of notice though, the command you execute will be run with root privileges (there is no clean way to fix that), wants the absolute path (not "~/") and mind to put the command in quotes if you have more than one argument.
Example:
$./wakeup 48h -e "mpg123 -@ /home/user/stream/my\ radio.pls"
I will see if I can write a manpage for it some time.
]]>strptime(3) is pretty much an analog to sscanf(3) and is meant for parsing well-known structured data. You'd have to reverse engineer (so to speak) the user's intentions. At that point, you may as well just be parsing the string manually.
Yeah it is pretty rigid, but I'd much prefer to inflict that little pain onto the user instead of trying to parse a string manually that might, or might not be something that could resemble some time.
The way I thought of it was to allow something like "8:00" _maybe_ even something like "5:00AM" depending on locale but that's the most what would be planned for. If someone really wants to wake his box if it is a Friday in the timezone of China and if Saturn and Mars are aligned but only on a full moon he/she better grabs a calculator or uses your workaround.
leverage a tool that already does this parsing, and just have wakeup read an absolute time as seconds from epoch, e.g.
$ wakeup -a "$(date -d 'tomorrow 8:00' +%s)"
Adding this feature becomes trivial then.
It should be possible to do that inside the application with somewhat minimal hassle. strptime() looks like a good start, but stuff like "tomorrow" might be a bit over the top for it.
]]>ijanos wrote:Nicely done! Feature request: what about adding an option which accepts an exact time and calculates the time difference from now.
Something like ./wakeup -at 8:00 or with some intelligent syntax: ./wakeup -at tomorrow, 8:00
I could write a bash wrapper for this if I really want to, but it would be better suited inside the application.
I will try that next, however that kind of parsing isn't trivial. It might take a while before its working
leverage a tool that already does this parsing, and just have wakeup read an absolute time as seconds from epoch, e.g.
$ wakeup -a "$(date -d 'tomorrow 8:00' +%s)"
Adding this feature becomes trivial then.
]]>how can I connect this to mplayer and make it a *real* alarm clock? I wonder what waking up beethoven's 9th sounds like xD
I'm on it currently. It isn't as straightforward as it sounds since the process is already done and finished (hence not running anymore) once you set a time and well, a process that isn't running can't do anything. It should work with a signal event though.
]]>Nicely done! Feature request: what about adding an option which accepts an exact time and calculates the time difference from now.
Something like ./wakeup -at 8:00 or with some intelligent syntax: ./wakeup -at tomorrow, 8:00
I could write a bash wrapper for this if I really want to, but it would be better suited inside the application.
I will try that next, however that kind of parsing isn't trivial. It might take a while before its working
]]>how can I connect this to mplayer and make it a *real* alarm clock? I wonder what waking up beethoven's 9th sounds like xD
Easyly open a terminal and write this:
sleep 20 && mplayer /path/to/9th.mp3
then you have 20 seconds to put your computer to suspend. In suspend the mplayer's countdown will be freezed and it will be resumed when the computer wakes up.
]]>Something like ./wakeup -at 8:00 or with some intelligent syntax: ./wakeup -at tomorrow, 8:00
I could write a bash wrapper for this if I really want to, but it would be better suited inside the application.
]]>As for the tint, well... no idea about that. It sure hasn't anything to do with the program since all it does is setting a timer and execute 'pm-suspend' just like you would in a terminal. I'll see if upower can be used as an alternative.
And many thanks for the PKGBUILD!
The tint is actually something my laptop (x220) does by default, but
my last ThinkPad didn't have that nice LED, so I wasn't expecting it.
I hadn't realized it always did this because in the past I just closed
the lid to suspend, and never looked at the power button.
No problem.
]]>Do you mean that if you set it to suspend, you cannot unsuspend until
the time is up? Because with a laptop, that is set to resume from
suspend by opening the lid, this is not an issue, because I can resume
by just opening the lid. Or maybe you meant something else.
No it means that if you set the timer and don't suspend (it currently does that by itself but imagine a version that wouldn't automatically trigger suspending) and you suspend at some later timer it would wake up again. That is potentially troublesome which is why I choose to let it trigger suspending immediately.
So for example, you set a timer, do some stuff and forget about it. then you suspend sometime later and then the timer will trigger a wakeup. In case you are just making a romantic walk with your laptop in the bag that behaviour can be problematic. If you aren't suspended and the timer runs out nothing happens.
As for the tint, well... no idea about that. It sure hasn't anything to do with the program since all it does is setting a timer and execute 'pm-suspend' just like you would in a terminal. I'll see if upower can be used as an alternative.
And many thanks for the PKGBUILD!
]]>It works pretty good. However, a --help or -h parameter option would be nice. Also at the moment if you try to invoke an option like -h it goes into suspend, you should limit the characters you can use for the time to numbers followed by h/m/s.
You're right. I'll fix that soon. As mentioned the arg parsing isn't very robust at the moment. using h/m/s shouldn't be a problem since that differs from -h.
update: updated. There was a check for digits already in place btw. What was missing was that it interpreted the 'h' and no digits as 0 hours. That should be fixed now.
]]>