[PATCH] jobs: Always reset SIGINT/SIGQUIT handlers

setsignal(SIGQUIT); > > + } > > setsignal(SIGTERM); > > } > > + > > + if (lvforked) > > + return; > > + > > for (jp = curjob; jp; jp = jp->prev_job) > > freejob(jp); > > } > > This leaves

Re: [PATCH] jobs: Block signals during tcsetpgrp

On Wed, Jan 6, 2021 at 10:17 PM Harald van Dijk wrote: > On 06/01/2021 04:45, Herbert Xu wrote: > > This patch implements the blocking of SIGTTOU (and everything else) > > while we call tcsetpgrp. > > > > Reported-by: Steffen Nurpmeso > > Signed-off-by: Herbert Xu > > > > diff --git

Re: [PATCH] jobs: Block signals during tcsetpgrp

On Wed, Jan 06, 2021 at 09:16:58PM +, Harald van Dijk wrote: > On 06/01/2021 04:45, Herbert Xu wrote: > > This patch implements the blocking of SIGTTOU (and everything else) > > while we call tcsetpgrp. > > Reported-by: Steffen Nurpmeso > > Signed-off-by: Herbert Xu > > diff --git

Re: [PATCH] jobs: Block signals during tcsetpgrp

On 06/01/2021 04:45, Herbert Xu wrote: This patch implements the blocking of SIGTTOU (and everything else) while we call tcsetpgrp. Reported-by: Steffen Nurpmeso Signed-off-by: Herbert Xu diff --git a/src/jobs.c b/src/jobs.c index 516786f..809f37c 100644 --- a/src/jobs.c +++ b/src/jobs.c @@

[PATCH] jobs: Block signals during tcsetpgrp

Harald van Dijk wrote: > On 19/12/2020 22:21, Steffen Nurpmeso wrote: >> Steffen Nurpmeso wrote in >> <20201219172838.1b-wb%stef...@sdaoden.eu>: >> |Long story short, after falsely accusing BSD make of not working >> >> After dinner i shortened it a bit more, and attach it again, ok? >> It

[PATCH] jobs: Only block in waitcmd on first run

This patch ensures that waitcmd never blocks unless there are outstanding jobs. This could otherwise trigger a hang if children were created prior to the shell coming into existence, or if there are backgrounded children of other kinds (e.g., a here- document). Fixes: 6c691b3e5099 ("jobs:

[PATCH] jobs: Fix waitcmd busy loop

("jobs: Only clear gotsigchld when waiting...") Signed-off-by: Herbert Xu diff --git a/src/jobs.c b/src/jobs.c index 94bf47e..3417633 100644 --- a/src/jobs.c +++ b/src/jobs.c @@ -1135,7 +1135,6 @@ static int dowait(int block, struct job *jp) rpid = 1;

[v3 PATCH 4/17] jobs: Only clear gotsigchld when waiting for everything

either the given job is not running, or until all terminated jobs have been processed, this patch moves the loop into dowait itself. Fixes: 03876c0743a5 ("eval: Reap zombies after built-in...") Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> --- s

[v3 PATCH 8/17] jobs: Replace some uses of fmtstr with stpcpy/stpncpy

ar *os, int status, int sigonly) { - int col; + char *s = os; int st; - col = 0; st = WEXITSTATUS(status); if (!WIFEXITED(status)) { #if JOBS @@ -426,21 +425,21 @@ sprint_status(char *s, int status, int sigonly) goto out;

[v2 PATCH 4/12] jobs: Only clear gotsigchld when waiting for everything

either the given job is not running, or until all terminated jobs have been processed, this patch moves the loop into dowait itself. Fixes: 03876c0743a5 ("eval: Reap zombies after built-in...") Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> --- s

jobs

Hello, trying to keep my shell scripts portable, I am also testing on systems which use dash; for instance, /bin/sh is dash in Ubuntu. That's where my scripts fail because of how the "jobs" builtin behaves. First of all, "jobs" is not even mentioned in http://git.kernel

Re: [PATCH v2] jobs: Handle string-based job descriptors

On Mon, 6 Jun 2016 22:45:27 +0800, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 09:54:31AM +0200, Stephen Kitt wrote: > > When looking for a job using a string descriptor, e.g. > > > > fg %man > > > > the relevant loop in src/jobs.c only ever exits to the err

Re: The behavior of `jobs -p` is definitely, without a doubt, a bug

On Wed, 18 May 2016 14:03:59 -0700 Harald van Dijk <har...@gigawatt.nl> wrote > Hi, > > On 13/05/16 04:06, Geoff Nixon wrote: > > Let me start with a couple of corrections to that previous thread. > > > > > > 1. The line: jobs -p

The behavior of `jobs -p` is definitely, without a doubt, a bug

e all of "no", and "you should just use $!". So I guess rather than a "bug report" per se, this is a vociferous argument questioning that conclusion, and a request that it be reconsidered. To me, this is definitely, absolutely, positively a bug. --- Let me start wit

Re: Inconsistent behaviour between 'jobs' and 'echo $(jobs)'

On Tue, Jan 20, 2015 at 06:01:10PM +0100, Damian Wrobel wrote: I would prefer not to code something like the following: $ jobs -p /tmp/jobs-$$ kill $(cat /tmp/jobs-$$); rm /tmp/jobs-$$ As a better alternative, you could maybe try this: trap : TERM # in case we have something to do after

Re: Inconsistent behaviour between 'jobs' and 'echo $(jobs)'

On 01/20/2015 09:44 AM, Seb wrote: On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote: Hello, I'm observing an inconsistent behaviour between: jobs and echo $(jobs) It's because the command is ran in a sub-shell, where there is indeed no running job. Bash has a special

Re: Inconsistent behaviour between 'jobs' and 'echo $(jobs)'

On Tue, Jan 20, 2015 at 06:01:10PM +0100, Damian Wrobel wrote: On 01/20/2015 09:44 AM, Seb wrote: On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote: Hello, I'm observing an inconsistent behaviour between: jobs and echo $(jobs) It's because the command is ran in a sub

[PATCH 1/2] [JOBS] Debug compile fix

No point in tracing a no longer undeclared ps-cmd, fixes: jobs.c: In function ‘commandtext’: jobs.c:1192: error: ‘ps’ undeclared (first use in this function) jobs.c:1192: error: (Each undeclared identifier is reported only once jobs.c:1192: error: for each function it appears in.) Signed-off-by:

Re: [JOBS] Do not close stderr when /dev/tty fails to open

On Sun, Feb 22, 2009 at 07:33:04PM +0800, Herbert Xu wrote: [JOBS] Do not close stderr when /dev/tty fails to open Turns out that there was more to this than jobs.c The use of savefd in redir ended up closing the wrong file descriptor too, albeit in a harmless manner. I'm going to throw