gc a écrit 2109 commentaires

Bon j'ai peut-être été un poil trop loin mais le programme suivant devrait faire ton affaire. D'autre part, je te suggèrerais de faire cela sur le logout de tes users plutôt qu'en cron : moins bourrin et plus propre.

-=-=---=-=---=-=---=-=---=-=---=-=---=-=---=-=--
#!/usr/bin/perl

sub get_new_line {
    my ($user) = @_;
    open F, '/tmp/foo2';
    while () {
        if (/^\Q$user:/) {
            return $_;
        }
    }
    return undef;
}

sub subst_new_line {
    my ($user, $new_line) = @_;
    my $file = '/tmp/foo1';
    if (-s $file) {
        local @ARGV = $file;
        local $^I = '';
        local $_;
        while (<>) {
            if (/^\Q$user:/) {
                $_ = $new_line;
            }
            print;
        }
    }
}

my $new_line = get_new_line('bar');
if (defined($new_line)) {
    subst_new_line('bar', $new_line);
}
-=-=---=-=---=-=---=-=---=-=---=-=---=-=---=-=--

a ma connaissance le module samba de webmin est pourri et tu ferais mieux de te diriger vers swat.

N'hésite pas à aller mendier sur #mandrivafr@irc.freenode.net si personne ne te répond ; il est notoire que les mails publiques d'ex-mandrake ont plus d'un trou noir que d'une adresse fiable.

Le ski ca puxor.

Un jour tu passeras au snowboard "malgré moi" et tu verras la vie sous un nouveau jour. Le ciel sera plus bleu, les oiseaux chanteront, un brin d'herbe te chatouillera le cr^Hmenton, tu pourras envoyer des double mac-twist sur les barres rocheuses, et enfin tu diras oui, tu dirais oui à la vie, tu feras communion avec la nature pure et immaculée (moyennant quelques pylônes judicieusement placés c'est vrai), et tu sauras enfin ce que le mot "hors-piste" veut dire.

Je dirais qu'il faudrait alors que tu fasses un effort pour importer les données présentes dans les autres bases existantes, à la mesure du possible...

everaldo.

Je pense que le mieux est de faire du locking. Par exemple en utilisant flock.

J'y ai pensé aussi, mais je me suis dit que pour le peu d'effort que ça coutait en développement cela valait la peine.

Je ne parlais pas de l'effort de développer ton site, je parlais de l'effort de renseigner les bases hardware. Déjà qu'elles sont en général bien vides, parceller encore plus avec ta nouvelle base...

Ma question c'est pourquoi tu regardes une émission dont l'animateur ne laisse jamais ses invités développer une idée plus de 3 secondes et demie ?

est-ce que ca ne duplique pas les efforts deja consentis ailleurs ?

je pense à HCL et les bases hardwares des distribs par exemple.

Il faut aussi avoir installer libdv, libraw, libavc, libsamplerate ainsi que leur devel

Pourquoi "ainsi que leur devel" ?

Elle est sûrement complètement non-standard cette appli :/

D'une part ce n'est pas LANG comme je le dis plus loin, d'autre part ce n'est pas du tout conseillé de se fier à l'encoding par défaut du système, parce que si celui-ci change tous tes services vont foirer. Utiliser plutôt la méthode que je décris plus haut, qui configure précisément ce que l'on veut.

Ce n'est pas LANG.

import java.io.InputStreamReader;
import java.io.ByteArrayInputStream;

public class T {

    public static void main( String args[] ) {
        byte b[] = {};
        InputStreamReader isr
            = new InputStreamReader( new ByteArrayInputStream( b ) );
        System.out.println( "JVM's default encoding: " + isr.getEncoding() );

    }

}

Mon système est en en_US/UTF-8 :

[gc@meuh /tmp] java T
JVM's default encoding: UTF8

[gc@meuh /tmp] LANG=fr_FR java T
JVM's default encoding: UTF8

[gc@meuh /tmp] LC_CTYPE=fr_FR java T
JVM's default encoding: ISO8859_1

[gc@meuh /tmp] LC_ALL=fr_FR java T
JVM's default encoding: ISO8859_1

Regarde tes variables avec "locale". Change la locale du système avec l'outil dispo avec ton système si tu en as un (localedrake chez mandrak^Hiva), sinon cherche des docs là-dessus. Mais en général LC_ALL suffit pour passer devant toutes les autres (sauf LANGUAGE).

Tu devrais utiliser valgrind. Il t'aurait trouvé ça tout de suite (et justement avant que ça plante, ce qui t'aurait permis de résoudre ton problème en deux secondes).

Quant à gdb cité par d'autres, tu devrais aussi l'utiliser, mais dans le cas de corruption mémoire comme ton problème, c'est inutile car le programme plantera parfois plusieurs centaines de lignes après l'origine de la corruption mémoire (souvent c'est un plantage dans la glibc d'ailleurs, ce qui est au mieux drôle et au pire rageant).

Le tag HTML dont tu parles passes au second plan par rapport à l'entête HTTP Content-Type, lorsque le browser reçoit la réponse. Si une telle entête est présente (et à ma connaissance tomcat la place) alors ton tag HTML sera ignoré.

En théorie, tu utilises Tomcat pour servir une servlet pure, ou du JSP. Le mieux est de servir ton contenu textuel en provenance de fichiers properties ou d'une base de données, pour pouvoir avoir des sources et JSP moins crades et plus maintenables, et la localisation des messages. Dans ce cas-là, ton contenu sort d'une String java, et la question est de permettre à tomcat de savoir quel codage utiliser pour les afficher. Tomcat se servira du ContentType associé à l'objet HttpServletResponse. Plusieurs solutions :

