[mOved] PedroM Command List - Page 3

bah... c toi qui prog PedroM, a la base

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

Pareil

Nil
a écrit : Je ne sais pas si ça a été demandé, mais une commande de type "exist" pour tester l'existence d'un fichier

Pourquoi pas comme pour les shell-scripts :
if [ -e fichier]
Pareil pour -f, -d et -x dans le cas de PedroM.

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

perso, je dirai une compatibilité assez importante avec les sh unix... histoire de ne pas destabiliser...
mais si tu veux prendre des libertees, pkoi pas
(cela dit, pas des libertées abusées, du style ls pour remplacer cat, ou dans le genre (j'exagére, mais bon ))
comme l'on dit d'autres, il serait cool de conserver une certaine logique des commandes

Et les commandes minimums ?

au strict minimum :
cp, ls (avec options -a pour montrer aussi les fichiers cachés, par exemple, -l pour afficher plus que simplement les noms de fichiers, ...), mv, rm, mkdir, rmdir
cat ca peut aussi etre utile, de meme que more (more étant d'autant plus utile si on a les flux et pipes)
les trucs du style >, >>, <, et le pipe |
heu... pour le reste, j'ai pas encore trop l'habitude de l'environnement console unix...

les tests de condition, ca serait pas mal, de meme que les boucles...
(au moins une boucle while...endwhile ca serait pas mal...)

Pour respecter la syntaxe sh/bash, ça serait if/then/elif/else/fi, for/in/do/done, while/do/break/done, until/do/done, case/in/)/;;/esac.
Il faudrait que script et prgms asm puissent accèder à l'stdin/out et retourner une valeur. Et il faudrait pouvoir utiliser la valeur avec ` ` ou quelque chose qui ressemble.
Ou c'est trop, là ? Ca serait chouette en tout cas.

squale92
a écrit : les trucs du style >, >>, <, et le pipe |

Mais alors ça serait un faux pipe en deux temps.

oue, ca serait cool

Mais alors ça serait un faux pipe en deux temps

heu

Normalement les deux processus s'exécutent en même temps et se partagent la mémoire de façon synchronisée je crois.

Normalement les deux processus s'exécutent en même temps et se partagent la mémoire de façon synchronisée je crois

ah, ok
je croyais que ca dependait de ce quo'n fait...
que genre, pour un
ls | more
tu avais ls, qui mettait son resultat dans un buffer, et que appres, more etait lancé sur le resultat contenu dans ce buffer, une fois ls fini...
mais bon, pour l'utilisateur, ca revient au meme...

squale92
a écrit : je croyais que ca dependait de ce quo'n fait...

Ah, oui.
Par exemple cat|more &
puis ps -> cat et more sont suspendus, alors que c'est pas le cas pour ls|more (mais ça pourrait l'être si le tube était plein je crois).

heu... possible...
(j'en sais pas assez pour dire, là )

moi je suis pour quelque chose de compatible dans la limite du réalisable. les flux ca serait vraiment mais je veux pas te voir mourir de surchauffe cérébrale avant la sortie officielle de PedroM. par contre le variables système en $xxx, les paramètres en $1, $2 et tout ces truc pas trop dificile a implémenter j'aimerai bien les avoirs.

Je voudrais pas dire, mais vous dites que c pas dur d'apprendre les nouvelles commandes d'un shell, mais vous voulez pas que PpHd prennent des libertés:-/

si c'est pour ajouter des fonctionnalités on est pour mais pour ce qui existe déja en shell script autant reprendre la même syntaxe vu qu'il est parti sur ce modèle.

Pour les pipes, ca sera des faux (si je le fais), car y'a qu'un processus qui fonctionne (Je vous rappelle que c'est pas du multitache !).

Quelles sont les variables systemes que vous desirez ?

Uther Lightbringer
a écrit : si c'est pour ajouter des fonctionnalités on est pour mais pour ce qui existe déja en shell script autant reprendre la même syntaxe vu qu'il est parti sur ce modèle.

C vrai qu'il est partis sur ce model. Mais a priorie, ils voulaient pas continuer


Càd les variables systemes ??

Pour les pipes, même si c'est des faux ca serait vraiment énorme! Si tu fait ca je sais plus comment t'appeller (y'a quoi au dessus de dieu? )
les premières variables systèmes qui me viennent à l'esprit:
$APD
$PATH(comme sous unix)
$TIME/$DATE(pour pedrom 2.0)
$F1KEY, F2KEY ...
$FONT(si tu permet de changer de fonte)
$0,$1, $2,...,$#, $*, $? pour les scripts

ca serait bien aussi une fonction "system(char* commande)" dans les programmes

sous les UNIX,Linux,... il y a des variables systèmes qui contiènnent par exemple l'heure($TIME), la date($DATE), les répertoire ou chercher les executables($PATH)...

Wow... et après il est embauché chez Palm pour la réalisation du nouveau PalmOS, non ?

Uther>ok
Ce serait pas plus économique de faire des fonction qui détermine ça ??

Uther>Yen a aussi sous DOS - les variables d'environnement (définies avec SET) et les variables systèmes ($x) - (mais bien sur beaucoup moins !)

Macintoc> bah non je ne pense pas si l'implémentation des variables est correcte. La seule différence c'est que les scripts peuvent y accèder directement donc que du bon.

pour les variables globales, PATH, je vois pas trop l'utilite...
sinon, les entres des scripts, genre $1, $2, ... ca serait pratique
je me souvient plus trop, mais il doit y avoir aussi moyen de recuperer le nombre d'entrees, ainsi que la valeur de retour (genre $0 et $$ ou $? ou dans le genre), qui seraient pratiques...

bah si au contraire c'est super utile de pouvoir mettre ces scripts perso dans un répertoire /bin et de pouvoir les executer depuis n'importe ou!
Pour le nombre d'argument variables, sous unix, il vaut mieux faire avec le shift jusqu'a se que $1 = ""

bah si au contraire c'est super utile de pouvoir mettre ces scripts perso dans un répertoire /bin et de pouvoir les executer depuis n'importe ou

erf, oue, remarque, c'est vrai

squale92
a écrit : je me souvient plus trop, mais il doit y avoir aussi moyen de recuperer le nombre d'entrees, ainsi que la valeur de retour (genre $0 et $$ ou $? ou dans le genre), qui seraient pratiques...

$$ donne le PID du processus, $# donne le nombre de paramètre, $? donne la valeur de retour, $0 donne le nom du script, $* donne la liste des paramètres.

Merci

(force est de reconnaitre que je ne fais pas assez souvent de Shell-scripts )

Le path existe deja, Uther. Ce n'est pas une variable systeme, c'est tout.

>$APD / $PATH / $F1KEY, F2KEY ... / $FONT
Est-ce vraiment necessaire, compte tenu que l'interet de lecture est minime, et qu'on peut deja les modifier par des commandes ? En gros, quel interet de savoir les lire ?


>$0,$1, $2,...,$#, $*, $? pour les scripts
Je prevois un truc different. Au demarrage d'un script une var globale args est initialise contenant la liste des arguments (Au passage, vous remarquerez que vous pouvez deja travailler avec les string/liste meme si PedroM retourne toujours un float).
D'ou ceci :

for i 1 dim(args)
echo "Detruire le fichier ${args[i]} - (OUI = ENTER)"
if getkey()=13
unarc ${args[i]}
rm ${args[i]}
fi
next

Selon la convetion PedroM implicite, la valeur de retour d'un programme est un float.
Ca vous convient ?

oue, la liste d'arguemtns est ue idee pas mauvaise
(pas trop francaise, ma phrase )

mais ca serait pas mal de puvoir decaler les arguments, comme avec shift, jusqu'a avoir args[1]=NULL

args[0] contient le nom du script, je suppose ?

Si vous voulez... M'enfin, c'est vraiment necessaire ?
On peut toujours faire lef(args,1)->args