using `jobs` in a script

roeesar · 08-30-2010, 03:41 AM

Hey all,

Can someone tell me why when I use "jobs -l >> tmp" in a script
file it does nothing, and when typing it at the prompt it creates
the tmp file I expect it to...?

thx,
Roee

repo · 08-30-2010, 03:50 AM

Welcome to LQ
Try to give the whole path to tmp

Kind regards

gnashley · 08-30-2010, 10:04 AM

job control does not work in scripts -AFAIK. ditto for aliases.

makyo · 08-30-2010, 10:01 PM

Hi.

The command jobs works when job control is inactive as well as active. You can turn on job control in bash with set:

Code:

#!/usr/bin/env bash

# @(#) s1	Demonstrate job control in bash, non-interactive.

# Utility functions: print-as-echo, print-line-with-visual-space.
pe() { for i;do printf "%s" "$i";done; printf "\n"; }
pl() { pe;pe "-----" ;pe "$*"; }
version version =o bash jobs

pl " Test if script is interactive:"
if echo "$-" | grep -q -e "i"
then
  pe " Script is interactive :$-:"
else
  pe " Script is *not* interactive :$-:"
fi

pl " Background, jobs, fg, monitor mode off:"
rm -f t1
set -o | grep monitor
sleep 9 &
jobs > t1
fg %1
ls -lgG t1
cat t1
wait

pl " Background, jobs, fg, monitor mode on:"
rm -f t1
set -m
set -o | grep monitor
sleep 10 &
jobs > t1
fg %1
ls -lgG t1
cat t1

exit 0

producing:

Code:

% ./s1
version (local) 1.42
OS, ker|rel, machine: Linux, 2.6.26-2-amd64, x86_64
Distribution        : Debian GNU/Linux 5.0 
GNU bash 3.2.39
jobs - is a shell builtin [bash]

-----
 Test if script is interactive:
 Script is *not* interactive :hB:

-----
 Background, jobs, fg, monitor mode off:
monitor        	off
./s1: line 23: fg: no job control
-rw-r--r-- 1 40 Aug 30 21:57 t1
[1]+  Running                 sleep 9 &

-----
 Background, jobs, fg, monitor mode on:
monitor        	on
sleep 10
-rw-r--r-- 1 41 Aug 30 21:57 t1
[1]+  Running                 sleep 10 &

See man bash for details.

Best wishes ... cheers, makyo

gnashley · 08-31-2010, 02:27 AM

Hey that's very nice and I'm glad to be corrected there. There was a discussion here some time ago about how one might do job control within a script and nobody came up with a solution. Your code looks like it is.
But, what is this?:

Code:

version version =o bash jobs

roeesar · 08-31-2010, 03:47 AM

Quote:

Originally Posted by makyo

Hi.

The command jobs works when job control is inactive as well as active. You can turn on job control in bash with set:
[CODE]#!/usr/bin/env bash

[...]

Best wishes ... cheers, makyo

OK, tried it. Works just as u printed it here. The thing is that I have emacs running in the background and it does not include it in the jobs list. For some reason when I type `jobs -l` at the prompt it lists emacs as well but the script ignores it. Any ideas?

thanks a lot,
Roee

makyo · 08-31-2010, 04:26 AM

Hi.

Quote:

Originally Posted by gnashley

... what is this?:

Code:

version version =o bash jobs

It's a non-standard utility we use here that helps to standardize and report versions of commands. Later in the output, it reports on itself that it is "(local)".

In more detailed scripts, that line is usually written as:

Code:

version >/dev/null 2>&1 && version ...

so that the script can be run as copied even if version is not available. In this case, that part of the script did not as important as the comparison of how the system behaved when monitor was in different states ... cheers, makyo

druuna · 08-31-2010, 04:48 AM

@makyo: I have to admit that I like this utility, but it has one big disadvantage when used here at LQ: it is non-standard and most of the people here (especially those that are new) will not know how to deal with this (errors due to non-existing tools, a lot of code even though the important part is small etc).

Wouldn't it be a better idea to remove the extra code and just post the relevant part(s)?

