Mail #11284

Zurück zur Archiv-Hauptseite

Vorige Mail   Nächste Mail   Unformatiert/Volle Header
Übersicht  10 Tage   Betreff   Datum   Thread   Autor  

Von: jan.ruzicka@comcast.net
Betreff: compiling-update
Datum: 27.1.2005, 00:10:39

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 &auml; to &Auml; */
   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
>

Vorige Mail   Nächste Mail   Unformatiert/Volle Header
Übersicht  10 Tage   Betreff   Datum   Thread   Autor  

Antworten auf diese Mail

Antwort auf

Zurück zur Archiv-Hauptseite

Hinweis: Diese Seite enthält Informationen, die nicht vom Betreiber dieser Website, sondern von den Autoren der archivierten Mails stammen. Der Betreiber dieser Website ist nicht für den Inhalt dieser Informationen verantwortlich. Die weitere Verwendung dieser Informationen bedarf des Einverständnisses des jeweiligen Autors.

Sofern WWW-Adressen (URLs) in den archivierten Mails als Hyperlinks hervorgehoben werden, so geschieht dies ausschließlich zur Annehmlichkeit für den Leser. Der Inhalt der auf diese Weise angelinkten Webseiten spiegelt nicht notwendigerweise die Meinung des Betreibers dieser Webseite oder der Autoren der archivierten Mails wider. Der Betreiber dieser Webseite ist nicht für den Inhalt solcher Webseiten verantwortlich. Diese Seiten sind ausdrücklich nicht als Teil des Inhalts dieser Seite zu betrachten, sondern lediglich als Referenzen.

Diese Seite wurde erzeugt von Crystal 0.999 (Linux 2.4.27/i686).