I'm pretty unsophisticated in my scripting. I never followed a method
to learn, I just use google when I want to figure out how to use a
command or preform a certain function (and most of the results are from
here or the ABSG). Anyway, there are a lot of gaps in my knowledge.
So, I wanted to write a simple, multi-purpose alarm-clock. What
I've got is tiny, and it works. It reads the user-specified time and command, and
executes the command at the time then exits. Here it is:
#!/bin/bash
time="$1"
command="$2"
trig=0
while [ $trig = 0 ]; do
if [ "$(date +%R)" = $time ]; then
$command
trig=1
else
sleep 5
fi
done
exit
So I can give it a line like...
alarm 07:00 'mplayer annoying-sound.ogg'
... and it plays the annoying sound at 7:00.
Then I checked google to see how others had created alarms. They were
all rather involved, calling functions and using all sorts of commands I
didn't recognize, and all substantially longer.
Is there any reason my rather humble implementation is undesirable or
problematic?
For a simple alarm it's enough. What others probably have added is plausibility checks for the time, DoW-variant alarm times, checking if the command line is correct, ...
DoW == Day of Week. Meaning the possibility to set different alarm times based on the day (wouldn't want the alarm to ring on 06:00 on a Saturday since I just went to bed )
@Skrynesaver: at does basically the same. But I think for someone who's just learning the hang of scripting, this is a good starting project, as it can be extended over time.
Hmmm... this "at" looks a little complicated, but useful. I'll have to play with it a little.
On first glance, it looks like the syntax is better suited to scripts than terminal. Is that correct?
---------- Post updated at 02:32 PM ---------- Previous update was at 02:13 PM ----------
Ah. right. I was thinking about (among other things), calling it from another script with config files to organize calender events and things like that, and letting the parent script handle day of the week stuff.
I woudn't exactly say I'm 'just learning the hang of it.' I'm somewhere in the "upper-beginner/lower intermediate" level of bash (though bash is just a doorway to other things, I guess). I've written scores of them. My .xinitrc and .bashrc are from scratch. I've written some scripts that search web websites for correct files to download automatically, or create new directory strutures based on file types. I actually even wrote a system of 20 or so scripts to coordinated a bunch of UI elements to get a good system going on my netvertible with config files and everything. I can write scripts that do all kinds of cool things.
I'm just always insecure about whether I'm doing it the best possible way. For a while, I called all of my command substitutions with `substitution` syntax, and I would run into these weird problems with no apparent solution, and then I randomly stumbled across $(substitution) syntax and figured out how much better it is.
And I still need to learn sed. It looks so awesome for making config files, but I'm intimidated by the size of the man page.
I didn't target that comment specifically at you, but more as a general statement for any "newbies" reading this thread.
And IMO I wouldn't parse config files with sed unless forced, as I think it's too much of a hassle if you can just source the file & use the variables from there. It's useful if you want to do some pre-processing on it (eg. if you want to use some special variable substitution or similar), but that's about it in this case.
This is probably another thread, but what's the best way to do config
files. At the moment, I just use...
cat config_file|grep var_name|cut -d'=' -f2
... which is fine for what I've been doing, but I'm not sure what to
do when there are a variable number of entries and I want it go through
them like a list.
Course, the config file itself could be a script but I prefer to keep
the configs seperate from the functions. Not really sure how to do
this. It's a problem sometimes, though I can usually hack up some kind
of work-around for my ignorance.
If you plan to deploy that alarm into a mission critical process daylight saving time and in general adjustments to the system clock may be problematic for your script.
Why not directly use the date-$time check as the loop condition? This way, $trig is not needed. Also, it may be more useful to have this script return the exit status of $command.
For your consideration:
#!/bin/sh
time="$1"
command="$2"
while [ "$(date +%H:%M)" != "$time" ]; do
sleep 5
done
$command
Also, for portability, I made some minor modifications that may not be of any interest to you.
Since there's nothing bash-specific about this little script, I changed /bin/bash to /bin/sh. Should you ever need to run it on a system that does not have bash, it will still work.
A system without bash may have a date command that does not support the %R format. Since that's equivalent to the standard %H:%M, I used that instead.
That's excellent. I'm always happy to see better ways of doing it. I just somehow had it in my head that it would be an if condition before I started, so it never occured to me to put the condition in the loop itself.
)
