In your comment you clarify:
I'm actually looking for a single step option to ps or pgrep (or similar) which only outputs "active" processes...
I'm afraid you're out of luck with current ps/pgrep implementations.
Post filtering like this relies on a full understanding of the intial output, which I don't have...
But you can get that understanding and, better yet, control that output as desired. Try something like this:
function pgrep_live {
pids=$(pgrep "$1");
[ "$pids" ] || return;
ps -o s= -o pid= $pids | sed -n 's/^[^ZT][[:space:]]\+//p';
}
That will return the pids for any pgrep'd processes matching your input string, which processes are "available for normal use," that is, neither dead+unreaped (Z) nor stopped (T).
To background itself, that application forks a child process and exits the parent. The shell knows of the parent process as that's the one it has forked itself before executing the command itself, but it has no visibility on the children or grand-children that that process may have spawned.
A simpler example of such a backgrounding command would be:
$ sh -c 'ps -j; sleep 10 &'
PID PGID SID TTY TIME CMD
6562 6562 14469 pts/13 00:00:00 sh
6563 6562 14469 pts/13 00:00:00 ps
14469 14469 14469 pts/13 00:00:00 zsh
My zsh knows about that sh process and its process group.
However, all it sees is that 6562 process exiting. It has no way to know that 6562 process has spawned a 6563 one.
$ ps -j
PID PGID SID TTY TIME CMD
6564 6562 14469 pts/13 00:00:00 sleep
6565 6565 14469 pts/13 00:00:00 ps
14469 14469 14469 pts/13 00:00:00 zsh
However, you can see the process running sleep is also in that 6562 process group (though, there's nothing stopping commands start new process groups, or even sessions (as daemons typically do)).
Those process groups are only created when the shell is interactive though.
Another thing you could do is:
cmd | cat &
wait
If the processes that cmd spawns don't close their stdout, then cat won't die until they have all died.
Best Answer
There is nothing wrong with your terminal or your shell. By default,
psshows processes with the same effective user identifier as the user running it, and associated with the same terminal. This typically results in only two processes showing up: the current shell, andpsitself. If there are any background processes associated with the current terminal, they will show up too; you can see this by runningTo see all processes, run
There are a number of other process selection flags, see
man pson your system for details.When you run
script, it allocates a new terminal and starts a new shell; sopsinsidescriptis running on a different terminal (even though it’s in the same terminal window on your system, or on the same virtual console). That’s why you don’t seescript. You can see this happen by runningttybefore and after runningscript: you’ll see it output two different values.