Re: regulating the time a process can run with crontab?

["L. C. Robinson" <lcr@onewest.net>]

On Sun, 6 Jan 2002, James R. Van Zandt wrote:

> You will at least have to put your recording command in parentheses

The parentheses are not necessary, when only one pipeline is
involved.  You would only need this to enclose a set of command
lines.

> (so it runs as a subprocess) and follow it with an ampersand (so it

Yes, the ampersand was missing, and necessary, to backgound the
process; "$!" is only meaningful after that.

> runs in the background, and control returns to the parent process
> immediately).  So, I would write it this way:
> 
> #!/bin/sh
> (lynx --source `cat /tmp/streamurl` >path_to_file.mp3)&
> PROC=$!

The "at" command syntax requires the commands to be taken from a
file, or fed via the standard input, like my example with the
"here" document, or, to correct the line above: 

echo "kill $PROC" | at $END
 
> However, I have not tested this.  In particular, I'm not sure the at
> job will inherit the environment so that $end is defined.

Yes, it does inherit the environment (with a couple of minor
exceptions like TERM -- see the man page).  So the "`cat
/tmp/streamurl`" and temp file could be eliminated, and the URL
could simply be passed by an environmental variable (make sure
you export all the variables "at" will need, though, in the
starting script):

export STREAMURL

Can you really capture streaming audio with the -source option to
lynx?  I've never tried this, but it would really solve some
problems for me: what format would the result be in?  Would I
need to pipe it through sox?

See the script corrections below, too, for your original example.
 
> >From: Brent Harding <bharding@doorpi.net>
> >Date: Sat, 05 Jan 2002 21:55:28 -0600

> >Cool, that's what using at was for. I never knew how to get the process of
> >a script in to a variable with $!, better than using killall. Is there any
> >way, to for say,
> >Read a time as the prompt for some script which is in a variable, use it to
> >schedule up an at job for start and end this way?

> >For example:
#!/bin/sh
echo "Script to record broadcast or webcast material"

echo -e "Enter the time to start recording (default is now): \c"
read START
# Do not remove the next line -- not just a comment:
: set default start time, for testing -- ${START:=now}, if not set already.

echo -e "Enter the time to stop recording: (default is one hour): \c"
read END
# : set default stop time, for testing: ${END:=now+5minutes}if not set already
: set default stop time: ${END:=now+1hour}if not set already

echo -e "Enter the stream url to be recorded: \c"
read STREAMURL 
export STREAMURL END

read OUT_FILE\?"Enter the output filename with no suffix
 (suffix will be added -- default is captured_broadcast): "
: set default filename to ${OUT_FILE:=captured_broadcast} if not already set.

# old wrong: # at $START /usr/local/bin/record
at "$START" << End_of_here_document_marker
   # /usr/local/bin/record & # replaced:
   # Does the next line mean that the stream must be in mp3
   # format?  Will it work?
   lynx --source "$STREAMURL" > ${OUT_FILE}.mp3 &
   export PROC=$!
   # And we need another "at" command within the "at" command:
   at "$END" << End_Of_File_Mark
      # Prevent loss of recording with move command:
      kill $PROC && mv --backup --version-control=numbered \
         ${OUT_FILE}.mp3 ${OUT_FILE}.saved.mp3 
End_Of_File_Mark

   # exit "at" script at marker:
   # Marker string specified above for "here document" must start
   # at beginning of line (next line):
End_of_here_document_marker

exit

# Broken record script eliminated:
> >Then in /usr/local/bin/record
> >#!/bin/sh
> >lynx --source `cat /tmp/streamurl` >path_to_file.mp3
> >PROC=$!
> >at $end kill $PROC
> >One would probably use a date command to insure the file name won't
> >overwrite the last episode if it's not gone yet, and clean up the temp file
> >created. The only real problem with it is that if someone put in (halt) in
> >as a time, your system would go down if this is run by root. No error

Never run a script with external input as root!  Security hazard!
But "at" would not accept halt as a valid time: you would just
get an email from "at" telling you that you made a time format
error, and no recording would be made.  "at" scripts are run as
the user that invoked them, not root.  And halt wouldn't work
anyway, even if it was in the "here document", unless you ran it
as root, and used the root path.

LCR

The remaining lines are just quotation from the discussion thread:

> >checking at all in this, not sure if time is a possible test to make sure a
> >valid time of day is used.
> >At 04:55 PM 1/5/02 -0700, you wrote:
> >>And you might find that the "at" command is better choice
> >>for timing than "sleep" or cron.  For example:
> >>
> >>mpg123 lecture.mp3 &
> >>SOUNDPROC=$!
> >>
> >>at now+2hours << End_of_here_document
> >># Or: 
> >># at 9:30pm << End_of_here_document
> >>kill $SOUNDPROC
> >>End_of_here_document
> >>
> >>On Fri, 4 Jan 2002, James R. Van Zandt wrote:
> >>
> >>> One way to limit the duration of a command is to run it in a
> >>> subprocess (i.e. put the shell command in parentheses) and have the
> >>> parent kill it.  Here's an example:
> >>> 
> >>>   #!/bin/bash
> >>>   # try to send a string to the synthesizer via four different serial
> >>>   #ports
> >>>   for x in 0 1 2 3; do
> >>>       (DTK_PORT=/dev/ttyS$x
> >>>       echo "trying $DTK_PORT"
> >>>       stty sane 9600 raw -echo crtscts <$DTK_PORT &&\
> >>>       stty -echo                       <$DTK_PORT &&\
> >>>       stty ixon ixoff                  <$DTK_PORT &&\
> >>>       echo "this is /dev/t t y s $x" $'\r' >$DTK_PORT )&
> >>>   # if one of the above commands hangs, kill the process
> >>>       sleep 2; kill $! >/dev/null 2>&1
> >>>   done

-- 
L. C. Robinson
reply to no_spam+munged_lcr@onewest.net.invalid

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html