jan.ruzicka@comcast.net wrote:
Lets split it into blocks:
- 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.
- [ -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.
- 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