Coucou :-)
pour une fois je vais faire court :
Je suis d'accord avec tout ce qui a ete dit : du niveau supplementaire MAIN a
l'utilisation de ShiftMsgLevel tel que c'est presente ci-dessous.
Je vais d'ailleurs le coder, maintenant que j'ai enfin trouve mon bonheur au
niveau distro, en attendant Nasgaia ;-) (gentoo pour info) j'ai le temps pour
le faire :-)
++
Chicha
Quoting Gontran <[EMAIL PROTECTED]>:
Le Mardi 10 Mai 2005 19:45, Chicha a écrit :
>- On garde INFO, DETAIL et FULL (avec FULL : affichage de tout ce qui
> arrive)
Ok :-) (on est d'accord, il n'y aura pas de -v 1 ou -v 2.... ?
Oui, je confirme qu'il n'y aura pas de -v 1, -v 2, ... :-)
Par contre, j'aimerai ajouter un niveau supplémentaire à ceux existants.
Quelque chose comme "MAIN", ou tout autre appellation plus explicite, qui se
placerait avant INFO. Ça donnerait :
$ Ncooker -v MAIN check paquet.nbuild
Checking "paquet.nbuild" package ... [ OK ]
$ Ncooker -v INFO check paquet.nbuild
Checking "paquet.nbuild" package ...
Checking "infos" file ... [ OK ]
Checking "build" file ... [ OK ]
Checking "desc" file ... [ OK ]
Checking "changelog" file ... [ OK ]
$ ...
MAIN n'afficherait donc que l'action générale de la commande.
Une ébauche de solution alternative à shiftMsgLevel() :
[...]
Qu'est-ce que tu en penses ? (ainsi que tous ceux que ça intéresse... :-) )
C'est une possibilité :-)
Les fonctions shiftMsgLevel() et unshiftMsgevel() que j'ai proposé ne
s'utilisent pas tout à fait de la même manière. En fait, elles ne sont pas
lancés par la commande ou le module appelé, mais par la commande ou le module
appelant.
Pour reprendre ton exemple, ça donnerait ceci :
Avant de lancer la commande Check, la commande Pack appelle shiftMsgLevel.
Celle-ci positionne dans une variable globale le décalage de niveau de
verbosité à appliquer aux prochains messages. Ce décalage correspond par
défaut au niveau de verbosité du dernier message affiché + 1. Ou bien au
niveau de verbosité du dernier message affiché + le nombre passé en paramètre
à shiftMsgLevel(). Ainsi, la commande ou le module appelant peut contrôler
parfaitement le décalage à opérer.
Concrétement, dans Pack:
1 print_msg "INFO" "Packaging ${dir} directory ..."
2 shiftMsgLevel
3 run_command check
4 unshiftMsgLevel
Ligne 2, shiftMsgLevel est appelé sans paramètre. Le décalage appliqué aux
prochains messages va correspondre au niveau du dernier message affiché (donc
INFO, ligne 1) + 1, ce qui va amener à DETAIL. Lorsque la commande Check est
lancé ligne 3, le niveau de ses messages INFO va passer à DETAIL, ceux du
niveau DETAIL à FULL, etc. On retrouve ici le même principe que toi.
Lorsqu'on revient dans Pack après l'exécution de Check,
unshiftMsgLevel annule
le précédent décalage.
Si la ligne 2 est :
2 shiftMsgLevel 2
le décalage opéré est de INFO + 2 = FULL. Je n'ai pas d'exemple de cas
d'utilisation en tête, mais le cas échéant, ce serait disponible :-)
Autre avantage de faire ces appels de fonctions dans le module appelant, ça
évite des appels inutiles dans le cas où deux modules sont utilisés
successivement avec le même décalage. Par exemple :
1 print_msg "INFO" "Packaging ${dir} directory ..."
2 shiftMsgLevel
3 run_command check
4 run_command autre_commande
5 unshiftMsgLevel
Les fonctions shiftMsgLevel et unshiftMsgLevel ne sont appelées qu'une seule
fois pour les deux commandes lancées lignes 3 et 4.
Je trouve que laisser le contrôle au module appelant offre plus de souplesse.
Et vous ? :-)
++
Gontran
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
