From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4624 invoked by alias); 25 Jun 2014 18:05:05 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32803 Received: (qmail 11487 invoked from network); 25 Jun 2014 18:04:49 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 Message-ID: <1403718974.2469.11.camel@niobium.home.fifi.org> Subject: Re: shell function in the background? From: Philippe Troin To: Bart Schaefer Cc: Dave Yost , zsh-workers@zsh.org Date: Wed, 25 Jun 2014 10:56:14 -0700 In-Reply-To: References: <2C39FCD4-02E6-4957-B292-486065C24639@yost.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 2014-06-25 at 08:55 -0700, Bart Schaefer wrote: > On Jun 25, 2014 9:34 AM, "Dave Yost" 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.