On Fri, Feb 13, 2015 at 02:44:03AM -0500, Jeff King wrote:
> On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
>
> > On the NonStop port, we found that trap was causing an issue with test
> > success for t5570. When start_git_daemon completes, the shell (ksh,bash) on
> > this platform is sending a signal 0 that is being caught and acted on by the
> > trap command within the start_git_daemon and stop_git_daemon functions. I am
> > taking this up with the operating system group,
>
> Yeah, that seems wrong. If it were a subshell, even, I could see some
> argument for it, but it seems odd to trap 0 when a function returns
> (bash does have a RETURN trap, which AFAIK is bash-specific, but it
> should not trigger a 0-trap).
Hmm, today I learned something new about ksh. Apparently when you use
the "function" keyword to define a function like:
function foo {
trap 'echo trapped' EXIT
}
echo before
foo
echo after
then the trap runs when the function exits! If you declare the same
function as:
foo() {
trap 'echo trapped' EXIT
}
it behaves differently. POSIX shell does not have the function keyword,
of course, and we are not using it here. Bash _does_ have the function
keyword, but seems to behave POSIX-y even when it is present. I.e.,
running the first script:
$ ksh foo.sh
before
trapped
after
$ bash foo.sh
before
after
trapped
$ dash foo.sh
foo.sh: 3: foo.sh: function: not found
foo.sh: 5: foo.sh: Syntax error: "}" unexpected
Switching to the second form, all three produce:
before
after
trapped
I don't know if that is all helpful to your bug-tracking or analysis,
but for whatever reason it looks like your ksh is using localized traps
for both forms of function. But as far as I know, bash has never behaved
that way (I just grepped its CHANGES file for mentions of trap and found
nothing likely).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
