Re: [PATCH] silent job monitor when 'set +m'

oups sorry you want to see the other errors from kill ... On Wed, Nov 11, 2009 at 9:02 AM, Pierre Gaston wrote: > of course I meant: > exec 3>&2 2>/dev/null #save stderr on fd3, redirect stderr to /dev/null >

Re: [PATCH] silent job monitor when 'set +m'

of course I meant: exec 3>&2 2>/dev/null #save stderr on fd3, redirect stderr to /dev/null

Re: [PATCH] silent job monitor when 'set +m'

On Wed, Nov 11, 2009 at 6:22 AM, Jeff Chua wrote: > On Wed, Nov 11, 2009 at 12:04 PM, Jeff Chua >wrote: > > > > > > > On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey > wrote: > > > >> > How do you silent this one without a subshell. > >> > >> What's wrong with the approach above? > >> > > > > Nothi

Re: [PATCH] silent job monitor when 'set +m'

On Wed, Nov 11, 2009 at 12:04 PM, Jeff Chua wrote: > > > On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey wrote: > >> > How do you silent this one without a subshell. >> >> What's wrong with the approach above? >> > > Nothing wrong, but can be made more efficient because "| grep" means > another subp

Re: [PATCH] silent job monitor when 'set +m'

On Wed, Nov 11, 2009 at 12:44 AM, Chet Ramey wrote: > > How do you silent this one without a subshell. > > What's wrong with the approach above? > Nothing wrong, but can be made more efficient because "| grep" means another subprocess which can be eliminated if the shell silents the Terminate co

Re: [PATCH] silent job monitor when 'set +m'

Jeff Chua wrote: > > On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera > mailto:jan.schamp...@web.de> > > >> wrote: > > > > Chet Ramey schrieb: > > > > > redirect stderr > > > kill pid > > >

Re: [PATCH] silent job monitor when 'set +m'

On Tue, Nov 10, 2009 at 11:09 PM, Chet Ramey wrote: > Jeff Chua wrote: > > > > > > On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera > > wrote: > > > > Chet Ramey schrieb: > > > > > redirect stderr > > > kill pid > > > wait pid > > > restore stderr >

Re: [PATCH] silent job monitor when 'set +m'

Jeff Chua wrote: > > > On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera > wrote: > > Chet Ramey schrieb: > > > redirect stderr > > kill pid > > wait pid > > restore stderr > > > > It seems to me that this sequence forces the necessary sync

Re: Error handling question

Marc Herbert wrote: > Chet Ramey a écrit : >>> The fact that "set -e" is not the default looks like a big design >>> mistake to me. >> Wow. That ship sailed 30 years ago. > > but forgot "set -e" on the quay? Maybe. But it's 30 years too late to change the default. -- ``The lyf so short, the c

Re: [PATCH] silent job monitor when 'set +m'

On Tue, Nov 10, 2009 at 6:20 AM, Jan Schampera wrote: > Chet Ramey schrieb: > > > redirect stderr > > kill pid > > wait pid > > restore stderr > > > > It seems to me that this sequence forces the necessary synchronicity. > > Interesting. And sad that I never thought of that > Will you consider h

Re: Error handling question

Marc Herbert a écrit : > Chris F.A. Johnson a écrit : >> For example, if you want to know whether user 'john' is in the >> password file: >> >> grep -q ^john: /etc/passwd >> >> You want to get the return code and execute code depending on the result >> >> (which can be 0, 1 or >1; 'if grep

Re: Error handling question

Chet Ramey a écrit : >> The fact that "set -e" is not the default looks like a big design >> mistake to me. > > Wow. That ship sailed 30 years ago. but forgot "set -e" on the quay? See also this ship:

Re: Error handling question

Chris F.A. Johnson a écrit : > It isn't desirable. However, commands will sometimes fail; they > are intended to fail. Their failure provides necessary information > to the script. Because it lacks proper exceptions, the language is indeed creating a confusion between exceptional erro