Une des choses que j'ai apprises en écrivant et en utilisant ce type de script est qu'ils sont plein de pièges. A chaque fois que vous écrivez quelque chose qui contient des informations lisibles par un humain et que vous essayez de l'analyser, vous allez faire face à des problèmes d'interface. Non seulement parce que les données elles même sont suspectes - bien que ce ne soit pas la question ici, où l'information est juste un bloc notes - mais aussi parce que les interactions de l'utilisateur avec le script créent des cas limites partout. Au résultat, 99% du script consiste à tester les mauvaises entrées de l'utilisateur; la partie réellement fonctionnelle du script représente environ une douzaine de lignes. Le coté le plus amusant de, comment les actions peuvent planter le script, est ce que vous obtenez lorsque vous exécutez le script après ne pas l'avoir utilisé pendant un moment et que vous avez oublié ses astuces: même moi, l'auteur du script, j'ai réussi à le planter à l'occasion! Ces occasions ont toujours été suivies de malédictions mi-amusées, mi-frustrantes - jusqu'à ce qu'il ne reste plus rien à corriger (au moins concernant les problèmes que j'avais rencontrés, trouvés, imaginés ou créés). Comme toujours, j'apprécie tout retour, si quelqu'un découvre un problème que je n'ai pas trouvé!

Sur mon système, le script est simplement nommé n - pour autant que je me souvienne, j'avais pensé à 'note' au moment où je l'ai nommé. Vous pouvez télécharger la dernière version ici, la version sur le serveur LG n'étant pas forcement à jour; ce script n'a pas changé depuis un moment.

Les options d'utilisation de ce script sont d'une grande simplicité, et peuvent être obtenues en invoquant le script suivi de l'argument '-h' ou '--help':

ben@Jotunheim:~$ n -h

  n [-h|--help] | [section] [comment_search_string]
  
  If invoked without any argument, asks for the section and entry text to
  be added to the data file. If an argument is provided, and matches an
  existing section, that entire section is displayed; if two arguments
  are supplied, displays the first entry matching arg[2] in the section
  matching arg[1].

Voici un exemple d'ajout d'une nouvelle entrée:

ben@Jotunheim:~$ n 
Current sections:
awk
date
find
grep
mencoder
misc/miscellany/miscellaneous/general
mount
mp3/ogg/wav
mplayer
netstat
perl
shell/bash/ksh
sort
tcpdump
vi/vim
whois
Please enter the section to update or a new section name: perl 
Please type in the entry to be added to the 'perl' section:
# Interactive Perl debuggerperl -d scriptname
ben@Jotunheim:~$

Notez que chaque entrée requiert un commentaire en première ligne et doit être suivie d'une ligne vide. Le commentaire peut être continué sur les lignes suivantes, et ceci est important: la recherche par défaut (qui peut être modifiée dans le script) se fait seulement dans les commentaires lorsque le script cherche une donnée spécifique dans une section. En d'autres termes, si je veux retrouver l'entrée ci-dessus, je recherche en écrivant n perl debug

Cette commande retournera chaque entrée contenant « debug » dans le commentaire dans la section « perl ». Si vous voulez effectuer une recherche moins précise, c'est à dire une recherche qui cible à la fois le commentaire et le contenu, vous pouvez modifier la variable search_opt située dans le haut du script décrit ci-dessus. Personnellement, je préfère la recherche sur « commentaire seulement » - je tiens compte de ma « Google-fu », c'est à dire, de ma capacité à formuler une bonne requête de recherche. L'astuce est que j'utilise la même chose, le même mode de pensée, quand je crée un commentaire pour une donnée entrée: j'écris un commentaire pratiquement équivalent à une requête de recherche même si je n'ai plus aucun souvenir de ce que j'ai originellement écrit.

