ZenTech - code

Qui est le plus fort entre l'éléphant et l'hippopotame

hr — Wed, 02 Apr 2008 15:31:00 +0200

Je me pose toujours des questions de performance lorsque je développe. Il y a souvent plusieurs façons de rêgler un problème et certaines plus consommatrices de ressources que d'autres. Dans le cas qui m'intéresse, je me questionne sur la performance des expressions régulières en regard d'autres méthodes de traitement de chaîne. Je dois effectuer un traitement sur un très grand nombre de lignes de log au fur et à mesure de leur émission en syslog.

La plupart du temps avec python, avoir une idée innovante est modérée par l'existence d'un module qui couvre déjà le sujet. Dans ce cas, le module timeit va me permettre de tester la rapidité d'exécution de différents bouts de code.

Le format d'une ligne de log syslog est connu et décrit par la RFC3164, ce format me permet différentes approches pour en extraire différents champs. Dans mon cas, je vais extraire le champ appelé HEADER de différentes façons. Un ligne de log syslog doit être de la forme :

<     >TIMESTAMP HOSTNAME TAG CONTENT
| PRI |      HEADER      |    MSG

Dans le code python ci-dessous, les trois fonctions testées sont :

split() qui récupère le champ header en effectuant un split sur le caractère espace et en réunissant les champs résultants.
match() effectue une sélection par expression régulière.
match_full() effectue une capture par expression régulière et occurence nommée.

Il est important de bien faire attention au contexte et à la portée des variables et fonctions ("scope" et "namespace") lorsqu'on utilise timeit.

import timeit

def split():
    str = '<22>Mar 27 16:13:35 192.168.1.1 mx-daemon[2754]: m2RFDTbw002754: from=<j.doe@nowhere.com>, size=3356, class=0, nrcpts=1, msgid=<000701c8902d$04cb7356$879fa6b4@epwlhnj>, proto=ESMTP, daemon=MX, relay=[192.168.1.2]'
    ' '.join(str.split()[0:4]).split('>')[1]

def match():
    import re
    pattern = r'^<(\d+)>(\w{3} (?: |\d)\d \d\d:\d\d:\d\d [\w:.]+) (\w+.+)'
    _pattern = re.compile(pattern)
    str = '<22>Mar 27 16:13:35 192.168.1.1 mx-daemon[2754]: m2RFDTbw002754: from=<j.doe@nowhere.com>, size=3356, class=0, nrcpts=1, msgid=<000701c8902d$04cb7356$879fa6b4@epwlhnj>, proto=ESMTP, daemon=MX, relay=[192.168.1.2]'
    _pattern.search(str).group(2)

def match_full():
    import re
    pattern_full = r'^<(?P<pri>\d+)>(?P<header>\w{3} (?: |\d)\d \d\d:\d\d:\d\d [\w:.]+) (?P<msg>\w+.+)'
    _pattern_full = re.compile(pattern_full)
    str = '<22>Mar 27 16:13:35 192.168.1.1 mx-daemon[2754]: m2RFDTbw002754: from=<j.doe@nowhere.com>, size=3356, class=0, nrcpts=1, msgid=<000701c8902d$04cb7356$879fa6b4@epwlhnj>, proto=ESMTP, daemon=MX, relay=[192.168.1.2]'
    _pattern_full.search(str).groupdict()['header']

print "split:"
print timeit.Timer("split()", "from __main__ import split").timeit()
print "match:"
print timeit.Timer("match()", "from __main__ import match").timeit()
print "match_full:"
print timeit.Timer("match_full()", "from __main__ import match_full").timeit()

Ce qui donne après exécution :

$ python stress.py
split:
6.14724898338
match:
14.80702281
match_full:
19.0696430206

En y réfléchissant bien, les fonctions testées ne sont pas vraiment optimisées et ne sont pas donc comparables en vitesse d'exécution. Pour vraiment jouer sur un pied d'égalité, je procède aux modifications suivantes :

Import du module re en début de script, ça fonctionne finalement, j'avais peur que les problèmes de contexte de timeit ne posent problème.
La compilation des expressions régulières est faite une fois pour toute et pas à chaque lancement des fonctions cmatch() et cmatch_full()
Introduction de deux nouvelles fonctions effectuant une capture par expression régulière sans compilation de l'expression.
Utilisation de la méthode repeat() plutôt que timeit() pour essayer d'obtenir un résultat moins influencé par le fonctionnement du système.

