No! the first ls has completed, thus the job has finished, thus it has stopped. The shell waits for the next prompt before it alerts you of this fact.
No, 'fraid not. Compare:
[EMAIL PROTECTED] bryn $ ssh hex ls -lR > /dev/null 2>&1 &
[2] 1889
[EMAIL PROTECTED] bryn $ ls
FrozenPenguins.png foo.java share shot0003.jpg
Screenshot.png questframe shot0002.jpg [2]+ Stopped ssh hex ls -lR >/dev/null 2>&1
[EMAIL PROTECTED] bryn $
with:
[EMAIL PROTECTED] bryn $ ls / > /dev/null &
[3] 1048
[EMAIL PROTECTED] bryn $
[3] Done ls / >/dev/nullA stopped job is one who's execution is suspended by the shell. It would return 'Done' if the job had completed. The use of ls was merely an example to demonstrate; ls -lR takes quite a while on my home directory on hex!
The problem I was refering to was background ssh jobs spontaneously stopping just because I ran another command or hit enter.
This is simply because the background job has already finished.
Try running it _not_ in the background, and see how long it takes to complete.
[EMAIL PROTECTED] bryn $ fc 465 time ssh hex ls -lR > /dev/null 2>&1 & [3] 3439 [EMAIL PROTECTED] bryn $ real 0m3.342s user 0m0.290s sys 0m0.115s
Long enough to see the problem I'm referring to - maybe this example with gimp makes it clearer:
[EMAIL PROTECTED] bryn $ ssh hex gimp&
[3] 3443
(1) [EMAIL PROTECTED] bryn $
[3]+ Stopped ssh hex gimp
[EMAIL PROTECTED] bryn $ bg
[3]+ ssh hex gimp &
(2) [EMAIL PROTECTED] bryn $
[3]+ Stopped ssh hex gimp
[EMAIL PROTECTED] bryn $
All I did at (1) & (2) was hit enter. I'm using a normal UK keyboard & keymap so I don't think the KB is spitting out funny chars...
I can work around this locally by using the -f switch because I use public key logins, but this will break keyboard logins for remote sites.
Cheers
Bryn
-- [EMAIL PROTECTED] mailing list
