On Mon, Jul 20, 2026 at 03:58:08PM +0200, Bruno Haible via Bug reports for the
GNU Texinfo documentation system wrote:
> On Solaris 11.4, today's CI run reports a new test failure:
>
> FAIL: t/quoted-index-target.sh
>
> I reproduce it locally in a Solaris 11.4 VM. Find attached the
> info/test-suite.log file.
Thanks for keeping an eye on this. It is no surprise that the use of
a "character class" ("[:cntrl:]") in the grep regex caused a problem in
this recently introduced test (assuming that's the problem).
I did try to research whether this usage would be portable when this
test was first added, on 11 July. :cntrl: is in the POSIX standard
for Basic Regular Expression (*). I checked the autoconf manual (**)
and GNU grep manual (***) also, but didn't see anything wrong.
(*)
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
(**)
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.73/html_node/Limitations-of-Usual-Tools.html
(***)
https://www.gnu.org/software/grep/manual/html_node/Problematic-Expressions.html#Problematic-Expressions
The online Solaris documentation I could find (+)(++) does document :cntrl:.
(+) https://docs.oracle.com/cd/E88353_01/html/E37839/grep-1.html
(++)
https://docs.oracle.com/cd/E88353_01/html/E37853/regex-7.html#REFMAN7regex-7
Well, when I managed to find a Solaris system to log into, its grep didn't
seem to recognise character classes at all.
gavin@s11-sparc:~$ uname -a
SunOS s11-sparc.cfarm 5.11 11.4.93.221.2 sun4v sparc sun4v logical-domain
The "grep" man page there refers to a "regexp(7)" page:
/usr/bin/grep
The /usr/bin/grep utility uses limited regular expressions like those
described on the regexp(7) manual page to match the patterns.
/usr/xpg4/bin/grep
The options -E and -F affect the way /usr/xpg4/bin/grep interprets pat-
tern_list. If -E is specified, /usr/xpg4/bin/grep interprets pat-
tern_list as a full regular expression (see -E for description). If -F
is specified, grep interprets pattern_list as a fixed string. If nei-
ther are specified, grep interprets pattern_list as a basic regular ex-
pression as described on regex(7) manual page.
Accessing this with "man -s 7 regexp":
Regular Expressions (REs) provide a mechanism to select specific
strings from a set of character strings. The Simple Regular Expressions
described below differ from the Internationalized Regular Expressions
described on the regex(7) manual page in the following ways:
o only Basic Regular Expressions are supported
o the Internationalization features--character class, equiva-
lence class, and multi-character collation--are not sup-
ported.
Indeed:
gavin@s11-sparc:~$ printf 'A\n' | grep '[[:alpha:]]'
gavin@s11-sparc:~$ echo $?
1
gavin@s11-sparc:~$ printf 'A\n' | /usr/xpg4/bin/grep '[[:alpha:]]'
A
gavin@s11-sparc:~$ echo $?
0
gavin@s11-sparc:~$
So I suppose we should find some other way to match the DEL character in
the output - or change this test to work differently. I don't want to
use a raw DEL byte in the test file (as it's hard to type in my text
editor), and there isn't a portable Bourne shell way to escape
a character AFAIK (bash has $'...').
As the autoconf manual says, "POSIX does not specify the behavior of
grep on binary files." So trying to match the output which may contain
a DEL byte is probably not worth trying to do reliably.
The best idea I have is to delete the DEL bytes before piping
to grep. I've committed this change today (git commit 8a082ce77d1e0).
>
> ======================================================
> GNU Texinfo 7.3.20260720dev: info/test-suite.log
> ======================================================
>
> # TOTAL: 91
> # PASS: 90
> # SKIP: 0
> # XFAIL: 0
> # FAIL: 1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: t/quoted-index-target.sh
> ==============================
>
> + ginfo=./ginfo
> + INFOPATH=../../info/t/infodir
> + export INFOPATH
> + HOME=''
> + export HOME
> + XDG_CONFIG_HOME=../../info/t/config
> + export XDG_CONFIG_HOME
> + t=../../info/t
> + export t
> + basename ../../info/t/quoted-index-target.sh.out
> + ginfo_output=t/quoted-index-target.sh.out
> + basename ../../info/t/quoted-index-target.sh.pipein
> + pipein=t/quoted-index-target.sh.pipein
> + basename ../../info/t/quoted-index-target.sh.pipeout
> + pty_type=t/quoted-index-target.sh.pipeout
> + rm -f t/quoted-index-target.sh.out
> + INFO_PRINT_COMMAND='>t/quoted-index-target.sh.out'
> + export INFO_PRINT_COMMAND
> + pty_pid=0
> + LC_ALL=C
> + export LC_ALL
> + TERM=dumb
> + export TERM
> + trap cleanup 2
> + path_sep=:
> + initialization_done=0
> + true 10
> + ./ginfo --file quoting --index-search 'Colon::in, name' --all
> + 1> t/quoted-index-target.sh.out
> info: "../../info/t/config/texinfo/infokey", line 2: unknown action
> `xxx-not-recognized'
> info: "../../info/t/config/texinfo/infokey", line 3: cannot bind key sequence
> to menu-digit
> + q='[[:cntrl:]]\{0,1\}'
> + grep '\* Colon::in, name: *[[:cntrl:]]\{0,1\}Colon::in,
> name[[:cntrl:]]\{0,1\}.' t/quoted-index-target.sh.out
> + retval=1
> + cleanup
> + test 0 -ne 0
> + rm -f t/quoted-index-target.sh.out
> + rm -f t/quoted-index-target.sh.pipein t/quoted-index-target.sh.pipeout
> + exit 1
> FAIL t/quoted-index-target.sh (exit status: 1)
>