Jusqu'ici, c'est simple mais ce n'est pas tout. La partie délicate concerne les caractéristiques éventuellement surprenantes qui sont les conséquences naturelles des outils que j'ai utilisés pour écrire le script. Car, comme j'utilise les capacités regex de sed pour rechercher dans les sections et les lignes, les arguments fournis au script peuvent également être des regex - au moins si nous prenons soin de les protéger des expansions de l'interpréteur en utilisant de simples guillemets de part et d'autre. Avec ceci, le script devient plus utile, puisque vous pouvez maintenant rechercher plus de chaines arbitraires avec plus de liberté. Par exemple, si je me souviens que j'avais une entrée contenant 'tr' dans une section, je peux demander à n de rechercher 'tr' dans les commentaires de toutes les sections:

n '.*' tr

Cependant, si la recherche ci-dessus renvoie trop de réponses (cela se pourrait car 'trailing', 'matrix', 'control' etc. vont tous correspondre), je peux demander à n de chercher 'tr' comme mot - par exemple une chaine entourée de caractères non alphanumériques:

n '.*' '\<tr\>' 

Ceci renverra uniquement ce que je cherche.

Je peux également rechercher des données dans plus d'une section à la fois, au moins si je me souviens comment utiliser le style sed dans les expressions régulières:

n 'perl\|shell' debug

Ceci recherchera toutes les données contenant 'debug' dans les commentaires des deux sections 'perl' et 'shell'.

On peut également faire l'inverse:

n perl 'text\|binary'

ou alors :

n 'awk\|perl' 'check\|test'

L'une des options pratiques, lorsque l'on crée une nouvelle section, est d'utiliser plusieurs noms de section - autrement dit, il pourrait y avoir plus d'un nom de section qui aurait un sens lorsque j'effectuerai une recherche. Par exemple, pour les trucs et astuces sur l'écriture de shell, je peux penser au mot « shell » mais aussi à « bash », « ksh » voire même « sh » en premier. (Notez que ce cas ne pose pas de problème: n l'ignore lorsqu'il effectue une recherche sur les noms de section). Que faire? En fait, c'est assez facile: n autorise plusieurs noms dans une section donnée tant que ce sont des mots séparés, ce qui veut dire séparés par des caractères non alphanumériques excepté le tiret bas (tiret du 8). Ainsi, si vous nommez une section « KSH/sh/Bash/shell/script/scripting », n'importe quel mot, parmi ceux-ci, spécifié comme nom de section, permettront une recherche au bon endroit.

Comme les données sont contenues dans un fichier texte, vous pourrez toujours l'éditer pour corriger une erreur. (Le nom et la position du fichier, ~/.linux_notes, sont définis en haut du script, chaque utilisateur peut avoir le sien ou en partager un). Vérifiez simplement le format, qui est très simple: les noms de section commencent par « ### » en début de ligne, les commentaires commencent par « # » en début de ligne et les données et sections sont séparées par une ligne vide. Si, d'aventures, vous commettez une erreur, ce n'est pas un gros problème, car le fichier est évalué ligne par ligne, chaque entrée est individuelle, et grâce à la conception du script, le processus est assez robuste. (Par exemple, plusieurs lignes vides c'est bon, utiliser plusieurs # au début d'un commentaire c'est bon; oublier de laisser des lignes vides entre les différentes entrées donnera un résultat où les données seront « connectées » entre elles). Même dans le pire des cas, la sortie sera lisible et utilisable, et les réparations à faire seront évidentes et faciles.

Une des choses, que j'aimerais que les lecteurs de LG retiennent de cet article, est de considérer n comme un début de leur futur développement de ce type de script. Il y a beaucoup d'occasions où voudrez utiliser une interface de « recherche et mise à jour », et n est un modèle que j'ai utilisé encore et encore dans ces cas là avec quelques ajustements mineurs. Comme ce script est publié sous la licence GNU, vous êtes libres d'affiner, améliorer et réécrire comme vous le souhaitez. Encore une fois, j'apprécierai d'être informé des améliorations intéressantes!