if we move the locale test completely to the C test file why don't we return result (pass/fail) in the exit code? ------------- #include <ctype.h> #include <locale.h> /* test for a correctly working locale. * for reference see: * http://czyborra.com/charsets/iso8859.html */ int main() { int rv = 0; setlocale (LC_ALL, ""); rv = rv || (toupper ((unsigned char) 'ä') == (unsigned char) 'Ä'); /* text ä to Ä */ rv = rv || (toupper ((unsigned char) 0xe4) == (unsigned char) 0xc4); /* codes for Latin[1-9] */ return ( ! rv ); /* revert to the shell meaning of the logic 0 == true; 0 != false */ } ------------- This way the test can be just a return value: ./"${A_OUT}" > /dev/null 2>&1
Jan
On Jan 26, 2005, at 11:56, Frank Heckenbach wrote:
jan.ruzicka@comcast.net wrote:
I would suggest rewrite the conditions to a multiple lines/blocks. something like :
gcc dummy.c > /dev/null 2>&1 if [ ! $? ]; then echo "failed: can not compile the test C code" exit(1) fi
Generally, I wouldn't object, but I find `||' easier to read (and more common, in shell scripts) than `[ ! $? ]'. (I'm generally a bit wary of `$?' because it adds an inter-statement dependency; adding something between the lines can cause non-obvious problems. So I rather don't use `$?' unless really necessary.)
You have a valid point.
Should it be then: ------------ gcc dummy.c > /dev/null 2>&1 ||\ echo "SKIPPED: can not compile the test C code" && exit 1 ------------
if [ ! -r $A_OUT ]; then echo "failed: can not read the test C code"
The compiled program, BTW.
exit(1)Shouldn't it be `exit 1'?
Also, I'd generally quote all variables in shell scripts unless explicitly meant not to. Though $A_OUT is probably harmless, anything that might contain a directory might also contain spaces nowadays, e.g. ...
printf "\x80" > ./${A_OUT}2.dat
comparison can be also ./$A_OUT 2> /dev/null | hexdump >./$A_OUT.dat # ... file tests as previous diff./$A_OUT.dat <<EOF 0000000 8000 0000001 EOF
Now, this is the actually tricky part. Apart from the fact that I'm not sure if we should require hexdump as a dependency, 80 is at least not the most common character code for A-umlaut.
Question is what exactly are we testing?
Are we testing that the compiler, shell and function toupper can work with non ASCII characters [in this case A umlaut]? printf ("%c\n", toupper ((unsigned char) '')); or
We shouldn't really test the shell.
Are we testing the ability of toupper converting a non ASCII character ? printf ("%c\n", toupper ((unsigned char) 0x80));
Is there any standard and portable way to obtain a selected localized letter? Example get platform representation of A-umlaut or u-circle.
The issue here is that different platforms can have different encoding of the character. Unicode vs. Latin-1, Windows etc.
Exactly.
Well, we can surely remove the shell non-ASCII dependency. E.g., we can check the result within the C program and output 1 if it matches:
printf ("%i\n", toupper ((unsigned char) 'ä') == (unsigned char) 'Ä');
[...]
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then
If we then move the C program to a separate file, the shell won't have to deal with those characters. E.g., put it in fjf165a.c and put this in the script:
#!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) if gcc "`dirname "$2"`"/fjf165a.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then rm -f "$A_OUT" $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else echo "SKIPPED: German locale not installed" fi
Then we've restricted those characters to the compilers which should at least read them. If they don't treat them as expected (Latin[129]/Unicode), the test will be skipped which is acceptable. If someone would like to add support for other charsets in fjf165a.{c,pas}, go ahead, but note that the main problem might be to find a suitable test for the current charset (a system conditional probably won't suffice).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8