Unless you add the -n option to ssh, ssh will read from its standard input, which in the case of the while loop is the tempo.txt file.
Alternatively, you can use a different file descriptor to read the tempo.txt file:
#! /usr/bin/ksh -
while IFS='#' read <&3 -r r1 r2 rest; do
apx_server_disk_space.sh "$r2" "$r1"
done 3< tempo.txt
If those servers are GNU/Linux servers, your ssh script could be:
#! /bin/sh -
ssh -n "$1@$2" 'stat -fc "scale=2;100*(1-%a/%b)" .' | bc
Which would probably be more robust and future-proof.
This looks like a bug in several shells, it works as expected with ksh93 and zsh.
Background:
Most shells seem to run the while loop inside the main shell and
Bourne Shell suspends the whole shell if you type ^Z with a non-login shell
bash suspends only the sleep and then leaves the while loop in favor of printing a new shell prompt
dash makes this command unsuspendable
With ksh93, things work very different:
ksh93 does the same, while the command is started the first time, but as sleep is a buitin in ksh93, ksh93 has a handler that causes the while loop to fork off the main shell and then suspend at the time when you type ^Z.
If you in ksh93 later type fg, the forked off child that still runs the loop is continued.
You see the main difference when comparing the jobcontrol messages from bash and ksh93:
bash reports:
[1]+ Stopped sleep 1
but ksh93 reports:
^Z[1] + Stopped while true; do echo .; sleep 1; done
zsh behaves similar to ksh93
With both shells, you have a single process (the main shell) as long as you don't type ^Z, and two shell processes after you typed ^Z.
Best Answer
Single square brackets in the shell is a synonym for
test(either the separate command or the shell built-in), so[ 0 ]means the same thing astest 0.testis for doing comparisons and testing the attributes of files, as you can read about in its manpage. When it isn't given an expression that looks like a comparison, file test, or one of the other operations it can do, it will instead test if the argument is present and a non-empty string. Neither0or1are really appropriate inputs for test, and as non-empty strings test simply succeeds and your while loop loops forever.You may want to try instead
possibly replacing
falsewithtrue. Or maybe what you want is to use(( )):Which will behave like most languages, where 0 means failure/false and 1 means success/true.