22Close24
deleted2On the 2010-10-17 at 12:18pm
PpHd (./22) :
Oué. Sur TI, le clavier n'est pas super pratique. Surtout pour 89.

Ok, mais ça demande une double passe sur la ligne de commande.
En effet :
:> xxx fcv

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...).

et :
:> xxx fcv abc

Le programme doit processer deux fichiers, ou le fichier abc avec les options fcv ? A moins de normaliser ça, pour le moment c'est assez flou.
PpHd (./22) :
Ben le mieux serait que tu fasses des Pack Archive avec ce soft.

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).
PpHd (./22) :
Et perso, je ferrai plutôt une interface autre que vis system("par ...") pour les softs mais directement en exportant dans par les fonctions nécessaires pour l'utiliser directement.

C'est sûrement mieux, je vais faire ça.
PpHd (./22) :
Dans ce cas, les programmes (pour extraire) peuvent utiliser les fonctions du kernel existantes, et il ira utiliser par.

Juste une question, pourquoi les programmes appelleraient-ils Par si le kernel fournit les fonctions d'extraction qui vont bien ?

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à.