Re: [PATCH] t0005: ksh93 portability workaround

From: Jeff King <peff@peff.net>
Date: May 31, 2016, 23:03 UTC
Message-ID: <20160531230301.GB4585@sigill.intra.peff.net>
In-Reply-To: <xmqqinxt3kwq.fsf@gitster.mtv.corp.google.com>

On Tue, May 31, 2016 at 03:47:01PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> The test has two things ksh93 does not happy about:
> 
>  * It thinks "(( command1; command2 ) | command3)" is a perfectly
>    sane way to write a pipeline.  ksh93, unlike other POSIX shells,
>    does not like the two open parentheses next to each other for
>    whatever reason it has.
> 
>  * It adds 256, unlike 128 that are used by other POSIX shells, to
>    the signal number that caused the process to die when coming up
>    with the exit status.
> 
> What is interesting is that we knew about the latter issue and had a
> workaround in the test-sigchain test when verifying that SIGTERM
> works OK, but we didn't have corresponding workaround for SIGPIPE.

Hmm. We discussed these back in:

  http://thread.gmane.org/gmane.comp.version-control.git/268657

but I thought we decided not to do anything about them (according to that thread, I found a bunch of other ksh93 oddities, but maybe we've since fixed them?).

Show 9 quoted lines

> +died_with_sigpipe () {
> +	case "$1" in
> +	141 | 269)
> +		# POSIX w/ SIGPIPE=13 gives 141
> +		# ksh w/ SIGPIPE=13 gives 269
> +		true ;;
> +	*)	false ;;
> +	esac
> +}

This is OK, but I like the patch I posted in

  http://article.gmane.org/gmane.comp.version-control.git/268666

better, as it contains the shell logic in a single place (though I am not sure how these tests fare on Windows, where I think every signal just looks like "3").

-Peff