The 2>&1 construct (as HH states) directs standard error to wherever standard output is currently going. The '&' in '2>&1' certainly does not background the process. In order to do this, you'd need a whole separate '&' like this:
xxxxxxx >/dev/null 2>&1 &
But more to the point, I think HH's analysis of Paddy's problem is actually plain wrong. I would hazard a guess that the $USER variable being used contains a space, with the result that script is doing something like this:
vncserver :1 -name Paddy Tillman >/dev/null 2>&!
The effect of this (boring details aside) is that the invocation of vncserver fails, 'coz it thinks the name is 'Paddy', and then doesn't have any idea what the 'Tillman' is all about. It *appears* to be OK ('cos any useful output has been redirected to /dev/null) but in reality it really isn't.
The vncserver-created files that hold the PID of the (short-lived, now defunt) Xvnc process that vncserver thought it had started are still there, although the corresponding process is now gone - having printed an error message about the wierd Tillman parameter and then exited. This means that the vncserver -kill :1 (note the space after '-kill' and before ':1' - not printed in the mag) then gives an error message about the expected process not being present.
The failure of vncserver (actually of the Xvnc that it starts) due to the extra 'Tillman' parameter also explains why subsequent efforts to connect gives the 'Connection refused' message: there's nothing there to connect to any more!
Paddy if you read this, please can you try setting $USER to be spaceless (assuming my diagnosis is right), and try again? The fix (if you *must* keep the $USER with a space in it) is perhaps to enclose $USER in quotes in your script "$USER".
Or of course, I may just be completely and utterly wrong in my space-hypothesis! If so, I apologise; but if I'm right, do I get a lovely Neuros for being Star Quoting Geek?
James