import re, timeit

str='<22>Mar 27 16:13:35 192.168.1.1 mx-daemon[2754]: m2RFDTbw002754: from=<j.doe@nowhere.com>, size=3356, class=0, nrcpts=1, msgid=<000701c8902d$04cb7356$879fa6b4@epwlhnj>, proto=ESMTP, daemon=MX, relay=[192.168.1.2]'

split_init = """from __main__ import split"""
match_init = """from __main__ import match"""
match_full_init = """from __main__ import match_full"""
cmatch_init = """from __main__ import cmatch"""
cmatch_full_init = """from __main__ import cmatch_full"""

pattern = r'^<(\d+)>(\w{3} (?: |\d)\d \d\d:\d\d:\d\d [\w:.]+) (\w+.+)'
pattern_full = r'^<(?P<pri>\d+)>(?P<header>\w{3} (?: |\d)\d \d\d:\d\d:\d\d [\w:.]+) (?P<msg>\w+.+)'
_pattern = re.compile(pattern)
_pattern_full = re.compile(pattern_full)

def split():
    ' '.join(str.split(' ')[0:4]).split('>')[1]

def match():
    re.search(pattern, str).group(2)

def match_full():
    re.search(pattern_full, str).groupdict()['header']

def cmatch():
    _pattern.search(str).group(2)

def cmatch_full():
    _pattern_full.search(str).groupdict()['header']

print "Testing %d occurences of each match, %d times" % (timeit.default_number, timeit.default_repeat)
split_result = timeit.Timer("split()", split_init).repeat()
print "split: %fs %s" % (min(split_result), split_result)
match_result = timeit.Timer("match()", match_init).repeat()
print "match: %fs %s" % (min(match_result), match_result)
match_full_result = timeit.Timer("match_full()", match_full_init).repeat()
print "match_full: %fs %s" % (min(match_full_result), match_full_result)
cmatch_result = timeit.Timer("cmatch()", cmatch_init).repeat()
print "cmatch: %fs %s" % (min(cmatch_result), cmatch_result)
cmatch_full_result = timeit.Timer("cmatch_full()", cmatch_full_init).repeat()
print "cmatch_full: %fs %s" % (min(cmatch_full_result), cmatch_full_result)

Qui me donne les résultats suivants :

$ python stress.py
Testing 1000000 occurences of each match, 3 times
split: 5.818318s [5.8183181285858154, 6.5981872081756592, 6.327794075012207]
match: 8.220056s [8.2262570858001709, 8.2361149787902832, 8.2200560569763184]
match_full: 12.399510s [12.40582799911499, 12.399509906768799, 12.501888036727905]
cmatch: 3.818037s [3.8180370330810547, 3.8276369571685791, 3.8310809135437012]
cmatch_full: 6.724747s [6.7247469425201416, 6.7392361164093018, 6.7564170360565186]

Il est surprenant de constater la différence énorme entre les expressions régulières compilées et non compilées, l'avantage de compiler ses expressions dans le cas d'une utilisation de masse est évident. La rapidité de split() est plutôt décevante par rapport à l'utilisation des expressions régullières.

Ces tests sont intéressant et donnent des indications de performance mais ne remplacent pas des tests complet de profilage.

C'est curieux chez les marins ce besoin de faire des phrases

hr — Tue, 18 Mar 2008 15:47:00 +0100

Suite à une remarque judicieuse j'ai été obligé de gérer un petit cas particulier qui conduisait à un conflit. Le script sed est maintenant modifié, ce n'est pas extrêmement propre mais c'est assez efficace. Le bout du script concerné est :

# remove /* */ comments, multiline or not
/\/\*/{
    # special case of /*/ starting comments that fools the next test
    s:/\*/:/\* /:
    :mline
    /\*\// {
        s:/\*.*\*/::
        b mlineend
    }
    N
    b mline
}
:mlineend

Pour en finir avec Lulu la Nantaise

hr — Mon, 17 Mar 2008 12:32:00 +0100

Au final, je me suis occupé des espaces, le but de ce script étant au départ de fournir un code nettoyé qui pourra passer au banc des statistiques. Le script sed est disponible et placé sous license type *BSD. Quelques corrections d'erreur et de nouvelles fonctions constituent cette dernière version du script.

J'utilise un petit fichier de définition test.h :

/*
 * Big story here
 * my life
 */
// one line
#define HEHE 1

/* includes */
#include "blah"
#include "foo" // end line comment

#include /* weird comment */ "pouet"
int woop /* to see */
/* let's continue with weird comments */ void sigpipe_handle(int);

/*-------------
  bloh
---------------*/
int main(int argc, char **argv);
int parseCommandLine(int argc, char* argv[]);

Ce qui donne, une fois passé par sed :

$ sed -nf ccmtstrip.sed test.h
#define HEHE 1
#include "blah"
#include "foo"
#include "pouet"
int woop
void sigpipe_handle(int);
int main(int argc, char **argv);
int parseCommandLine(int argc, char* argv[]);

Les commentaires déssoudés par Jo le trembleur

hr — Sat, 15 Mar 2008 21:21:00 +0100

La version précédente du script sed ne me convenait pas. Elle ne gérait pas certaines formes de commentaires horribles, qui mériterait une sentence extrême et douloureuse. C'est maintenant chose rêglée avec une version améliorée.

#!/usr/bin/sed -nf

# remove single line comments
/^\/\//d

# remove /* */ comments, multiline or not
/\/\*/{
    :mline
    /\*\// {
        s:/\*.*\*/::
        b mlineend
    }
    N
    b mline
}
:mlineend

# remove empty lines
/^$/d

p

Il peut arriver que certains espaces inutiles apparaissent dans le code suite à la suppression des commentaires multiligne mais ce n'est pas fondamentalement un problème.

Du C par Teddy de Montreal

hr — Fri, 14 Mar 2008 17:25:00 +0100

" ... un fondu qui travaillait qu'à la dynamite." Je me suis mis en tête de compter le nombre de lignes efficaces d'un développement en C. Par ligne efficace j'entends le nombre de lignes de code vraiment compilées. Je dois donc éliminer les commentaires sous leurs diverses formes et les lignes blanches. Et comme j'aime bien me faire mal, au lieu de faire ça en 10 minutes en Perl ou Python, je l'ai fait grâce à sed(1).

Ce script sed doit donc gérer les lignes blanches, les commentaires sur une ligne commençant pas '//', les commentaires sur plusieurs lignes (ou pas) du type /* comment */. Ca donne alors le script suivant :

#!/bin/sed -nf

# remove empty lines
/^$/d
# remove single line comments
/^\/\//d

# remove /* */ comments, multiline or not 
/\/\*/{
    :mline
    /\*\//b mlineend
    N
    b mline
    :mlineend
    d
}
p

