Duncan, thank you for pointing out that&& is a conditional test. I
had understood&& simply as "wait until previous instruction completes
before proceeding", because that is the question I sought to answer
when I first came across it via google; hence my seemingly
contradictory logic. If pan fails I need to run dem (display error
messages), a function I've put in .bashrc. Its essential feature is
that it throws up an xterm and blinks an appropriate error message at
me whenever a script running in background fails for some reason.
But there does seem to be an anomaly here. Whatever follows the&&
can not take effect until pan exits. That it happens to be a test
that must always fail is irrelevant. That test cannot be tried until
the pan instruction has terminated. And that does _not_ happen. In
fact, after Ctrl-c-ing to terminate pan, when restarted (after reboot)
with just
pan&
it went right back to downloading those duplicates.
Apparently Task Manager is not removing completed items from the list
in command line mode, So when it reaches the end of the list it just
returns to the beginning of it again. The only way I was able to
completely shut it up was to select all the items in Task Manager and
delete them, when in gui mode.
As for pan.debug, when I could not find it in /home/g I ran
find /home -name pan.debug
which I believe searches every subdirectory under /home. It returned
nothing. Possibly I deleted it in some way.