24/06/2009, 02:55
(This post was last modified: 24/06/2009, 03:18 by MenzAgitat.)
Restez zen les gars, c'est un forum d'entraide donc inutile de poster pour dire "démerde-toi", d'autant qu'il vous dit qu'il ne scripte pas.
@frisk :
Je ne suis pas sûr que ce que tu veux soit possible car charger un script ne déclare rien de particulier hormis les élément qu'il contient.
Il est possible de lister les variables utilisées, les procédures, les binds etc... mais pas les scripts, je le crains.
Si tu es organisé et que tu ne laisses que les scripts que tu utilises dans le répertoire scripts, tu peux toujours compter sur la commande :
pour t'afficher la liste des .tcl qui se trouvent dans eggdrop/scripts.
Quelques autres commandes éventuellement utiles :
afficher une liste des variables déclarées :
afficher une liste des procédures existantes
afficher le contenu d'une procédure
afficher une liste des variables globales
Les masques de recherche supportent les jokers ( * )
Edit :
Après mûre réflexion, j'ai imaginé cette technique :
Edite ton fichier eggdrop.conf et ajoute ceci juste avant la toute première ligne de chargement de tes scripts (les lignes source scripts/blablabla.tcl) :
et ensuite, modifie chaque ligne de chargement de tes scripts en prenant modèle sur l'exemple suivant :
doit être modifié en
Après avoir fait ça, redémarre ton eggdrop et tu obtiens une magnifique variable globale du nom de $loaded_scripts contenant la liste de tous les scripts chargés.
La variable peut être consultée en tapant .set loaded_scripts depuis la partyline. Elle est pas belle la vie ?
Maintenant, je m'attends à voir débarquer CrazyCat d'une minute à l'autre, la bouche en coeur, et répondre "oulàà arrête la bibine Menza, tu connais pas la commande .ScriptsList ?"
Remarque : les commandes .tcl et .set peuvent être utilisées en partyline après en avoir débloqué l'usage comme indiqué ici : Aidez-nous à vous aider
@frisk :
Je ne suis pas sûr que ce que tu veux soit possible car charger un script ne déclare rien de particulier hormis les élément qu'il contient.
Il est possible de lister les variables utilisées, les procédures, les binds etc... mais pas les scripts, je le crains.
Si tu es organisé et que tu ne laisses que les scripts que tu utilises dans le répertoire scripts, tu peux toujours compter sur la commande :
tcl
.tcl glob scripts/*.tcl
pour t'afficher la liste des .tcl qui se trouvent dans eggdrop/scripts.
Quelques autres commandes éventuellement utiles :
afficher une liste des variables déclarées :
afficher une liste des procédures existantes
afficher le contenu d'une procédure
afficher une liste des variables globales
tcl
.tcl info globals [masque de recherche]
Les masques de recherche supportent les jokers ( * )
Edit :
Après mûre réflexion, j'ai imaginé cette technique :
Edite ton fichier eggdrop.conf et ajoute ceci juste avant la toute première ligne de chargement de tes scripts (les lignes source scripts/blablabla.tcl) :
tcl
et ensuite, modifie chaque ligne de chargement de tes scripts en prenant modèle sur l'exemple suivant :
tcl
source scripts/kikoulol.tcl
doit être modifié en
tcl
source scripts/[register_script kikoulol.tcl]
Après avoir fait ça, redémarre ton eggdrop et tu obtiens une magnifique variable globale du nom de $loaded_scripts contenant la liste de tous les scripts chargés.
La variable peut être consultée en tapant .set loaded_scripts depuis la partyline. Elle est pas belle la vie ?
Maintenant, je m'attends à voir débarquer CrazyCat d'une minute à l'autre, la bouche en coeur, et répondre "oulàà arrête la bibine Menza, tu connais pas la commande .ScriptsList ?"
Remarque : les commandes .tcl et .set peuvent être utilisées en partyline après en avoir débloqué l'usage comme indiqué ici : Aidez-nous à vous aider
Toute l'actualité de mes scripts ici (dernière mise à jour le 22/04/2020)
Tout programme comporte au moins un bug et pourrait être raccourci d'au moins une instruction, de quoi l'on peut déduire que tout programme peut être réduit à une seule instruction qui ne fonctionne pas.
Tout programme comporte au moins un bug et pourrait être raccourci d'au moins une instruction, de quoi l'on peut déduire que tout programme peut être réduit à une seule instruction qui ne fonctionne pas.