Folco (./23) :
Ca nécessite donc d'utiliser zpack et zunpack. Ces programmes embarquent printf de tigcclib, c'est dommage sous PedroM où tu t'es amusé à faire une libc, d'autant plus qu'on perd stderr. Et on perd également l'exécution en archive, bref, on perd tous les avantages sur lesquels j'appuie pour les programmes dédiés à PedroM, je trouve ça dommage. Qui plus est, si on veut garder une compatibilité AMS (vu que les PA, zpack et zunpack le sont), il faut parser la ligne de commande avec les fontions de l'estack, donc on perd encore le main(int argc, const char** argv) spécifique à PedroM, et si commode. Je trouve que ça fait beaucoup de sacrifices, à moins de réimplémenter des fonctions zpack et zunpack dédiées à PedroM (entre autres en utilisant la lib système).

Là j'avoue que je ne comprends pas pourquoi tu me parles de zpack/zunpack.

Folco (./23) :
Je reste dans la situation où c'est une lib qui gère la ligne de commande : Est-ce que le programme va processer le fichier fcv, ou y a-t-il une commande derrière, auquel cas fcv sont des flags ? Et l'utilisateur peut de toutes façon avoir besoin de préfixer plusieurs options avec -, dans le cas où ses options demande des arguments (-i/--include, -f/--folder etc...).

A toi de voir quel est le mieux. N'oublie pas la cible finale.

Folco (./23) :
Je suis un peu perplexe. En plus, à moins de rajouter un fichier d'information spécifique à Par dans le pack archive, on perd l'outil d'enregistrement/restauration de path prévu pour Par. J'ai fait ça avec dans l'idée qu'après un crash ou une fausse manip, on peut remettre sa cals d'aplomb avec un simple appel à Par, en mode --force pour écraser ce qui peut avoir été corrompu (un fichier de configuration dans /system mal modifié par l'utilisateur, et qui fait merde un soft par exemple). En clair, je ne vois pas à quoi sert Par s'il suffit tout simplement d'utiliser zpack et zunpack qui existent déjà.

Ok, comme tu veux. Ce n'était qu'une proposition.