Le seul passage qui me semble nécessiter une explication est celui qui gère les commentaires sur plusieurs lignes. Ce qui est fait là est assez simple (sisi c'est vrai) : on ne traite que les lignes comprenant '/*', si la ligne comprend aussi '*/' on passe à la balise mlineend, sinon on ajoute la ligne suivante aux lignes déjà lues et on passe à la balise mline (boucle). Le saut à la balise mlineend provoque la destruction des lignes lues et le passage à la ligne suivante en recommençant le script.
On finit par afficher la ligne (grâce à 'p') si aucun des cas précédents ne s'est produit.

Le défaut de ce script est de ne pas gérer les cas où les commentaires sont mixés avec du code. Je pense l'améliorer dans un deuxième temps pour prendre en compte ces cas.

Mise à jour: une nouvelle version de ce script règle ces soucis.

Booooooonjouuuuuuuuuuuur jeee m'aaaappeeeeeeeeeeeeelle Dooooooooriiiiiiiiiiiis

hr — Thu, 13 Mar 2008 15:54:00 +0100

Suite à la configuration de net-snmp pour utiliser des scripts, il a bien fallu coder un compteur 32bits. Aimant les défis, je me suis décidé à écrire un compteur 32 bits en bash qui compte les entrées d'une base de donnée.

Comment doit fonctionner un compteur 32 bits en script :

Le compteur est un entier modulo 2^32
Le compteur augmente uniquement de la différence de valeur entre deux requêtes
Le compteur doit être conservé entre deux requêtes

Pour implémenter le modulo, ce n'est pas très compliqué en bash/sh :

$(($count % 2**32))

J'ai choisi de stocker les données dans un tableau bash. Pour conserver les données entre 2 appels, je stocke directement le tableau dans un fichier sous la forme d'une définition de tableau bash. De cette façon, je peux inclure le fichier au début de mon script et j'évite d'avoir à lire un fichier de donnée. Les données que je conserve sont le résultat de ma dernière requête SQL, la différence entre la dernière requête et la précédente, et finalement mon compteur. Pourquoi conserver le dernier résultat ? Ca me permet au passage de choisir le comportement du compteur entre compteur 32 bits et donnée directe (gauge).
La requête SQL est tout simplement un count(*) sur une table, le nombre de lignes de cette table peut augmenter ou diminuer (si il ne faisait qu'augmenter, je pourrais directement prendre le count(*) modulo 2^32).

#!/bin/sh

counters='pgcount.txt'
# call the counters
if [ -f $counters ]; then
    . $counters
else
    # last count / last diff / counter
    count=(0 0 0)
fi

# adds 2 values
# return the sum modulo 2**32
counter() {
    counter=$(($1 + $2))
    echo -n $(($counter % 2**32))
}

# dumps the values as bash arrays
dump() {
    echo "count=(${count[@]})" > $counters
}

getdata() {
    count=($@)
    rows=$(getcount $table)
    if [ "${count[1]}" -ne "$count" ]; then
        count[1]=$(($rows - ${count[0]}))
        count[0]=$rows
        count[2]=$(counter ${count[2]} ${count[1]})
    fi
    # return needed values
    echo ${count[@]}
}

count=($(getdata ${count[@]}))
dump()

La fonction getcount() effectue le count(*) et retourne le nombre de lignes lues.

Ce script est lancé toutes les minutes car la requêtes peut parfois prendre du temps et provoquer un timeout snmp. Mon serveur net-snmp appelle donc un bête script qui inclut le fichier de sauvegarde et renvoit les données sauvées.

#!/bin/sh

counters='pgcount.txt'
# call the counters
if [ -f $counters ]; then
    . $counters
else
    # last count / last diff / counter
    count=(0 0 0)
fi

echo ${count[1]}
echo ${count[2]}

En sélectionnant la donnée que je veux dans mon chemin snmp je peux obtenir le nombre de lignes insérées sous forme de compteur 32 bits ou le nombre de lignes insérées entre deux exécutions du scipt. Cette dernière valeur est bancale puisqu'elle ne représente pas le nombre de lignes insérées entre deux consultations du compteur. Il serait possible de le faire fonctionner correctement si le script de lecture réécrivait le fichier de sauvegarde à chaque lecture pour signifier qu'il a été consulté. Il faudrait alors implémenter un verrou sur ce fichier pour éviter qu'il soit utilisé par les 2 scripts en même temps.

NB: Désolé pour le titre du post, je ne trouvais rien de plus inspiré mais un compteur 32bits c'est un peu comme Doris, au bout d'un certain temps, il revient à zero. Oui, je sais ...

HAL> Affirmative, Dave, I read you.

hr — Fri, 11 Jan 2008 17:39:00 +0100

Ah la vacuité d'une session IRC sur un canal dirigé par un automate. Quoi de plus extraordinaire que pouvoir connaitre la météo de Felletin dans la Creuse ou d'avoir une blague carambar à la demande. En ce moment je fais beaucoup de python, donc je me suis penché sur le problème pour un ami. Je vais essayer de vous exposer les clés de l'utilisation d'irclib pour construire un automate irc simple.

L'automate est présenté ci-après, ses fonctions sont simplement la connexion à un serveur irc local sur le port 6667 et l'entrée dans le canal #test. L'automate s'attend à lire des commandes préfixées de '!' dans le canal. La commande !cycle demande à l'automate de partir et revenir sur le canal, la commande !die provoque la déconnexion du serveur puis l'arrêt de l'automate. Le script de l'automate ci-après se trouve en téléchargement ici et peut être lancé par la commande python mybot.py.

import sys
try:
    from ircbot import SingleServerIRCBot
    import irclib
except ImportError, e:
    print e
    sys.exit(1)

class pybot(SingleServerIRCBot):
    def __init__(self, server, nick, realname, chan):
        SingleServerIRCBot.__init__(self, server, nick, realname)
        self.chan = chan
        self.nick = nick

    ## Event callbacks
    def on_welcome(self, c, e):
        if self.chan:
            c.join(self.chan)

    def on_join(self, c, e):
        who = e.source().split('!', 1)
        if who[0] == self.nick:
            c.privmsg(e.target(), 'Hello world!')

    def on_pubmsg(self, c, e):
        msg = e.arguments()[0].strip()
        if msg.startswith('!'):
            cmd = msg[1:].split(' ', 1)[0]
            self.trigger(c, e, cmd)

    ## Command triggers
    def trigger(self, c, e, cmd):
        try:
            getattr(self, 'cmd_%s' % cmd)(c, e)
        except AttributeError:
            pass

    def cmd_cycle(self, c, e):
        chan = e.target()
        c.part(chan, 'cycle')
        c.join(chan)

    def cmd_die(self, c, e):
        SingleServerIRCBot.die(self, 'Argh')

## Here comes the real script
if __name__ == '__main__':
    server = [('localhost', 6667)]
    nick = 'monbot'
    realname = 'monbot'
    channel = '#test'

    bot = pybot(server, nick, realname, channel)
    try:
        bot.start()
    except KeyboardInterrupt:
        bot.connection.disconnect("Ctrl-C m'a tuer")
        bot.connection.close()

La librairie irclib est basée sur la gestion d'évènements, des méthodes vont être lancées sur apparition d'un évènement au sens IRC. Les méthodes de l'objet pybot commençant par 'on_' sont les méthodes de gestion d'évènements, par exemple lorsqu'un message est envoyé sur un canal (PUBMSG) la méthode on_pubsmg() est appelée. La création de l'automate se base sur la surcharge des méthodes de gestion d'évènements. Ces méthodes ont toutes la même définition d'appel :

def on_foo(self, c, e):
    [...]

La variable c est un objet ServerConnection, cet objet permet de manipuler tout ce qui concerne le serveur irc d'où provient l'évènement. On peut par exemple rejoindre un canal (c.join()) ou envoyer un message à un canal ou une personne (commande PRIVMSG via c.privmsg()). La variable e est un objet Event, elle permet d'obtenir toutes les informations sur l'évènement qui a provoqué l'appel de la méthode. L'origine de l'évènement (e.source()), la destination de cet évènement (e.target()) ou encore les arguments de cet évènement (e.arguments()). Toutes les informations sur ces 2 méthodes se trouvent dans le module irclib (pydoc irclib).

A partir de la connaissance de ces éléments de base, la construction d'un automate devient assez simple. Si l'automate doit effectuer des tâches régulières, les méthodes execute_at() et execute_delayed() (héritage de l'objet IRC parent de SingleServerIRCBot) peuvent être utilisées. Plus d'information sur irclib devrait se trouver sur mon wiki.

Il est également possible d'utiliser twisted.words pour effectuer la même chose mais ça me semble une librairie un peu imposante pour un simple automate.

Il faut noter qu'on peut faire également le même genre de chose en Perl.

WOPR> Global Thermonuclear War

hr — Thu, 03 Jan 2008 18:33:00 +0100

Dans mon parcours d'initiation à python, je me suis retrouvé face à un problème existentiel (ce qui donne tout le caractère initiatique au parcours, le problème, parce qu'il est existentiel ... laisse tomber). Lors de l'utilisation du module cmd, comment gérer correctement les interruptions classiques que sont ctrl+D (EOF) et ctrl-C (SIGINT).

Ci-après, un squelette pour la gestion des 2 signaux évoqués. Juste après ci-après, les quelques explications qui s'imposent.

import sys
import cmd

class shell(cmd.Cmd):
    def __init__(self):
        cmd.Cmd.__init__(self)

    # Let's handle ctrl+D signals and quit gently
    def do_EOF(self, str):
        # CLEAN HERE
        return 1

if __name__ == "__main__":
    console = shell()
    try:
        console.cmdloop()
    except KeyboardInterrupt:
        # CLEAN HERE
        sys.exit(0)

`ctrl-D` ou la fin du monde

Le manuel de cmd nous dit :

An end-of-file on input is passed back as the string 'EOF'.

Ce qui signifie que la combinaison de touches ctrl+D revient à gérer la commande EOF, la méthode appelée est donc do_EOF().
Une autre information à propos de cmdloop() donnée dans le manuel est :

This method will return when the postcmd() method returns a true value. The stop argument to postcmd() is the return value from the command's corresponding do_*() method.

Donc si la méthode do_EOF() retourne simplement 1, la boucle va tout bêtement s'arrêter.

`ctrl-C` ou la fin de l'univers

En Python, l'utilisation de ctrl-C lève l'exception KeyboardInterrupt, en capturant cette interruption, on permet au script de sortir de façon maitrisée.

Evolution

Il est conseillé d'ajouter des actions de nettoyage au niveau des commentaires # CLEAN HERE pour permettre une sortie de la console vraiment sans encombre. Il reste encore à trouver un moyen élégant d'utiliser ctrl-c pour annuler la ligne en cours et récupérer l'invite vierge sans quitter cmd.cmdloop()
Attention toutefois, ce code n'a pas été testé dans un environnement microsoft. Les signaux ne sont surement pas traités de la même façon, ça n'étonnera personne.

A chacun sa petite fiche de présence

hr — Sun, 11 Nov 2007 12:52:00 +0100

J'aime bien avoir des logs d'accès séparés par vhost sur mes serveurs, ça permet de simplifier la recherche d'erreur et la construction de statistiques. Comme je gère mes vhosts par un script, j'ai pensé que rajouter la création automatique de logs d'accès serait un plus. C'est toujours ça qui ne sera pas oublié lors de l'ajout d'un nouveau vhost.
Au passage, j'ai rajouté le document-root automatique, les données d'un site virtuel doivent se trouver dans un répertoire du nom de son fichier de configuration.

# ./include_vhost -h
Usage: include_dir [-hptx] [-d docroot_path] [-l log_path] <dir>
    -h      displays this help
    -d      Automatic document-root specification
    -l      Add vhost access logs in log_path
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)

Si les logs doivent se trouver dans /var/log/lighttpd, que les sites se trouvent dans /usr/local/www/data et que les fichiers de configurations de vhost sont dans /usr/local/etc/lighttpd/vhost.d, on obtient l'appel suivant au script :

./include_vhost -l /var/log/lighttpd -d /usr/local/www/data /usr/local/etc/lighttpd/vhost.d

Au passage, le script change de nom étant donné qu'il se spécialise vraiment dans la gestion de fichiers de configuration d'hôte virtuel.

Pour information, je n'ai pas rajouté les logs d'erreur dans cet automate, pour la simple et bonne raison que la documentation de configuration déconseille de placer plusieurs appels à server.errorlog dans la configuration de lighty.

Je veux bien prendre mais pas de là

hr — Sat, 21 Jul 2007 22:14:00 +0200

C'est toujours autant amusant de jouer avec lighttpd, mais parfois on se trompe dans un fichier de configuration et là, c'est le drame. Mon script include_dir ne permet pas de savoir quel fichier de configuration est brokmut lors de l'utilisation de lighttpd -p -f lighttpd.conf. C'est maintenant chose faite, avec la nouvelle version toujours téléchargeable au même endroit. Au passage, il est passé en license beerware

# ./include_dir -h
Usage: include_dir [-hptx] <dir>
    -h      displays this help
    -p      print the parsed config files and exit (default behaviour)
    -t      test the config files
    -x      specify a lighttpd binary (default /usr/local/sbin/lighttpd)
# ./include_dir -t vhost.d/
>>> Testing vhost.d/www.vhost1.org
Syntax OK
>>> Testing vhost.d/www.vhost2.org
2007-07-21 22:28:47: (configfile.c.833) source: vhost.d/www.vhost2.org line: 3 pos: 21 parser failed somehow near here: (EOL) 
>>> Testing vhost.d/www.vhost3.org
Syntax OK

httpd.zero = enable

hr — Fri, 30 Mar 2007 18:55:00 +0200

Toujours à m'amuser avec asparttpd et je me dis que ce serait sympa de pouvoir utiliser le mécanisme auquel je me suis habitué pour les vhosts. Un dossier vhost.d et un fichier de conf par vhost dans ce répertoire.

Rien de plus facile en fait, grâce à include_shell je lance un script de ma composition, ce script est un bête bout de sh qui inclut tous les fichiers du répertoire donné en argument au script. Ca donne ce genre de chose :

#### vhosts
include_shell "./include_dir vhost.d"

et le script :

#!/bin/sh

# I prefer doing nothing if no dir is given on command line
# that way I do not break anything
if [ "$#" = "0" ]; then
        exit 0
fi

# exclude vim temporary files
# configuration file has to have the vhost domain name
for site in $(ls $1 | grep -v .swp); do
        echo "\$HTTP[\"host\"] == \"$site\" {"
        cat $1/$site
        echo "}"
        echo
done

l'utilisation d'un petit lighttpd -p -f lighttpd.conf permet de s'assurer que tout fonctionne correctement, on remarque également que de cholis commentaires sont ajoutés pour faciliter la lecture. Le script include_dir est présent dans le même répertoire que le fichier de configuration de lighttpd (je sais, c'est sale).