From: Eric <eric@cisu.net>
To: Carl <carl@anexia.co.uk>, Peter Howell <p.howell74@rcn.com>
Cc: linux-newbie@vger.kernel.org
Subject: Re: scripting the "rec" function for a fixed time.
Date: Wed, 26 Feb 2003 11:26:27 -0600 [thread overview]
Message-ID: <200302261126.27248.eric@cisu.net> (raw)
In-Reply-To: <5.1.1.6.0.20030226100528.01edc598@pop3.demon.co.uk>
On Wednesday 26 February 2003 04:19 am, Carl wrote:
> At 19:44 25/02/2003 -0500, Peter Howell wrote:
> >On Tue, 2003-02-25 at 01:14, pa3gcu wrote:
> >> > "rec" is not a stock linux command, and I cannot readily identify a
> >> > package that includes that application (just trying to match on "rec"
> >> > turns up several hundred hits in the Debian package database). So I'd
> >> > suggest you tell us a bit more about your setup, including enough
> >> > information that we can identify and take a look at the package that
> >> > includes this command.
> >>
> >> rec is an unix command altho' not well supported, slackware 8 has it
> >> included.
> >>
> >> rec --help shows a lot but thses are relavant to the question;
> >> -c, --channels=CHANNELS specifies the number of sound channels in
> >> FILE -d, --device=DEVICE use DEVICE for input/output
> >> -f, --format=FORMAT specifies bit format of sample
> >> FORMAT is either s, u, U, A, a, or g
> >> -r, --rate=RATE sample rate in hertz of FILE
> >> -s, --size=SIZE interpret size of sample
> >>
> >> I think this one could be an help -s xxxxxxxb
> >> SIZE is either b, w, l, f, d, or D
> >
> > Alas no :-(
> > size isn't the file size. It's really the width of each sample.
> > eg b for 8 bits, w for 16 bits....
> >
> >It appears that rec does not buffer the sound, but instead writes it
> >directly to the file.
> >It's inelegant, but I suppose I could kill the application after a
> >specified delay. There are two problems with implementing that for me.
> >Firstly, I don't think I could do that in perl, which I'm most familiar
> >with because there doesn't appear to be an easy way to spawn a process
> >and continue running the scipt. Secondly, I don't know how to run a
> >process and get it's process id, which I'd need to kill it.
> >
> > Ok, just did a little rtfm. I guess I could use ps and extract
> > the id. Now I guess I'd better learn some bash scripting
>
> There is a tcl based interpreter called expect which lets you spawn
> processes and gives you it's pid easily. If you have any programming or
> scripting experience then it will be easy.
>
> Or there is a program called timelimit which is part of the netpipes
> package that spawns a process and kills it if it doesn't return after a
> specified time.
>
> I don't know how accurate these are and i have no experience of timelimit.
I am not sure if I am correct, but its worth a try:
If you are interested in scripting it I once had to do something similiar in
BASH. By creating a function, it will execute the function commands in a
subshell while continuing with the current script. Try something like this
#!/bin/bash
function boot ()
{
*RecordProgram Command Here*&
}
boot #calls the funtion boot.
let PID = $! #returns PID of last executed background command.
wait 9000 #let it run for 9000 seconds
kill $PID
Something like that. this is opposed to the example below where the background
ampersand will hang the script. If $! doesnt return the correct pid then you
might be able to fake it using awk.grep and the ps command to isolate the pid
column.
#!/bin/bash
Recordprogram&
letPID = $!
wait 9000
kill $PID
I believe the function wont hang the script waiting for input like the above
example. Let me know if this sounds logical. I would appreciate input from
any real bash programmers to see if I am correct. As always, best of luck!
#------------------------
#Eric Bambach
#Eric@CISU.net
#------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
next prev parent reply other threads:[~2003-02-26 17:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-25 0:01 scripting the "rec" function for a fixed time Peter Howell
2003-02-25 2:55 ` Ray Olszewski
2003-02-25 6:14 ` pa3gcu
2003-02-26 0:44 ` Peter Howell
2003-02-26 6:01 ` pa3gcu
2003-02-26 8:08 ` Elias Athanasopoulos
2003-02-26 10:19 ` Carl
2003-02-26 17:26 ` Eric [this message]
2003-02-25 7:01 ` Elias Athanasopoulos
2003-03-08 0:22 ` whitnl73
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200302261126.27248.eric@cisu.net \
--to=eric@cisu.net \
--cc=carl@anexia.co.uk \
--cc=linux-newbie@vger.kernel.org \
--cc=p.howell74@rcn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox