[mOved] PedroM Command List - Page 2

Et sans déconner, qqch qui donne des infos sur une var dans une liste, genre taille etc.
et biensûr IF...GOTO

création de fichiers textes peut-être ..

Peut-être une commande d'arcdir d'archiver tous les dossiers dans une chemise?

nEUrOne
a écrit : création de fichiers textes peut-être ..

De l'stdin/stdout couplé à de la redirection vers fichier ? (> et >> )

c'est clair que la gerstion des stdin/stdout ca serait vraiment la valeur de retour d'un programme aussi.

clair que ca serait

kes ke c ???#n00b#

bah c'est les flux, très pratique quand on travaille en mode console. par exemple:
ls * > fic
ne va pas afficher la liste de répertoire a l'écran mais l'écrire dans le fichier fic. Le principe est qu'un programme a 3 flux, un d'entré(clavier par défaut), de sortie(ecran par défaut), sortie d'erreur(ecran pas défaut) que tu peux rediriger. dans l'exemple au dessus je redirige le flux de sortie vers le fichier fic.

l'équivalent du -> (sto) sur AMS, koi ??

Oui et Non on ne peut pas vraiment comparer vu que la on est sous une console(genre DOS) et non dans un CAS. en gros les données que le programme recoit et envoie transite par ces flux ce n'est pas une simple variable comme la valeur de retour du TIOS.

Je ne sais pas si ça a été demandé, mais une commande de type "exist" pour tester l'existence d'un fichier, une implémentation complète de copy (pour faire du "copy con xxx" de la concaténation, de la redirection [vers l'écran, un fichier, le port I/O->pratique si qq'un fait un adaptateur imprimante ...]).
Un "GotoXY"
Un "more" (affichage page par page)

Pour la ligne de commande, un système de jonction des commandes (comme sous nux ou dos "dir|more", "type|more").

Une commande mem peut-être plus complête (un peu à l'image de celle de l'AMS avec le détail)

Et quand tout sera bien implanté, un fichier d'aliases

Ah, oui et %1, %2, %3, %4 pour envoyer des paramètres à un programme, et une valeur de retour, aussi.

pour rester dans l'UNIX sa serait plustot un "cat >" que "copy con"
et %1, %2, %3, %4 donnerai plustôt $1, $2, $3, $4 ,... aussi

cat et more ca serait programmé en 10 minutes, le seul vrai problème c'est les redirections car ca donnerai pas mal de boulot a PpHd et demanderai d'adapter TIGCCLIB pour lrendre stdio.h vraiment standard.

Oui, t'as raison pour les détails unix/dos (même si je connais les commandes unix, j'avoue être carrément plus à l'aise en Batch).

Bah c'est qu'une habitude mais UNIX est quand même bien plus puissant.
Et puis la console DOS c'est mort alors autant utiliser la syntaxe UNIX qui a encore de beaux jours devant elle grace à Linux

[HS]Non, la console DOS n'est pas morte - Non, la console DOS n'est pas morte - Non, la console DOS n'est pas morte[/HS]
Cela dit, je suis tout à fait d'accord sur le fait que les shelle unix sont beaucoup plus performants (malgré les extensions possibles des .BAT grace aux codes ANSI)

Nil
a écrit : (malgré les extensions possibles des .BAT grace aux codes ANSI)

Qui permettent entre autre de redéfinir la touche espace en format /u c:.
L'interpréteur ANSI VT100 de DOS est le pire que je connais du point de vue sécurité.

Hmmm connaisseur, je vois (surtout pour le "/u" qui n'est documenté que dans une ditrib de DOS)

Je connais aucune commande Unix:-/

bah à la base pour faire aussi bien que DOS, ca s'apprend en 5 minutes chrono.

Et au pire, si VRAIMENT t'y arrive pas, tu te fais des aliases (mais je suis contre ls -> dir et ce genre de trucs)

Mac> les bases du shell et des commandes UNIX sont rqapides a apprendre.

clair que les flux et pipe, ca serait pas mal... :0

Nan, mais je dis pas ça pour me plaindre
G mis 5 minute pour apprendre les commande Batch de base, c pas les commandes Unix qui vont m'emmerder
Mais je trouve que les commandes batch sont plus intuitive.

Arg ! Vous voulez ma mort ou quoi

Pourquoi ?
Bon, c'est vrai que pour un début on n'a pas demandé les commandes les plus simples, mais les plus pratiques pour scripter... mais je pense que l'avantage de ton langage est qu'il est voué à remplacer le TI-Basic, non ?

Pas vraiment. C'es un langage de script. C'est tout.
Je ferrais ce que je pourrais.

erf... fallait pas nous demander notre avis

Ok. En tous cas, merci beaucoup pour tout ce travail !
(Mais le TI-Basic a aussi un rôle de langage de script, non ?)

oui, aussi.

Voulez-vous une compatibilite assez importante avec les shell unix ?
Ou je prend des libertes ?

Je pense que tu peux prendre des libertés, bien sur, mais à condition de garder la "logique" des commandes. (enfin, c'est mon avis)