On Fri 16 Feb 2018 at 07:28:45 (-0800), pe...@easthope.ca wrote: > * From: David Wright deb...@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.