> "CR" == Chet Ramey writes:
CR> Is everything you don't like that's not explicitly documented a bug? In
CR> any case, a little thought should tell you why having the shell stick
CR> around long enough to catch the child's death makes a difference.
With me you can exclude the concept of thou
On 1/29/11 7:33 PM, jida...@jidanni.org wrote:
>> "CR" == Chet Ramey writes:
> CR> Is it a problem? Bash prints messages about signal-terminated processes
> --
> CR> at least those that don't die due to SIGINT or SIGPIPE -- when the
> CR> shell is not interactive. Most people want to know w
Don't forget to mention that there better be e.g., at least a sleep 0
after it, if they want to be sure to see the message.
> "CR" == Chet Ramey writes:
CR> Is it a problem? Bash prints messages about signal-terminated processes --
CR> at least those that don't die due to SIGINT or SIGPIPE -- when the
CR> shell is not interactive. Most people want to know when their jobs die
CR> and their scripts fail.
But some
On 1/28/11 10:11 PM, jida...@jidanni.org wrote:
> I isolated the problem and submitted
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611417 which I forget
> to X-Debbugs-cc to bash-...@gnu.org, which I should have, as it probably
> is a upstream problem that only the bash authors can fix.
Is
On 1/25/11 10:08 PM, Peter O'Gorman wrote:
> Hi,
>
> Dan reported a libtool performance regression in libtool-2.4 when running
> his binaries with a large number of arguments.
>
> Libtool creates a shell script which usually sets some env vars and runs
> the binary, new in recent libtool, the scr
