Also occurs on SLES 10.1 with procps-3.2.6-18.7. Yeah, I'd go ahead and report the bug (or obtain the source code and attempt to debug it if you are so inclined).
Incidentally, you may already be aware but as a workaround you can do this to ensure your script carries on its merry way without having to turn off set -e:
I thought that if you did not export an "environment variable" when you change its value, then the change is only local, that is, the change is only seen within the process that performed that change. Since I execute the top command inside the process that set CPULOOP=1, I would have thought that top would see this new value.
Is this not the way that unix shells typically work? If not, then my experience with normal languages' scoping rules has led me astray.
Note that even if I do
export CPULOOP=1
top -b -n 1 -U $USER
I still get an error exit code, so I will still file a bug report.
top is not a command built-in to the shell. The shell must fork() a copy of itself and then that copy must exec() the top command. During the exec, the code for top, in effect, overlays the code for the shell. But a very few things are saved and environment variables are one. Regular variables are not saved.
Meanwhile the parent shell is waiting for its child process to finish. It continues to know that CPULOOP is 1. When you put an & on the end on the line, the parent shell does not wait.. it just keeps going.