man - Page 1

J'en parle depuis quelques semaines avec PpHd, il a mis ça sur le tapis ya deux jours alors que je venais de créer la structure du projet dans l'arborescence de mon disque.

Comme son nom l'indique, il s'agirait donc d'un programme fait pour lire on-calc la documentation d'autres programmes.
L'idée m'est venue depuis que j'ai commencé à faire des programmes en ligne de commande pour PedroM : dur de connaitre les arguments par coeur pour chacun des programmes utilisés. Qui plus est, afficher 5 pages sur stdout est bien, mais le shell de PedroM étant ce qu'il est, il n'est pas forcément aisé d'avoir quelque chose de très lisible, même avec more.

J'ai donc pensé à ça : chaque programme pourra embarquer dans son pack un fichier man, affichable par le programme du-dit nom. Reste à savoir de quel type est ce fichier, et quelles sont ses spécifications.
Quand on tape ensuite "man truc", man cherche "truc" dans la VAT, vérifie que c'est un pack, cherche dedans un fichier "man", et l'affiche comme il faut : l'idée peut être de mettre les noms de section en font 1, et le texte en font 0.

Mon idée : une lib dynamique, en raison de la facilité d'accès qu'on y a. Un export par section de man, pour le nom, le synopsis, la description, les options, les fichiers de conf etc... Un export par section, avec la première phrase considérée comme le titre de la section, et donc mise en relief.
L'avantage d'une lib est qu'en une ligne en plus dans le script de build, elle est dans le pack, et facilement accessible grâce aux fonctions du kernel. Qui plus est, ça permet de définir des touches de raccourci genre 0-9, allant directement d'une section à l'autre.

L'idée de PpHd, dans la mesure où il ne se fait pas trop l'avocat du diable () : un simple fichier texte dans le pack.
Ses contre-arguments à mon idée, c'est qu'il y a déjà un éditeur de texte (side), et des lecteurs de textes formatés (txtrider et autre consorts). Mais, à ma connaissance du moins, aucun de ces programmes n'est capable d'extraire un fichier dans un pack.

Qui plus est, un soft dédié à la vision de texte dépasse en facilité d'utilisation et en features de navigation un soft fait pour l'édition. Qui plus est encore, les softs à la textrider pèsent bien lourd pour la tâche à accomplir, alors qu'un viewer dédié peut être très léger.

A noter que je pense que l'utilisation d'un texte peut être pas mal, avec comme seul formattage une simple balise pour mettre en relief les noms de sections. Mais je préfère malgré tout l'emploi d'une lib, plus simple à compiler, et au format plus propre.

L'avantage d'utiliser un pack pour programme + doc est qu'on ne fournit qu'un seul fichier.


Voilà, j'attends vos idées au niveau de l'implémentation du soft et du format des fichiers à lire.

Sympa comme idée \o/

Sinon, je ne suis pas sûr que faire un nouveau format soit une bonne idée... Que reproches-tu au format txtrider ? sachant qu'on peut faire plus léger que txtrider si on élimine certaines balises

Flanker (./2) :
Que reproches-tu au format txtrider ?

Au format en lui-même, rien, il est puissant, mais dédié à un autre usage : équations, formes vectorisées et complexes, italique, soulignement, insertion d'image etc...

Pas envie de taper la gestion de tout ça, alors que d'après ce que je vois, mon man ordinaire ne se contente que de mettre les noms de section en gras.

L'idée d'avoir une lib dont la première phrase de chaque section est un titre sert à éviter la création d'un nouveau formatage justement : aucune balise ! Et c'est plus simples de créer un tel fichier que de se taper l'écriture d'un fichier formaté, beaucoup plus simple, et c'est là un gros avantage à mon sens. On reste sur un texte brut, avec juste des exports (man@00xx) où l'on veut.

bah on peut gérer un sous ensemble

Folco (./3) :

Flanker (./2) :
Que reproches-tu au format txtrider ?

Au format en lui-même, rien, il est puissant, mais dédié à un autre usage : équations, formes vectorisées et complexes, italique, soulignement, insertion d'image etc...

D'où l'intérêt de ne gérer que certaines balises

Pas envie de taper la gestion de tout ça, alors que d'après ce que je vois, mon man ordinaire ne se contente que de mettre les noms de section en gras.

Mais les liens hypertexte peuvent être intéressants, en revanche.

L'idée d'avoir une lib dont la première phrase de chaque section est un titre sert à éviter la création d'un nouveau formatage justement : aucune balise ! Et c'est plus simples de créer un tel fichier que de se taper l'écriture d'un fichier formaté, beaucoup plus simple, et c'est là un gros avantage à mon sens. On reste sur un texte brut, avec juste des exports (man@00xx) où l'on veut.

