at command

[Leslie Chaim]

Sorry I hit the enter key too soon:)

Well, I was able to 'solve' my problem but I still have some questions I would like to clear.

First let me outline what the script does:
It starts on machine A collects some data
then 'remsh' to machine B and collects some more data then it 'remsh' to machine C
followed by some other chores on machine A.

When I run the job without the 'at' command it runs fine. However if I start it with the at command it does not work if I start it as follows:

at now < driver.sh

The above fails after completing on machine B the job just stops. However if I start the job as follows:

at now
driver.sh
Ctrl D

This works fine. A small wrapper does the job as well.

Why does the 'driver.sh' stop after completing it's work on Machine B when using input redirection to the 'at' command.

I checked the spooler by doing at -d jobid, and after removing all of the environment stuff , a ?diff? to the original is successful.

Just looking for an explanation!

Thanks,

Leslie

[John Bolene]

Things that work for us are:
cat script|at now
at now -f script

In the case of
at now< script
It would appear that the pipe gets broken.

[Pedro Sousa]

Leslie, normally you need to specify the file with '-f' flag. If you specify '<' maybe it doesn't read it's contents.
When I run something with the at, I do it as follows: at -f -t

[Leslie Chaim]

I guess the -f option may be more elegent, nevertheless, reading from stdin should be no problem.

if 'cat job | at now' works why sould it differ from 'at now < job'? Also, what do yo0u mean by a broken pipe?

[John Bolene]

Since you submit the job to be partially run on another machine, the at command may not have read all the file to be submitted.

When it comes time to read more, the job has already been sent to the other machine with remsh.

[Pedro Sousa]

Sorry. You're completely right. it works fine for me...
so, it's very strange. Maybe it has to do with the shell? Just a thought

[James R. Ferguson]

Leslie:

I think the "anomoies" have to do with when stdin is closed and with . From the man pages for 'remsh':

/begin_quote/

By default, remsh reads its standard input and sends it to the remote command because remsh has no way to determine whether the remote
command requires input. The -n option redirects standard input to remsh from /dev/null. This is useful when running a shell script containing a remsh command, since otherwise remsh may use input not intended for it. The -n option is also useful when running remsh in the background from a job control shell, /usr/bin/csh or /usr/bin/ksh. Otherwise, remsh stops and waits for input from the terminal keyboard for the remote command. /usr/bin/sh automatically redirects its input from /dev/null when jobs are run in the background.

/end_quote/

...and from 'man at':

/begin_quote/

You can enter commands into a job...From the keyboard on separate lines immediately after the at or batch command line, followed by the currently defined eof (end-of-file) character to end the input.

/end_quote/

Does this help?

...JRF...

[Vincenzo Restuccia]

echo "sh $HOME/jobs/weekly-run" | at 1900 thursday next week

[Ravi_8]

at now < script
'at' command taking i/p from script.
"at now script" should work

[Wieslaw Krajewski]

Hi,

This is pretty interesting problem.
I've made some experiments, that I'd like to summarize:

0. First of all to adopt some assumptions.
In the file driver.sh there are a few remsh commands, as for example:

remsh hostA cmd ...
remsh hostB cmd ...
remsh hostC cmd ...

1. James seems to be very close to the right explanation.
Being executed the first command wait for sth from STDIN.

2. If we try to run directly (without file driver.sh)

at now
remsh hostA cmd ...
remsh hostB cmd ...
remsh hostC cmd ..
^d

we observe the same behaviour as when running
at now < driver.sh

only first command is executed. I assumed that this is related to executing these commands in background.

3. So I prepared a script with these commands in it, and when this script is run in the foreground everything is OK, whereas running this script in background (script.sh &)
it resulted as in running via at command. Only first command was executed. Furthermore I noticed running jobs commans, the result was as below.

[1] + Stopped (SIGTTIN)

man 5 signal

SIGTTIN means Background process attempting read.

4. At the next step I added to my script

trap '' 27

as the first line. Then this script when run in background was running correctly, i.e. all remsh commands have been executed.

Unfortunately adding trap command as the first command in the at command does not help.
So this can be further investigated.

Hope this help a little in explanation.

Rgds.