I've decided to put this down because I've seen you reply like this more then once. And although the solution(s) given were good, it got lost in all the non-standard lines (and OP's openly admitted not understanding your code).

Just my 2c.

makyo · 08-31-2010, 05:23 AM

Hi.

Quote:

Originally Posted by roeesar

OK, tried it. Works just as u printed it here. The thing is that I have emacs running in the background and it does not include it in the jobs list. For some reason when I type `jobs -l` at the prompt it lists emacs as well but the script ignores it. Any ideas?

thanks a lot,
Roee

The idea of a job is related to, but different from a process. A job is the knowledge of a child process that a specific instance of a shell has. I think that the behavior you are seeing is because the job table is not inherited from the parent. A process is more general and the group of processes that are part of the current terminal session is accessible with command ps:

Code:

       By default, ps selects all processes with the same effective user ID
       (euid=EUID) as the current user and associated with the same terminal
       as the invoker. 

-- excerpt from man ps

Here's an illustration. I will start emacs and a sleep in the background, then run a script that is similar to the one I posted above. The jobs command produces no output, but the ps command does:

Code:

#!/usr/bin/env bash

# @(#) s2	Demonstrate job control in bash, non-interactive.

# Utility functions: print-as-echo, print-line-with-visual-space.
pe() { for i;do printf "%s" "$i";done; printf "\n"; }
pl() { pe;pe "-----" ;pe "$*"; }

# Report versions being used.
pe
version >/dev/null 2>&1 && version version =o bash jobs emacs

pl " Test if script is interactive:"
if echo "$-" | grep -q -e "i"
then
  pe " Script is interactive :$-:"
else
  pe " Script is *not* interactive :$-:"
fi

pl " Background, jobs, ps, monitor mode on:"
rm -f t1 t2
set -m
set -o | grep monitor
# emacs &
jobs > t1
jobs -l >> t1
ps > t2
ls -lgG t1
cat t1
pe
ls -lgG t2
cat t2

exit 0

then the session produces:

Code:

% emacs &
[1] 544
% sleep 10 &
[2] 546
% ./s2

version (local) 1.42
OS, ker|rel, machine: Linux, 2.6.26-2-amd64, x86_64
Distribution        : Debian GNU/Linux 5.0 
GNU bash 3.2.39
jobs - is a shell builtin [bash]
GNU Emacs 22.2.1

-----
 Test if script is interactive:
 Script is *not* interactive :hB:

-----
 Background, jobs, ps, monitor mode on:
monitor        	on
-rw-r--r-- 1 0 Aug 31 04:55 t1

-rw-r--r-- 1 173 Aug 31 04:55 t2
  PID TTY          TIME CMD
  544 pts/0    00:00:00 emacs
  546 pts/0    00:00:00 sleep
  547 pts/0    00:00:00 bash
  596 pts/0    00:00:00 ps

In the earlier post, the jobs commands produced a listing of the background jobs started in that instance of the shell.

The concept of processes is central to *nix, and is complex. If you need more, the man pages are a place to start, perhaps followed by starting a different thread on that topic.

Someone else might stop by with more pertinent information.

Best wishes ... cheers, makyo

makyo · 08-31-2010, 05:38 AM

Hi, druuna.

Quote:

Originally Posted by druuna

@makyo: I have to admit that I like this utility, but it has one big disadvantage when used here at LQ: it is non-standard and most of the people here (especially those that are new) will not know how to deal with this (errors due to non-existing tools, a lot of code even though the important part is small etc).

Wouldn't it be a better idea to remove the extra code and just post the relevant part(s)?

I've decided to put this down because I've seen you reply like this more then once. And although the solution(s) given were good, it got lost in all the non-standard lines (and OP's openly admitted not understanding your code).

Just my 2c.

Thanks for the feedback.

Yes, it can be off-putting to see a glob of code like that. I'll try to think of a way I can post results from a apparently-simple script, but also supply the versions, perhaps later.

The body of code in the OS and commands is so fluid and fast-moving that I think it can be important to eliminate version differences first. However, burying the solution (or surrounding it) by a lot of directly-unrelated code can be counter-productive.

I'll give this some thought and see if I can design something that produces results that are accessible to the user and is also easy for me incorporate important points -- that might mean a supplementary post for the versions if it seems critical to understanding the issue.

Thanks again ... cheers, makyo