[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Brent -

You will at least have to put your recording command in parentheses
(so it runs as a subprocess) and follow it with an ampersand (so it
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=$!
at $end kill $PROC

However, I have not tested this.  In particular, I'm not sure the at
job will inherit the environment so that $end is defined.

	   - Jim Van Zandt


>X-Sender: bharding mail doorpi net
>From: Brent Harding <bharding doorpi net>
>Content-Type: text/plain; charset="us-ascii"
>X-Loop: blinux-list redhat com
>Sender: blinux-list-admin redhat com
>X-BeenThere: blinux-list redhat com
>X-Mailman-Version: 2.0.1
>Precedence: bulk
>Reply-To: blinux-list redhat com
>List-Help: <mailto:blinux-list-request redhat com?subject=help>
>List-Post: <mailto:blinux-list redhat com>
>List-Subscribe: <https://listman.redhat.com/mailman/listinfo/blinux-list>,
>	<mailto:blinux-list-request redhat com?subject=subscribe>
>List-Id: Linux for blind general discussion <blinux-list.redhat.com>
>List-Unsubscribe: <https://listman.redhat.com/mailman/listinfo/blinux-list>,
>	<mailto:blinux-list-request redhat com?subject=unsubscribe>
>List-Archive: <https://listman.redhat.com/pipermail/blinux-list/>
>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 Enter the time to start recording
>read START
>echo Enter the time to stop recording
>read END
>echo enter the stream url to be recorded
>read URL
>echo $URL >/tmp/streamurl
>at $START /usr/local/bin/record
>
>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
>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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]