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