From: Brandon Casey <drafnel@gmail.com>

IRIX's fnmatch() does not support the GNU FNM_CASEFOLD extension, so set
NO_FNMATCH_CASEFOLD so that the internal fnmatch implementation will be
used.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 Makefile |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 57d9c65..ff35154 100644
--- a/Makefile
+++ b/Makefile
@@ -1003,6 +1003,7 @@ ifeq ($(uname_S),IRIX)
 	# issue, comment out the NO_MMAP statement.
 	NO_MMAP = YesPlease
 	NO_REGEX = YesPlease
+	NO_FNMATCH_CASEFOLD = YesPlease
 	SNPRINTF_RETURNS_BOGUS = YesPlease
 	SHELL_PATH = /usr/gnu/bin/bash
 	NEEDS_LIBGEN = YesPlease
@@ -1022,6 +1023,7 @@ ifeq ($(uname_S),IRIX64)
 	# issue, comment out the NO_MMAP statement.
 	NO_MMAP = YesPlease
 	NO_REGEX = YesPlease
+	NO_FNMATCH_CASEFOLD = YesPlease
 	SNPRINTF_RETURNS_BOGUS = YesPlease
 	SHELL_PATH=/usr/gnu/bin/bash
 	NEEDS_LIBGEN = YesPlease
-- 
1.7.3.1

--

[ message continues ]

From: Brandon Casey <drafnel@gmail.com>

POSIX awk seems to explicitly not support hexadecimal escape sequences.

From http://pubs.opengroup.org/onlinepubs/009695399/:

   Regular expressions in awk have been extended somewhat...
   One sequence that is not supported is hexadecimal value escapes
   beginning with '\x'.

This affects the awk on IRIX 6.5, and causes t4015.56 to fail.
Use octal instead.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/test-lib.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 48fa516..cb1ca97 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -260,7 +260,7 @@ test_decode_color () {
 			if (n == 47) return "BWHITE";
 		}
 		{
-			while (match($0, /\x1b\[[0-9;]*m/) != 0) {
+			while (match($0, /\033\[[0-9;]*m/) != 0) {
 				printf "%s<", substr($0, 1, RSTART-1);
 				codes = substr($0, RSTART+2, RLENGTH-3);
 				if (length(codes) == 0)
-- 
1.7.3.1

--

[ message continues ]

From: Brandon Casey <drafnel@gmail.com>

The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'.  More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.

See also:

907a0b1e04ea31cb368e9422df93d8ebb0187914
84eeb687de7a6c7c42af3fb51b176e0f412a979e
3fee1fe87144360a1913eab86af9ad136c810076

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/t9001-send-email.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 5e48318..1dc4a92 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -319,7 +319,7 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '
 	git send-email \
 		--from="Example <nobody@example.com>" \
 		--to=nobody@example.com \
-		--no-chain-reply-to \
+		--nochain-reply-to \
 		--in-reply-to="$(cat expect)" \
 		--smtp-server="$(pwd)/fake.sendmail" \
 		$patches $patches $patches \
-- 
1.7.3.1

--

[ message continues ]

This still leaves --no-bcc, --no-to and --no-cc in "no-foo overrides
sendemail.foo" tests, it seems.  Do they also need to be fixed?
--

[ message continues ]

No, those are handled completely separately.  The --chainreplyto
option is a boolean option, and the '--no' prefix is an automatic
feature that is provided by Getopt::Long for boolean options (i.e.
those suffixed with '!').

The three options you mentioned are actually distinct options that
are configured in the call to GetOptions and are named so that they
appear to be 'no-' prefixed automatic versions of --bcc, --to, and
--cc, just like the boolean options.  But there is really just a
separate option named --no-bcc, that sets the variable $no_bcc that
is distinct from the --bcc option which populates @bcclist.

So, people with a somewhat old Getopt::Long (or those accustomed
to prefixing '--no' without the dash) may get confused when they
have to leave off the dash when negating --chainreplyto as
--nochainreplyto, but _must_ use the dash when typing --no-bcc.
If we want to be consistent with Getopt::Long which accepts both
'--no-' and '--no', then we could add --nobcc, --noto, and --nocc.
Not sure if it's worth the trouble.

-Brandon
--

[ message continues ]

Thanks; I am unsure about the third one, though (see a separate message).
--

[ message continues ]

I haven't received a separate message about the 3rd patch.
Not sure if you sent it out yet, but fyi.

-Brandon
--

[ message continues ]