jobs started inside a loop have the full loop text as their command line

[adavies42]

$ seq 2|while read x; do sleep $x& done
$ jobs
[3] +  Running                 seq 2|while read x; do sleep $x& done
[2] -  Running                 seq 2|while read x; do sleep $x& done
$ 
[3] +  Done                    seq 2|while read x; do sleep $x& done
[2] -  Done                    seq 2|while read x; do sleep $x& done
$ 

wouldn't something like

$ seq 2|while read x; do sleep $x& done
$ jobs
[3] +  Running                 sleep 2
[2] -  Running                 sleep 1
$ 
[3] +  Done                    sleep 2
[2] -  Done                    sleep 1
$ 

be more useful?

[McDutchie]

I agree. This is because ksh takes the job command from the history file, and it simply takes the entire command line; it's not a bug so much as a design flaw. You also get nonsensical output if you invoke two background jobs on the same command line:

$ sleep 10 & sleep 10 &
[1] 31064
[2] 31065
$ jobs
[2] +  Running                 sleep 10 & sleep 10 &
[1] -  Running                 sleep 10 & sleep 10 &

I intend to fix this for the future 93u+m/1.1 release at some point by regenerating the job's shell code from the binary command tree instead. For the 1.0 series, we're just going to have to live with it I'm afraid.

[ormaaj]

I like that you can do this to access every previous pipeline. I don't think that's possible anywhere else. (using jobs -p to find every background pid up to when you forked.)