On Fri 16 Feb 2018 at 07:28:45 (-0800), peter@easthope.ca wrote:
> * From: David Wright €deblis@lionunicorn.co.uk€
> * Date: Thu, 15 Feb 2018 15:18:45 -0600
> > Write …bashrc ; wake ; sleep 5'
> > and give yourself 5 seconds to read what it says in the xterm.
>
> Interactively.
> peter@hertz:~$ declare -f wake
> wake ()
> {
> input="";
> until [[ $input != "" ]]; do
> echo Beginning loop.;
> /usr/bin/play /usr/share/sounds/ekiga/ring.wav;
> read -n 1 -t 4 input;
> done
> }
>
> Therefore my .bashrc creates wake.
>
> Nevertheless,
> peter@hertz:~$ xterm -display :0 -e bash -c '. ~/.bashrc; declare -f wake; sleep 5'
> shows a black xterm, which, after 5 s, closes. Appears that this
> declaration fails.
This is odd. The attached shows what happens here. I should explain
that my .bashrc is noisy when interactive, as you can see in the outer
window. I changed wake to inform as I have that self-defined function
available, and I gave myself 15 seconds for taking the screenshot.
(BTW I would normally use type, it's shorter.)
> That has become a secondary problem. My current priority is to find
> why at fails to open the xterm at the specified future time. None of
> the at documents I've found mention error reporting. Can a failure of
> at be investigated without changing and recompiling the source?
I can't help you there as I've never used "at" in anger. My strategy
for a decade or more has been to use cron. Every minute cron runs a
python program which:
Looks for directory entries of the form 2000-02-29-12-34-foo[-*]
(where the year, month, day, hour and minute all match the current
time) in the {crondir} directory and, if found, executes {bindir}/foo from
the home directory thus:
. $HOME/{init} ; $HOME/{bindir}/foo -c $HOME/{crondir}/entry
The entry can be a file, link, or any other kind of directory entry.
Environment variables needed can be set in {init}.
Any backup entries *~ are ignored.
Foo gets handed its commandline (to find out what symlink it was called
by) and extracts the [-*] information above to get its arguments, from
which it knows things like what channel the radio is tuned to (for
setting input gain), and how many minutes to record from it.
So it's a little similar to what I think you're doing, but more flexible.
In terms of simplicity, it has nothing to do with X etc and doesn't
use stdin/out. Instead, recording is controlled by its touching a file
at startup called "2000-02-29-12-34-stoprecording" which is processed
in exactly the same way. This allows recordings to be curtailed or
extended by renaming the file without having to communicate with the
recording program itself (normally running headless): it runs until
stoprecording pops up and kills it.
It's all integrated into my arrangements for recording vinyl/cassettes
to file, and making recordings of arbitrary length on the spur of the
moment. I have a showtimes program that checks all the files to make
sure there are no time overlaps, and estimates diskspace requirements.
Cheers,
David.
Attachment:
nested.png
Description: PNG image
