shell function in the background?

shell function in the background?

[Dave Yost]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]


Can a shell function tell if it’s part of a pipeline running in the background? 

I want to write a shell function that traps SIGCONT and does one thing or another thing depending on whether the function is CONTinuing in the background.

Can’t see how to do it.

Furthermore, it’s not clear to me why a backgrounded function thinks its pid is the pid of the shell that spawned it.

0 Wed 0:12:34 DaveBook yost /tmp
250 Z% function foo() {
print foo says pid is $$
sleep 2
}
0 Wed 0:12:56 DaveBook yost /tmp
251 Z% foo & ps xl -t ttys004 | sort -k 2
[1] 26183
foo says pid is 25935
  UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT   TT       TIME COMMAND
    0 25934   226   0 143  0  2503604   2316 -      Ss   s004    0:00.01 login -pf yost /bin/zsh
  502 25935 25934   0  31  0  2500064   2512 -      S    s004    0:00.14 -zsh
  502 26183 25935   0 163  5  2500064    588 -      SN   s004    0:00.00 -zsh
    0 26184 25935   0  45  0  2433268    644 -      R+   s004    0:00.00 ps xl -t ttys004
  502 26185 26183   0 1074014208  5  2432764    500 -      SN   s004    0:00.00 sleep 2
  502 26186 25935   0 1074104586  0  2432800    500 -      R+   s004    0:00.00 sort -k 2
0 Wed 0:13:00 DaveBook yost /tmp
252 Z% 
[1]  + 26183 done       foo
0 Wed 0:13:02 DaveBook yost /tmp
252 Z%  print pid is $$
pid is 25935
0 Wed 0:21:00 DaveBook yost /tmp
253 Z% 


I get the same thing even if I do this

function foo() {(
  print foo says pid is $$
  sleep 2
)}
foo &

or this

function foo() {
  (
    print foo says pid is $$
    sleep 2
  ) &
}
foo

Re: shell function in the background?

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

On Jun 25, 2014 9:34 AM, "Dave Yost" <Dave@yost.com> wrote:
>
>
> Can a shell function tell if it’s part of a pipeline running in the
background?

That's a tricky question because all parts of a pipeline run "in the
background" except for the last (first, in most shells other than zsh)
command.  So you're really asking whether the function can tell if some
other process downstream of it has been put in the background.  There's no
direct way to do that.

> I want to write a shell function that traps SIGCONT and does one thing or
another thing depending on whether the function is CONTinuing in the
background.

I'm not sure that would work for you anyway, because the timing of delivery
of the signal to your function and to other jobs in the pipeline is not
deterministic.  Also, because of vagaries of job control and memory
management, the shell trap handler for CONT might not be called immediately.

Is there some other condition related to being in the background that you
might test instead?  I.e. why does backgrounding require different behavior?

> Furthermore, it’s not clear to me why a backgrounded function thinks its
pid is the pid of the shell that spawned it.

That's the way the $$ variable is defined by the standard and is how all
Unix shells have always behaved.

If you "zmodload zsh/system" the parameter $pid becomes available and has
the value you want.

Re: shell function in the background?

[Philippe Troin]

On Wed, 2014-06-25 at 08:55 -0700, Bart Schaefer wrote:
> On Jun 25, 2014 9:34 AM, "Dave Yost" <Dave@yost.com> wrote:
> > Can a shell function tell if it’s part of a pipeline running in the
> background?
> 
> That's a tricky question because all parts of a pipeline run "in the
> background" except for the last (first, in most shells other than zsh)
> command.  

Sorry to be pedantic here, but technically, a process group (and not a
process) is put in the foreground or the background.  Similarly, the
terminal control keys (ctrl-C, ctrl-Z, ctrl-\) deliver signals to entire
process group.

> So you're really asking whether the function can tell if some
> other process downstream of it has been put in the background.  
> There's no direct way to do that.

There is.  It's a little tricky, because you cannot and must not spawn
any subprocesses to do the detection, as zsh will create new process
group for the command and change the terminal controlling process group
as well for the duration of the command.

The following is Linux-specific as it uses /proc but it seems to work
for me:

        is_foreground() {        
          local a           
          a=(${(s: :)${"$(< /proc/self/stat)"##*\) }})
          if [[ $a[3] == $a[6] ]]
          then
            return 0
          else
            return 1
          fi
        }

See man proc for the magic numbers.  $a[3] is the process group  (pgid
aka pgrp) and $a[6] is the controlling terminal process group id (tpgid)

> > I want to write a shell function that traps SIGCONT and does one thing or
> another thing depending on whether the function is CONTinuing in the
> background.

Please give a shot to the above.

> I'm not sure that would work for you anyway, because the timing of delivery
> of the signal to your function and to other jobs in the pipeline is not
> deterministic.  Also, because of vagaries of job control and memory
> management, the shell trap handler for CONT might not be called immediately.

That unfortunately still applies...

> Is there some other condition related to being in the background that you
> might test instead?  I.e. why does backgrounding require different behavior?

It can be handy to display/stop displaying a progress bar for example.

> > Furthermore, it’s not clear to me why a backgrounded function thinks its
> pid is the pid of the shell that spawned it.
> 
> That's the way the $$ variable is defined by the standard and is how all
> Unix shells have always behaved.
> 
> If you "zmodload zsh/system" the parameter $pid becomes available and has
> the value you want.

/proc/self as used above will always use the function's executing shell
pid and obviates the need for $pid.

Phil.

Re: shell function in the background?

[Peter Stephenson]

On Wed, 25 Jun 2014 08:55:49 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> If you "zmodload zsh/system" the parameter $pid becomes available and has
> the value you want.

Somewhat belated, but it's actually $sysparams[pid] to reduce the
namespace pollution.

pws