The [2]+ Stopped occurs as a side effect of issuing ls - no kb interrupts sent.
No! the first ls has completed, thus the job has finished, thus it has stopped.
It hadn't completed, I was just pointing out that (completed|finished)!=stopped.
I never disputed that it was stopping as opposed to completing, I was merely mentioning explaining how the shell printed it's stopped response, and that you could run it _not_ in the background to possibly find out the reason why it was stopping.. does it only happen when run in the background?
No, this is an issue which only affects background ssh processes. If I run the same app locally, or in the foreground, no problem. Thing is I often want to log into a machine, open a few X apps in the background and check things out, close them down and log out.
I just noticed tho that this effects another machine here running redhat & a different version of ssh so maybe this is a 'feature'.
The -f switch redirects stdin from /dev/null, which is fine for the boxes here which don't need a password but less good for remote ones where I don't control the login method.
I've not long had bandwidth here to make it worth running X apps remotely so this has only just become an issue so I guess I'll go check in the ssh archives see if it's been a problem for anyone else.
Cheers
Bryn
-- [EMAIL PROTECTED] mailing list
