On 5/22/12 9:16 AM, Roman Rakus wrote:
> On 05/22/2012 03:01 PM, Chet Ramey wrote:
>> On 5/22/12 8:41 AM, Roman Rakus wrote:
>>
>>> Another situation: You had previous trap handler and you are installing new
>>> one. The received signals are "paused" for a while and are processed right
>>> after th
On 05/22/2012 03:01 PM, Chet Ramey wrote:
On 5/22/12 8:41 AM, Roman Rakus wrote:
Another situation: You had previous trap handler and you are installing new
one. The received signals are "paused" for a while and are processed right
after the installation of new trap handler. There was a bug rep
On 5/22/12 8:41 AM, Roman Rakus wrote:
> Another situation: You had previous trap handler and you are installing new
> one. The received signals are "paused" for a while and are processed right
> after the installation of new trap handler. There was a bug report against
> this, I'm not sure if it
On 05/22/2012 02:28 PM, Greg Wooledge wrote:
I do not know the answers to "How does bash implement traps? Is there
a guarantee that no signals will be lost?" Hopefully someone else does.
I can just imagine a situation when the bash is reading trap from the
source (is going through the script a
On Tue, May 22, 2012 at 04:47:01AM -0700, Linda Walsh wrote:
> If you are in your trap handler, and you don't reset the signal --
> how can you guarantee that your signal handler will be reset
> before another even that would cause a trap occurs
You are using the wrong words for everything.
A sig
Andreas Schwab wrote:
A trap is not a signal. It doesn't "come in". A trap handler is
executed because some condition is true at a command boundary.
Andreas.
That still begs the question...
If you are in your trap handler, and you don't reset the signal --
how can you guarantee that you
A trap is not a signal. It doesn't "come in". A trap handler is
executed because some condition is true at a command boundary.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different.
Andreas Schwab wrote:
Bob Proulx writes:
And lastly I will comment that you are doing quite a bit inside of an
interrupt routine. Typically in a C program it is not safe to perform
any operation that may call malloc() within an interupt service
routine since malloc isn't reentrant. Bash i
Bob Proulx writes:
> And lastly I will comment that you are doing quite a bit inside of an
> interrupt routine. Typically in a C program it is not safe to perform
> any operation that may call malloc() within an interupt service
> routine since malloc isn't reentrant. Bash is a C program and I
--
Von: Bob Proulx [mailto:b...@proulx.com]
Gesendet: Donnerstag, 3. Mai 2012 09:08
An: Crueger, Tillmann
Cc: bug-bash@gnu.org
Betreff: Re: Possible bug: Race condition when calling external commands during
trap handling
tillmann.crue...@telekom.de wrote:
> I have produced the following script a
tillmann.crue...@telekom.de wrote:
> I have produced the following script as a small example:
A good small example! I do not understand the problem but I do have a
question about one of the lines in it and a comment about another.
> trap "kill $?; exit 0" INT TERM
What did you intend with "kill
Hi,
I have a problem with a trap handler in a script, which is doing some logging
and needs external commands (date and hostname). In some cases there seems to
be a race condition causing a syntax error every once in a while. I am assuming
it is a race condition, because the syntax errors only
12 matches
Mail list logo
