MAL wrote:
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/null
A 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!
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?
MAL
-- [EMAIL PROTECTED] mailing list