- tu fais une servlet java pure (pas de JSP et pas d'HTML) dans ce cas-là utiliser response.setContentType( "text/html; charset=UTF-8" ); pour forcer le type (il est même possible que ce ne soit pas nécessaire dans ce cas-là - mais en général c'est utile, on verra plus loin pourquoi)

- tu fais du JSP ; dans ce cas-là utiliser <%@ page contentType="text/html;charset=UTF-8" language="java" %>

- tu mets du texte en dur dans du JSP ou de l'HTML ; dans le premier cas utilise la directive page de la ligne précédente pour préciser le charset dans lequel est encodé ton texte ; dans le deuxième cas, aucune idée :) mais tu peux très bien utiliser un JSP avec seulement cette directive et tout le reste en HTML pur


La problématique principale pour l'internationalisation avec tomcat est la façon dont tu vas recevoir les données entrées par les utilisateurs. Il s'agit des données passées par HTTP GET (URL avec paramètres derrière) ou HTTP POST (formulaire). Le problème est dans le premier cas qu'il n'existe pas de standard pour indiquer le codage des caractères (qui sont eux-même URL-encodés bien sûr), dans le second cas que les navigateurs n'envoient pas dans l'entête Content-Type le codage utilisé. D'après ce que j'avais vu dans le bugzilla de Mozilla (mais je ne retrouve plus la référence), ils avaient corrigé ce "problème" mais ça en créait trop de nouveaux dans les serveurs web existants.

La meilleure solution consiste donc à faire en sorte d'être raisonnablement sûr que le navigateur enverra les informations dans un codage déterminé.

La solution la plus simple à mettre en oeuvre et de tout faire en UTF-8. Ça permet une internationalisation sans soucis et c'est bien supporté par les navigateurs (même la passoire bien connue qui sert de navigateur dominant actuellement).


Dans le cas des informations reçues par HTTP GET, en général il s'agit d'un lien que tu auras créé dynamiquement dans ta servlet ou ton JSP. Assure-toi de le créer en UTF-8, et ajoute useBodyEncodingForURI="true" dans les attributs du Connector de ton server.xml (à partir de tomcat 5).


Dans le cas des informations reçues par HTTP POST, il s'agit de ce que l'utilisateur aura entré dans son navigateur. Comme je le disais plus haut, les navigateurs n'envoient pas le codage utilisé, donc lorsque tomcat va recevoir ces informations, il ne pourra pas savoir comment décoder les caractères - et par défaut il utilise ISO-8859-1 (c'est dans la norme des servlets).

    Envoi (point de vue du navigateur)

Pour être sûr que le navigateur enverra les informations en UTF-8, en théorie c'est vers l'attribut accept-charset="UTF-8" de l'élément form qu'il faudrait se tourner, mais l'implémentation actuelle des navigateurs pousse à une autre solution : faire en sorte que la page qui contenait le formulaire soit elle-même codée en UTF-8. Pour ce faire, voir plus haut - response.setContentType( "text/html; charset=UTF-8" ); et <%@ page contentType="text/html;charset=UTF-8" language="java" %> sont la meilleure solution.

    Réception (point de vue de ta servlet)

Ensuite, comme je le disais plus haut, il faut s'assurer que tomcat décodera les informations reçues avec le codage UTF-8. Le plus simple est de forcer le codage de HttpServletRequest : request.setCharacterEncoding( "UTF-8" );. Pour ne pas dupliquer cela dans tous les JSP et servlets, le mieux est d'utiliser un Filter, par exemple SetCharacterEncodingFilter.java qui est disponible en standard avec tomcat.


En espérant t'avoir été agréable.

doigtés

\o/ génial !

n'importe quoi :) un suffixe typiquement féminin serait pas bien pour un nom féminin, déjà c'est fort. ensuite, euh et "la conectiva" ou "la fedora" c'est différent ? et "la debiAn" hope un "a" pan ça pux ?

trouver un nom c'est extrêmement dur. "mandriva" ne sonne pas pire que "mandrake" de toutes façons (la différence c'est qu'on est habitué à "mandrake" et on entend plus la connotation véhiculée que la phonétique).

a ma connaissance y'a pas de raison que gcc puisse pas crosscompiler pour 68k (par contre il va falloir te compiler ton propre gcc pour faire ca).

par contre le binaire produit sera fonction de l'OS destination (linux 68k, je sais pas si c'est possible de faire autre chose) et donc pour executer tu vas pas pouvoir le faire direct.

Je te comprends, la référence à Célio, la marque qui a les pubs les plus sexistes du moment, c'est pas glorieux.

BORDEL mais on est ou là ? Vous imaginez Renault disant "vous avez le droit de conduire une Renault sauf si vous voulez vous rendre dans une usine citroën" ?

Tu es de mauvaise foi. L'analogie correcte est Renault disant "je vous donne ou prête gratuitement une Renault mais vous ne vous rendez pas dans une usine Citroën avec". Ben désolé mais je trouve ça compréhensible. Tu aides quelqu'un et tu lui demandes de ne pas te niquer par derrière.

C'est pas ça le problème. Lisez l'article.

Le problème c'est que des gens employés d'OSDL ont fait du reverse-engineering. D'une part ce n'est pas comme si c'était n'importe qui, et d'autre part c'est l'employeur de Linus. BitMover trouve que c'est du foutage de gueule et çe se comprend.

Généralement, c'est une bonne émission. Ils invitent rarement des politiques mais souvent des "experts" (institut de sondage, politologue, etc).

Généralement, c'est une mauvaise émission. L'animateur ne laisse pas parler les invités et a des opinions réactionnaires.

installe lex ("urpmi flex" en root)

ou, mieux, installe PHP5 directement avec les package mandrake des contribs.