Avertissement nouveau mail dans prompt bash

Programmation
#21

J’ai pas complètement tout lu mais pourquoi ne pas utiliser un simple fichier ? Pour limiter les accès disque ? Le noyau va rapidement repérer que tu y accède et le garder en cache.

Même si sur le principe j’apprends des choses intéressantes sur l’utilisation de fifo et de pipe dans un shell il me semble que c’est un peu énorme pour simplement avoir le nombre de mail.

#22

[quote=“MisterFreez”]J’ai pas complètement tout lu mais pourquoi ne pas utiliser un simple fichier ? Pour limiter les accès disque ? Le noyau va rapidement repérer que tu y accède et le garder en cache.

Même si sur le principe j’apprends des choses intéressantes sur l’utilisation de fifo et de pipe dans un shell il me semble que c’est un peu énorme pour simplement avoir le nombre de mail.[/quote]

Oui, je suis d’accord avec toi. L’utilisation d’un fichier serait plus approprié et moins galère à mettre en oeuvre.

Surtout qu’avec les pipes, il faudra gérer un système de synchronisation entre le démon qui sera charger de récupérer les infos dans les mailbox et les clients (i.e au moment de l’affichage du prompt). Et puis sans compter que le serveur peut se bloquer en cas de problème réseau empêchant la récupération des mails (un timeout devrait suffir mais bon, un prompt qui ne s’affiche pas immédiatement n’est pas l’idéal).

C’est pourquoi je pense que le script que j’ai fourni pourrait bien faire l’affaire si on l’utilise en tant que démon. On peut imaginer le lancer via le .bashrc et chaque lancement vérifie si il est déjà lancé (via les processus ou un fichier flag dans le dossier utilisateur). Ensuite, il suffirait de le modifier pour qu’il écrive dans un fichier plutôt que d’afficher le résultat à l’écran. Ainsi, lors de l’affichage du prompt, il suffirait de le consulter et d’alimenter le prompt. (C’est en gros le principe du lien fourni en premier lieu par branch mais avec un affichage du nom de la mailbox et du nombre de mail non lus)

#23

Hum, du boulot qui arrive, je dois laisser ça en suspend :confused:

Sinon, oui, le plus simple c’est évidemment d’utiliser un fichier du disque dur (mais ça m’amuse toujours de gagner trois millièmes de secondes au temps d’exécution, au prix d’une semaine travail supplémentaire …).

Ce qu’il faut que je retienne, c’est le protocole d’utilisation du fifo :

  • lorsqu’on prend la valeur du fifo pour l’afficher dans le prompt, il faut immédiatement la remettre dans le fifo.
  • lorsque le démon veut actualiser le contenu du fifo, il doit obligatoirement attendre de pouvoir lire la valeur actuelle (s’il doit attendre, ça veut dire qu’un shell est en train de lire le fifo).
  • lorsqu’il n’y a pas de nouveaux mails, le fifo doit contenir " \b", sans les guillemets.

Je pense que le démon devrait utiliser fetchmail, car il y a une option -c qui se contente de vérifier s’il y a de nouveaux mails, sans les télécharger. Par contre apparament le mot de passe est diffusé en clair, faut trouver un moyen de sécuriser ça.

Sécurisation : protocole APOP.
Instruction let du shell.
On peut écrire et lire directement dans la RAM à l’aide du fichier /dev/shm.

#24

fetchmail sait faire du TLS mais effectivement, le pwd est en claire dans le fichier de conf de l’utilisateur. Il faut dc lui mettre les bons droits.

Je vais faire ma version et j’attendrais la tienne avant de la poster.