On Fri, Feb 16, 2018 at 07:28:45AM -0800, pe...@easthope.ca wrote:
> 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.
This only demonstrates that *something* defined your function. It
doesn't prove that it was ~/.bashrc. The obvious way to prove
whether it's ~/.bashrc doing it would be to read ~/.bashrc and see
what it says.
> 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.
Use "type wake" instead of "declare -f wake", so that you at least get
an *error* if it's not defined.
wooledg:~$ declare -f wake
wooledg:~$ type wake
bash: type: wake: not found
> 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?
An at - or batch - command invoked from a su(1) shell will retain the
current userid. The user will be mailed standard error and standard
output from his commands, if any. Mail will be sent using the command
/usr/sbin/sendmail. If at is executed from a su(1) shell, the owner of
the login shell will receive the mail.
This is rather poorly written, but if you ignore the leading and
trailing sentences about su, or if you simply *try* things and see
what happens, you should see that you will indeed be sent the stdout
and stderr from your at(1) jobs in email, just like with crontab jobs.
Testing now:
wooledg:~$ echo echo hello | at now + 1 minute
warning: commands will be executed using /bin/sh
job 2 at Fri Feb 16 11:19:00 2018
And yes, I got the expected email.