Sinon, pourquoi le mettre dans un pack et non directement dans la lib (ou je n'ai pas tout suivi) ?

Et pourquoi ne pas utiliser le format d'eBook utilisé par la TICT?

Flanker -> Ouep, pas tout suivi, ou alors c'est moi qui te suis plus, mais j'ai dû mal m'exprimer aussi.

L'idée est de fournir le programme que tu distribues soit sous forme de pack archive, dont un des fichiers est une lib ne contenant que des dc.b "truc machin chouette", ie le texte de la page de man.

L'idée est aussi que grâce aux exports, on se passe complètement du formatage (parce que ça fait chier de formater un texte ).

Godzil -> Je connais pas ce format, je vais regarder. Mais encore une fois, pourquoi vouloir absolument créer un nouveau format ?

Folco (./7) :
Flanker -> Ouep, pas tout suivi, ou alors c'est moi qui te suis plus, mais j'ai dû mal m'exprimer aussi.

L'idée est de fournir le programme que tu distribues soit sous forme de pack archive, dont un des fichiers est une lib ne contenant que des dc.b "truc machin chouette", ie le texte de la page de man.

L'idée est aussi que grâce aux exports, on se passe complètement du formatage (parce que ça fait chier de formater un texte ).

Ok, j'avais bien compris... mais pourquoi ne pas intégrer les dc.b "truc machin chouette" directement dans la lib elle-même, au lieu de faire une lib séparée ?

Ce n'est pas un nouveau format, vu qu'il existe et qu'il y a deja un reader.

ttarchive / ttunpack est une solution possible, mais fonctionnellement très similaire aux pack archives, non ?
ttunpack est, de nos jours, nettement plus rapide que la routine de décompression des pack archives, mais il me semble que PedroM embarque une version plus ancienne, plus générique mais plus grosse et beaucoup moins rapide, de ttunpack.

ebook ne propose pas de formattage.

Je penserais également plutôt à pousser le man dans l'exécutable (programme ou lib).
Pour un programme natif AMS, j'aurais suggéré l'utilisation du standard de commentaires pour programmes natifs AMS... mais là, ce ne sont pas du tout des programmes natifs AMS

Godzil (./9) :
Ce n'est pas un nouveau format, vu qu'il existe et qu'il y a deja un reader.

qui pèse combien ? Qui est adapté ?

Lionel Debroux (./10) :
ttarchive / ttunpack est une solution possible, mais fonctionnellement très similaire aux pack archives, non ?

ouep, j'attendrai que PpHd ait mergé tous les ramcalls que tu vas lui soumettre pour avoir la même facilité d'utilisation qu'avec les PA.

Plus sérieusement, j'ai déjà regardé en détail ce format d'archive, mais ça me semble pas le concept à utiliser quand on design un soft pour PedroM, évidemment en kernel. Après, rien ne t'empêche de me convertir hein.

Lionel Debroux (./10) :
ttunpack est, de nos jours, nettement plus rapide que la routine de décompression des pack archives, mais il me semble que PedroM embarque une version plus ancienne, plus générique mais plus grosse et beaucoup moins rapide, de ttunpack.

Je te crois, mais les fichiers d'un PA ne sont pas forcément compressés (), qui plus est stdlib est builtin et en flash dans mon PedroM, donc je me fous pas mal de la place que ça prend. Puis la décompression d'un fichier de man devrait pas être catastrophique toute façon, c'est pas non plus le petit robert que tu vas écrire.

Lionel Debroux (./10) :
pousser le man dans la lib.

Quelle lib ? Je vous comprend pas les gars.

L'ebook reader fait dans les 6 KB.

ouep, j'attendrai que PpHd ait mergé tous les ramcalls que tu vas lui soumettre

Hmm ?

(cross)

ils veulent dire intégrer les dc.b dans le programme packarchivé lui même au lieu séparer dans un fichier dédié.

je serais aussi pour séparer le man du programme, pour éventuellement faire une distrib du programme sans doc, pour les ceusses qui veulent économiser la place.

squalyl (./13) :
je serais aussi pour séparer le man du programme, pour éventuellement faire une distrib du programme sans doc, pour les ceusses qui veulent économiser la place.

Ca me fait dévoiler mon projet suivant, un explorateur/manipulateur de pack, comme les front-end de WinZip ou 7Zip (ou Konqueror ). Mais c'est tout à fait l'idée en effet.


L'emmerdement de mettre l'aide adns le programme packarchivé, c'est de retrouver le texte dedans... On peut avoir un export dans le programme, ok, mais qu'est-ce qui dit que le programme exporte pas un service ou je ne sais quelle routine ? Faudrait un truc conventionnel, c'est un handicap. Et ça fait perdre les avantages d'utiliser une lib, c'est à dire les exports utilisés à la sauce de chaque page de man, suivant la présentation que veut lui donner l'auteur.

Tiens, je crois que mon shell gère déjà les packs archives (je sais qu'il gérait certains formats d'archives, mais je ne suis plus sûr pour les PA)

Excellent ! On peut y ajouter/supprimer des fichiers ? Il tient compte du standard des PA au niveau des fichiers supplémentaires (icon, author, version, comment) ?

On me dit dans l'oreillette que tout le monde ne connait pas forcément le format des PA et ce que peut faire PedroM avec.

Un pack archive, c'est donc une archive contenant des fichiers de tout type, avec ces particularités :
- le premier fichier est un exécutable, exécuté quand on tape le nom du pack dans un shell
- les autres fichiers sont compressés ou non, au choix du programmeur

Mon idée pour est donc tout simplement de rajouter une lib dans ce pack. Cette lib s'appellerait man, pour être identifiée en tant que doc du pack qui la contient. Cette lib contiendrait aussi des exports (ok, comme toute lib ) qui serviraient de section : aucun formatage à faire.

L'avantage de ce format d'archive est que PedroM sait les ouvrir et les manipuler, voire les décompresser, et ce de manière totalement transparente. C'est built-in et ça ne rajoute rien d'utiliser cette techno, qui a ma préférence.

Lionel Debroux (./12) :
L'ebook reader fait dans les 6 KB.

A mon avis, il y a largement moyen de reduire la taille de maniere significative

Je pense aussi. Ca devrait pouvoir tourner autour du kilo et encore.

y'a une spec qq part du format packarchive? ça pourrait coller avec mon projet aussi, et si ça pouvait m'éviter de recoder un format...

edit: ok trouvé topics/121211-nouveau-compresseur-tres-rapide#20

edit2: en fait ça colle pas avec ce dont j'ai besoin

Est-ce que tu veux faire du texte avec attributs (un sous-ensemble de la syntaxe txtrider), ou pas ? Dans le premier cas, ebook est de toute façon inadapté.

Il faudrait d'ailleurs lui ajouter de telles options a eBook

Lionel Debroux (./21) :
Est-ce que tu veux faire du texte avec attributs (un sous-ensemble de la syntaxe txtrider), ou pas ?

Apriori, non, pour les raisons suivantes :
- j'en ai jamais vu dans man, à part les titres des différentes rubriques
- personnellement, ça va me faire chier de faire une doc formatée
- ça augmente toute suite considérablement la taille de l'affichage, et ya besoin d'un parseur conséquent, même avec relativement peu de balises

./22: ben... ça augmenterait pas mal la taille d'ebook, et il y a déjà des outils très bien pour afficher les textes formattés. Est-ce que ça a vraiment un intérêt de faire ce genre d'extensions à ebook ?

./23: OK, je suis assez d'accord avec ça.

Bah (parlant en connaissance de cause) un eBook n'est pas qu'un simple fichier texte, ce que eBook pour TI est actuellement... (cf l'OEBv1 ou l'ePub pour ne citer que des formats ouverts)

(et ok on ne parle que de TIs la, mais bon quand meme )

Flanker (./5) :
Sinon, pourquoi le mettre dans un pack et non directement dans la lib (ou je n'ai pas tout suivi) ?

L'avantage est de ne pas consommer de place à l'éxecution du programme : la doc est à part et est quasi-optionnelle: on peut repackger le PA sans.

Lionel Debroux (./10) :
ttunpack est, de nos jours, nettement plus rapide que la routine de décompression des pack archives, mais il me semble que PedroM embarque une version plus ancienne, plus générique mais plus grosse et beaucoup moins rapide, de ttunpack

Les Pack Archive sont indépendant d'une quelconque routine de compression: on peut très bien utiliser ttunpack pour les compresser. PedroM (PreOS) les fera très bien marcher.
On peut aussi très bien mettre la routine de décompression (ttunpack) compressé avec shrnklib dans le Pack Archive contenant l'executable (compressée avec ttunpack) et ca marche très bien (tu peux même mettre du ziplib au milieu !) (ou dans un autre exe . Il faut juste créer une librarie kernel exportant une fonction au prototype imposée (la routine de décompression).
Un jour je passerai tout stdlib à ttpack en créant tnpcklib

Et PedroM intègre la dernière routine de ttunpack (rapide).

squalyl (./20) :
edit2: en fait ça colle pas avec ce dont j'ai besoin

Par curiosité, pourquoi ?

(il va te copier/coller la réponse qu'il a fournie à mon mmsg )

Les Pack Archive sont indépendant d'une quelconque routine de compression: on peut très bien utiliser ttunpack pour les compresser

Ah oui... ça me rappelle quelque chose, maintenant

Et PedroM intègre la dernière routine de ttunpack (rapide).

Good

PpHd -> d'ailleurs, t'as une préconisation au niveau de la compression ? Ou c'est toujours shrinklib le standard de fait ?

Folco (./29) :
PpHd -> d'ailleurs, t'as une préconisation au niveau de la compression ? Ou c'est toujours shrinklib le standard de fait ?

Y'a pas de standard. Tu prends ce que tu veux (et ce qui existe actuellement).