Re: [PATCH] small doc typos
On 11/21/23 6:37 PM, Grisha Levit wrote: diff --git a/doc/bash.1 b/doc/bash.1 Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] tests/unicode1.sub: fixup
On 11/22/23 7:46 PM, Grisha Levit wrote:
Many of the tests in unicode.sub don't actually run because the arrays
containing codepoints to test are sparse and the TestCodePage function
assumes that they are not.
Thanks for the report. Nice attention to detail. This test has not changed
substantially since it was donated in 2012. Namerefs didn't exist then, and
my guess is that John Kearney wasn't familiar or comfortable with ${!x[@]}.
https://lists.gnu.org/archive/html/bug-bash/2012-02/msg00063.html
If that's fixed, the zh_TW.BIG5 tests run but fail. I'm not sure what
the original intent was, they seem to expect U+00F6..U+00FE to be
encoded as 0xF6..0xFE which is not the case.
You'd have to ask John, I guess. These tests never got run in any
case, since the original code, as you pointed out, assumed the array
wasn't sparse, and the discrepancy never got discovered. My guess is
the point is to check how codepoints that don't encode valid characters
in the target character set (though 0xf7 is valid) are displayed, but
you can't be sure. In any case, they're just wrong.
This was part of a much wider discussion about unicode character conversion
in bash-4.2, which you might find interesting as a twelve-year-old
discussion.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
tests/glob2.sub failure on macOS 14
In macOS 14 (Sonoma), Apple switched from GNU to BSD-based iconv, which
have slightly different charset definitions. The tests in glob2.sub test
U+03B1 in zh_HK.big5hkscs, but this codepoint is not present in the BSD
BIG5-HKSCS definition, so the test fails.
The codepoint does exist in the BIG5 charset in both GNU and BSD versions
(with the encoding that the test expects) so I think changing this test
from zh_HK.big5hkscs to zh_TW.big5 would make it work as intended on both
system types.
---
diff --git a/tests/glob2.sub b/tests/glob2.sub
index 09cb6d51..7425ea4a 100644
--- a/tests/glob2.sub
+++ b/tests/glob2.sub
@@ -14,10 +14,10 @@
. ./test-glue-functions
# this locale causes problems all over the place
-if locale -a | grep -i '^zh_HK\.big5hkscs' >/dev/null ; then
+if locale -a | grep -i '^zh_TW\.big5' >/dev/null ; then
:
else
-echo "glob2.sub: warning: you do not have the zh_HK.big5hkscs
locale installed;" >&2
+echo "glob2.sub: warning: you do not have the zh_TW.big5
locale installed;" >&2
echo "glob2.sub: warning: that will cause some of these tests
to fail." >&2
fi
@@ -41,7 +41,7 @@ esac
[[ $var = $var ]] && echo ok 4
[[ $var = $'ab\134' ]] && echo ok 5
-LC_ALL=zh_HK.big5hkscs
+LC_ALL=zh_TW.big5
read a b c <<< $'\u3b1 b c\n'
echo $b
@@ -62,4 +62,4 @@ printf "%s" "a${alpha}b" | LC_ALL=C od -b |
_intl_normalize_spaces
a=$'\u3b1'
[[ $a = $a ]] && echo ok 6
-LC_ALL=zh_HK.big5hkscs ${THIS_SH} -c $'[[ \u3b1 = \u3b1 ]]' && echo ok 7
+LC_ALL=zh_TW.big5 ${THIS_SH} -c $'[[ \u3b1 = \u3b1 ]]' && echo ok 7
Many of the example loadable builtins don't work anymore
Many of the loadable builtins that set variables in the
examples/loadables directory don't work anymore because they still want
to call legal_identifier instead of valid_identifier.
$ ./bash -c 'enable -f {examples/loadables/,}mktemp; mktemp'
/tmp/shtmp.h2HpWZ
$ ./bash -c 'enable -f {examples/loadables/,}mktemp; mktemp -v foo'
./bash: symbol lookup error: examples/loadables/mktemp: undefined symbol:
legal_identifier
Replacing legal_identifier with valid_identifier should resolve the
issue:
$ git grep -l legal_ examples/loadables
examples/loadables/asort.c
examples/loadables/cut.c
examples/loadables/dsv.c
examples/loadables/kv.c
examples/loadables/lcut.c
examples/loadables/mktemp.c
examples/loadables/print.c
examples/loadables/realpath.c
examples/loadables/stat.c
o/
emanuele6
Re: Many of the example loadable builtins don't work anymore
I've noticed that a lib/sh/compat.c file was added that still provides the declaration for the legacy legal_ functions. The bash executable I was getting from building the devel branch did not have those symbols though. The reason was that lib/sh/Makefile was not getting regenerated, so the recipe for libsh.a did not include compat.o. Re-building bash from a clean tree correctly produces a bash with legal_ symbols. o/ emanuele6
Re: [PATCH] tests/unicode1.sub: fixup
On Fri, Nov 24, 2023, 17:32 Chet Ramey wrote:
> Thanks for the report. Nice attention to detail. This test has not changed
> substantially since it was donated in 2012. Namerefs didn't exist then, and
> my guess is that John Kearney wasn't familiar or comfortable with ${!x[@]}.
>
> https://lists.gnu.org/archive/html/bug-bash/2012-02/msg00063.html
>
> > If that's fixed, the zh_TW.BIG5 tests run but fail. I'm not sure what
> > the original intent was, they seem to expect U+00F6..U+00FE to be
> > encoded as 0xF6..0xFE which is not the case.
>
> You'd have to ask John, I guess. These tests never got run in any
> case, since the original code, as you pointed out, assumed the array
> wasn't sparse, and the discrepancy never got discovered. My guess is
> the point is to check how codepoints that don't encode valid characters
> in the target character set (though 0xf7 is valid) are displayed, but
> you can't be sure. In any case, they're just wrong.
>
> This was part of a much wider discussion about unicode character conversion
> in bash-4.2, which you might find interesting as a twelve-year-old
> discussion.
>
Thanks for all the info. I only noticed the problem when trying to figure
out the Big5 macOS 14 test failure that I posted about earlier today.
>
Re: Many of the example loadable builtins don't work anymore
On Sat, Nov 25, 2023 at 04:32:36AM +0100, Emanuele Torre wrote:
> I've noticed that a lib/sh/compat.c file was added that still provides
> the declaration for the legacy legal_ functions.
>
> The bash executable I was getting from building the devel branch did not
> have those symbols though.
>
> The reason was that lib/sh/Makefile was not getting regenerated, so the
> recipe for libsh.a did not include compat.o.
>
> Re-building bash from a clean tree correctly produces a bash with legal_
> symbols.
Actually, nevermind that message. It still does not work. I was building
master instead of devel.
Now I can see that compat.o is actually being used to create
lib/sh/libsh.a, and that libsh.a contains the legal_ symbols
$ make -j
[...]
ar cr libsh.a clktck.o clock.o getenv.o oslib.o setlinebuf.o strnlen.o
itos.o zread.o zwrite.o shtty.o shmatch.o eaccess.o netconn.o netopen.o
timeval.o makepath.o pathcanon.o pathphys.o tmpfile.o stringlist.o stringvec.o
spell.o shquote.o strtrans.o snprintf.o mailstat.o fmtulong.o fmtullong.o
fmtumax.o zcatfd.o zmapfd.o winsize.o wcsdup.o fpurge.o zgetline.o mbscmp.o
mbsncmp.o uconvert.o ufuncs.o casemod.o input_avail.o mbscasecmp.o fnxform.o
unicode.o shmbchar.o strvis.o strscpy.o anonfile.o compat.o utf8.o random.o
gettimeofday.o timers.o wcsnwidth.o mbschr.o
[...]
$ grep -abo legal_identifier lib/sh/libsh.a
2579:legal_identifier
567032:legal_identifier
But the bash executable still does not contain the legal_ symbols:
$ grep -abo legal_identifier ./bash || echo nope
nope
$ ./bash -c 'enable -f {examples/loadables/,}mktemp; mktemp -v foo'
./bash: symbol lookup error: examples/loadables/mktemp: undefined symbol:
legal_identifier
o/
emanuele6
