[SOLVED] next command starts before one finishes

/dev/dog · 08-01-2015, 04:14 PM

Hi! You guys are awesome!

Anyway, I am learning much just by fooling around with VMs.

I am confused about this output.

Code:

alpha@dogpack:~$ find / &> /dev/null & echo "---Current-Jobs---" ; jobs ; pgrep "find" | xargs kill && jobs
[1] 1992
---Current-Jobs---
[1]+   Running                     find / &> /dev/null &
[1]+   Running                     find / &> /dev/null &
alpha@dogpack:~$

For newbies noobier than I viewing this thread, I'll explain what this all means in the second reply to this thread.
My question is, am I correct in assuming that the last command

Code:

jobs

executed before the second-to-last command

Code:

pgrep "find" | xargs kill

finished?
If so, how can I make it so that the last 'jobs' happens only after the second-to-last command finishes?

Thank you all in advance

/dev/dog · 08-01-2015, 04:24 PM

For people who want to figure out what the above command means.

Code:

find / &> /dev/null & echo "---Current-Jobs---" ; jobs ; pgrep "find" | xargs kill && jobs

Code:

find /

looks at and prints every file and folder and files in subfolders that it encounters.

Code:

$>

all standard output and standard error are sent to the location after

Code:

/dev/null

a pseudo-location that destroys everything sent to it

Code:

sends the previous command to the background, allowing the terminal to continue accepting commands

Code:

echo "---Current-Jobs---"

prints "---Current-Jobs---" to the screen

Code:

denotes the end of one command and allows a new command to begin

Code:

jobs

lists all jobs and their statuses

Code:

pgrep "find"

gets the list of all processes, and filters for the term "find"

Code:

sends the standard output of the previous command to the standard input of the next

Code:

xargs

converts standard input into arguments/parameters

Code:

kill

terminates a process

Code:

pgrep "find" | xargs kill

pgrep "find" returns a process ID of the 'find' command I executed
then the pipe (|) sends that as standard input to xargs
xargs converts that standard input to 'kill's argument to kill

Code:

&&

runs the next command is the previous was successful

my confusion is that the last 'jobs' printed the last line of the output, which dictates that the find command is still running.
I thought that the previous command terminates that process.

rknichols · 08-01-2015, 08:39 PM

That last jobs command does run after the kill command completes. Your problem is that the kill command just sends a signal which is then queued for the target process. Nothing happens to that process until the next time it is scheduled, sees the signal, performs whatever cleanup actions are needed, and finally terminates. Even then, it remains as a zombie process until its parent reaps its status with a wait() call. You have no control over when your final jobs process gets scheduled in that sequence.

/dev/dog · 08-02-2015, 04:36 AM

Quote:

Originally Posted by rknichols

That last jobs command does run after the kill command completes. Your problem is that the kill command just sends a signal which is then queued for the target process. Nothing happens to that process until the next time it is scheduled, sees the signal, performs whatever cleanup actions are needed, and finally terminates. Even then, it remains as a zombie process until its parent reaps its status with a wait() call. You have no control over when your final jobs process gets scheduled in that sequence.

I see, well, that makes sense. Thank you very much.