regulating the time a process can run with crontab?

regulating the time a process can run with crontab?

[Brent Harding]

	Suppose I want to use the lynx --source option to record an mp3 stream
that will start at a certain time, and I want to stop it at a certain time.
I could start it with a cron entry, in a script, but how in such a script
would I cause lynx to terminate, assuming the mp3 stream never quits?
There's no way of telling lynx --source how much to get if this is in the
background.
Thanks.

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

[Mike Gorse]

kill `pidof lynx` aught to work.

--Michael Gorse / ICQ:22583968 / http://mgorse.home.dhs.org

On Thu, 27 Dec 2001, Brent Harding wrote:

> 	Suppose I want to use the lynx --source option to record an mp3 stream
> that will start at a certain time, and I want to stop it at a certain time.
> I could start it with a cron entry, in a script, but how in such a script
> would I cause lynx to terminate, assuming the mp3 stream never quits?
> There's no way of telling lynx --source how much to get if this is in the
> background.
> Thanks.
>
>
>
>
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/blinux-list
>

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

[Brent Harding]

Oh, so you'd just use sleep for the time in seconds, and use this command
after to make it end? I'm not real sure of good places to learn about shell
scripting and the like, as I've never done more than simple lists of
commands with it, conditionals get sort of tricky, for trying lfs, just
typed as the instructions said, and things worked to make it in to a
loopback file system.
At 09:15 AM 12/28/01 -0500, you wrote:
>kill `pidof lynx` aught to work.
>
>--Michael Gorse / ICQ:22583968 / http://mgorse.home.dhs.org
>
>On Thu, 27 Dec 2001, Brent Harding wrote:
>
>> 	Suppose I want to use the lynx --source option to record an mp3 stream
>> that will start at a certain time, and I want to stop it at a certain time.
>> I could start it with a cron entry, in a script, but how in such a script
>> would I cause lynx to terminate, assuming the mp3 stream never quits?
>> There's no way of telling lynx --source how much to get if this is in the
>> background.
>> Thanks.
>>
>>
>>
>>
>> _______________________________________________
>> Blinux-list mailing list
>> Blinux-list@redhat.com
>> https://listman.redhat.com/mailman/listinfo/blinux-list
>>
>
>
>
>_______________________________________________
>Blinux-list mailing list
>Blinux-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/blinux-list
>
>

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

[Dave Mielke]

It all depends on what you want your process to timeout for. If you want to
protect against a hung connection, then a much better method is to download
with wget rather than lynx. wget has just such a timeout option.

-- 
Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave@mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.

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

[Brent Harding]

Wow, will wget still work with these live streams that never end, or have
no definite size? In a background cron job, where will this status output
go, spam my email box? I don't think I need an email for every 50k, as this
process will run in the background. One problem I do have on dialup is that
the stream will stop, something would have to keep restarting it. Wouldn't
the until directive do it, or doesn't the until loop allow for the use of
time of day as a way to know when to stop restarting? One could use while
true or something and a second script to kill it off, but in practice,
infinite loops can go crazy and shouldn't be used.
At 11:27 AM 12/28/01 -0500, you wrote:
>It all depends on what you want your process to timeout for. If you want to
>protect against a hung connection, then a much better method is to download
>with wget rather than lynx. wget has just such a timeout option.
>
>-- 
>Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
>Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
>EMail: dave@mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
>
>
>
>_______________________________________________
>Blinux-list mailing list
>Blinux-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/blinux-list
>
>

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

[A. R. Vener]

You use a separate script which sends a kill signal to
lynx. This would call a script that either looks up the pid
of your lynx process or identifies it from your original script.

For example the first line in your script could be:
echo $$ > $HOME/.recordingpid


the second script would execute:

kill -9 `cat $HOME/.recordingpid`

Rudy

On Thu, Dec 27, 2001 at 10:59:16PM -0600, Brent Harding wrote:
> 	Suppose I want to use the lynx --source option to record an mp3 stream
> that will start at a certain time, and I want to stop it at a certain time.
> I could start it with a cron entry, in a script, but how in such a script
> would I cause lynx to terminate, assuming the mp3 stream never quits?
> There's no way of telling lynx --source how much to get if this is in the
> background.
> Thanks.
> 
> 
> 
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/blinux-list

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

[James R. Van Zandt]

Brent -

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

	              - Jim Van Zandt
  

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

[L. C. Robinson]

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

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

[Brent Harding]

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
>
>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
>
>
>
>_______________________________________________
>Blinux-list mailing list
>Blinux-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/blinux-list
>
>

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

[James R. Van Zandt]

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

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

[L. C. Robinson]

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

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

[Brent Harding]

Yes, mp3 shoutcast streams can be recorded this way. I've tested before.
Someone told me about using lynx --source for this one. If you want to play
it, pipe lynx's output in to mpg123. The output is mp3.
At 02:27 AM 1/8/02 -0700, you wrote:
>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
>
>
>
>_______________________________________________
>Blinux-list mailing list
>Blinux-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/blinux-list
>
>