jan.ruzicka@comcast.net wrote:
Lets split it into blocks: 1) gcc dummy.c > /dev/null 2>&1 compiles dummy.c and redirects output (stdout,stderr) to /dev/null (bit bucket)
Yes, because failure doesn't necessarily mean a problem with GPC, but perhaps just that the German locale is not installed, and the test should be skipped.
2) [ -r "$A_OUT" ] test if $A_OUT exists and is readable.
Yes, perhaps superfluous since the next step would fail as well, but shouldn't hurt.
3) x"`./"$A_OUT" 2> /dev/null`" = x"Â" test if $A_OUT outputs  3.a) `./"$A_OUT" 2> /dev/null` execute $A_OUT and redirect stderr to /dev/null 3.b) compare outputs
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.)
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