J'apprends à écrire des scripts SHELL (sh) ou (ksh).
J'aimerai apprendre à écrire des scripts interactifs qui génèrent des menus.
Voici le script que j'ai trouvé sur le WEB mais qui ne marche pas. Je ne
sais pas pourquoi.
Merci de m'aider à le faire tourner ou me proposer un autre script ou un
autre modèle plus facile.
Merci aussi de me conseiller des tutoriels ou des sites WEB qui m'aideront à
mieux apprendre à écrire de menus interactifs sous UNIX.
#! /bin/sh
opt1="Entrez le nom du répertoire."
opt2="Entrez le nom du fichier à rechercher."
opt3="Entrez la date du jour."
opt4="quitter le progamme."
echo -e "\nMENU RECHERCHE FICHIER\n"
Ce script ne fonctionne pas. Merci de me le corriger.
Ne manquerait il pas "bonjour" au début ?
Marc
"Guytou" wrote:
J'apprends à écrire des scripts SHELL (sh) ou (ksh). Merci de m'aider à le faire tourner ou me proposer un autre script ou un autre modèle plus facile.
Ce script utilise plein de choses non standard. Il doit marcher avec ksh93 ou bash normalement.
#! /bin/sh opt1="Entrez le nom du répertoire." opt2="Entrez le nom du fichier à rechercher." opt3="Entrez la date du jour." opt4="quitter le progamme." echo -e "nMENU RECHERCHE FICHIERn"
Pas de -e après echo.
echo -e " Option Descriptionn"
PS3=" Entrez votre choix : "
Utiliser PS3 pour indiquer un prompt n'a rien de standard, il vaut mieux utiliser printf pour afficher quelque chose.
select n'est pas standard. Utilise : read $option enleve la ligne avec select, et les do/done. Dans le case, il faut maintenant tester 1,2,3,4 et non $opt1 etc.
"Guytou" wrote:
J'apprends à écrire des scripts SHELL (sh) ou (ksh).
Merci de m'aider à le faire tourner ou me proposer un autre script ou un
autre modèle plus facile.
Ce script utilise plein de choses non standard. Il doit marcher avec
ksh93 ou bash normalement.
#! /bin/sh
opt1="Entrez le nom du répertoire."
opt2="Entrez le nom du fichier à rechercher."
opt3="Entrez la date du jour."
opt4="quitter le progamme."
echo -e "nMENU RECHERCHE FICHIERn"
Pas de -e après echo.
echo -e " Option Descriptionn"
PS3="
Entrez votre choix : "
Utiliser PS3 pour indiquer un prompt n'a rien de standard, il vaut mieux
utiliser printf pour afficher quelque chose.
select n'est pas standard. Utilise :
read $option
enleve la ligne avec select, et les do/done.
Dans le case, il faut maintenant tester 1,2,3,4 et non $opt1 etc.
J'apprends à écrire des scripts SHELL (sh) ou (ksh). Merci de m'aider à le faire tourner ou me proposer un autre script ou un autre modèle plus facile.
Ce script utilise plein de choses non standard. Il doit marcher avec ksh93 ou bash normalement.
#! /bin/sh opt1="Entrez le nom du répertoire." opt2="Entrez le nom du fichier à rechercher." opt3="Entrez la date du jour." opt4="quitter le progamme." echo -e "nMENU RECHERCHE FICHIERn"
Pas de -e après echo.
echo -e " Option Descriptionn"
PS3=" Entrez votre choix : "
Utiliser PS3 pour indiquer un prompt n'a rien de standard, il vaut mieux utiliser printf pour afficher quelque chose.
select n'est pas standard. Utilise : read $option enleve la ligne avec select, et les do/done. Dans le case, il faut maintenant tester 1,2,3,4 et non $opt1 etc.
Guytou
Oui Alain, vous avez raison C'est un oubli regretable Il manque bien un Bonjour au debut.
Guytou
"ALain Montfranc" a écrit dans le message de news:
Guytou a écrit
Ce script ne fonctionne pas. Merci de me le corriger.
Ne manquerait il pas "bonjour" au début ?
Oui Alain, vous avez raison
C'est un oubli regretable
Il manque bien un Bonjour au debut.
Guytou
"ALain Montfranc" <x@x.con> a écrit dans le message de news:
mn.74bc7d6c8e13856b.51095@x.con...
Guytou a écrit
Ce script ne fonctionne pas. Merci de me le corriger.
Oui Alain, vous avez raison C'est un oubli regretable Il manque bien un Bonjour au debut.
Guytou
"ALain Montfranc" a écrit dans le message de news:
Guytou a écrit
Ce script ne fonctionne pas. Merci de me le corriger.
Ne manquerait il pas "bonjour" au début ?
Rakotomandimby (R12y)
Guytou:
J'apprends à écrire des scripts SHELL (sh) ou (ksh). J'aimerai apprendre à écrire des scripts interactifs qui génèrent des menus.
Bon j'ai pas en shell, mais c'est aussi un langage de script: http://www.amk.ca/python/howto/curses/ http://gnosis.cx/publish/programming/charming_python_6.html Etc...
Guytou:
J'apprends à écrire des scripts SHELL (sh) ou (ksh).
J'aimerai apprendre à écrire des scripts interactifs qui génèrent des menus.
Bon j'ai pas en shell, mais c'est aussi un langage de script:
http://www.amk.ca/python/howto/curses/
http://gnosis.cx/publish/programming/charming_python_6.html
Etc...
J'apprends à écrire des scripts SHELL (sh) ou (ksh). J'aimerai apprendre à écrire des scripts interactifs qui génèrent des menus.
Bon j'ai pas en shell, mais c'est aussi un langage de script: http://www.amk.ca/python/howto/curses/ http://gnosis.cx/publish/programming/charming_python_6.html Etc...
Moi
Merci de m'aider à le faire tourner ou me proposer un autre script ou un autre modèle plus facile. Merci aussi de me conseiller des tutoriels ou des sites WEB qui m'aideront à mieux apprendre à écrire de menus interactifs sous UNIX.
dialog est fait pour ça (ou cdialog)
c'est basé sur ncurses et ça doit pouvoir faire l'affaire
il me semble qu'il existe même un xdialog
Reste à trouver un binaire pour ton Unix ou alors compiler
Merci de m'aider à le faire tourner ou me proposer un autre script ou un
autre modèle plus facile.
Merci aussi de me conseiller des tutoriels ou des sites WEB qui m'aideront à
mieux apprendre à écrire de menus interactifs sous UNIX.
dialog est fait pour ça (ou cdialog)
c'est basé sur ncurses et ça doit pouvoir faire l'affaire
il me semble qu'il existe même un xdialog
Reste à trouver un binaire pour ton Unix ou alors compiler
Merci de m'aider à le faire tourner ou me proposer un autre script ou un autre modèle plus facile. Merci aussi de me conseiller des tutoriels ou des sites WEB qui m'aideront à mieux apprendre à écrire de menus interactifs sous UNIX.
dialog est fait pour ça (ou cdialog)
c'est basé sur ncurses et ça doit pouvoir faire l'affaire
il me semble qu'il existe même un xdialog
Reste à trouver un binaire pour ton Unix ou alors compiler
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
--
Michel TALON
Moi <moi@ici.org> wrote:
il y a peut-être mieux
Peut être le module curses de python. Un joli exemple est le jeu de la
vie de Conway qui vient normalement avec python sous le nom life.py.
Un exemple très simple repeat.py
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
--
Michel TALON
Moi
Moi wrote:
il y a peut-être mieux
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire y compris ruby et l'inévitable perl :)
toutefois il faut apprendre le langage :(
Moi <moi@ici.org> wrote:
il y a peut-être mieux
Peut être le module curses de python. Un joli exemple est le jeu de la
vie de Conway qui vient normalement avec python sous le nom life.py.
Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire
y compris ruby et l'inévitable perl :)
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire y compris ruby et l'inévitable perl :)
toutefois il faut apprendre le langage :(
talon
Moi wrote:
Moi wrote:
il y a peut-être mieux
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire y compris ruby et l'inévitable perl :)
Of course! enfin apprendre perl il faut se prendre pour un fakir, et ruby ne vaut guère mieux - ou plutôt c'est aussi merdique en beaucoup plus lent.
toutefois il faut apprendre le langage :(
--
Michel TALON
Moi <moi@ici.org> wrote:
Moi <moi@ici.org> wrote:
il y a peut-être mieux
Peut être le module curses de python. Un joli exemple est le jeu de la
vie de Conway qui vient normalement avec python sous le nom life.py.
Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire
y compris ruby et l'inévitable perl :)
Of course! enfin apprendre perl il faut se prendre pour un fakir, et
ruby ne vaut guère mieux - ou plutôt c'est aussi merdique en beaucoup
plus lent.
Peut être le module curses de python. Un joli exemple est le jeu de la vie de Conway qui vient normalement avec python sous le nom life.py. Un exemple très simple repeat.py
en fait tout ce qui est à base de (n)curses peut faire l'affaire y compris ruby et l'inévitable perl :)
Of course! enfin apprendre perl il faut se prendre pour un fakir, et ruby ne vaut guère mieux - ou plutôt c'est aussi merdique en beaucoup plus lent.
toutefois il faut apprendre le langage :(
--
Michel TALON
Emmanuel Florac
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus. Remarque, Python ne fait pas beaucoup mieux.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus.
Remarque, Python ne fait pas beaucoup mieux.
--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus. Remarque, Python ne fait pas beaucoup mieux.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
talon
Emmanuel Florac wrote:
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus. Remarque, Python ne fait pas beaucoup mieux.
Python utilise les threads natifs du système, pour multiplexer son exécution, puis pose un verrou "global" pour que le code python ne puisse être exécuté que dans un seul thread à la fois (*). Par contre les entrées sorties et autres extensions externes programmées pour ça relachent le verrou, ce qui leur permet une exécution concurrente. En pratique ça préserve le plus gros des avantages du multithreading, car le temps mis à faire ces IO est bien plus grand que le temps mis à interprêter le code python dans la plupart des cas. En ce qui concerne la méthode de synchronisation, python, qui tourne à la fois sur Unix et Windows doit utiliser quelque chose qui est supporté partout. Il se limite donc à une technique simple et efficace, les verrous, essentiellement des mutex. Avec plusieurs verrous et quelques variables on peut facilement implémenter les autres procédures de synchronisation de pthread, après tout c'est bien comme ça qu'elles sont implémentées dans la librairie pthread. Il existe d'ailleurs un module de threading dit de "haut niveau" en python, qui implémente toutes ces constructions en python à partir des verrous de base. En Java je crois que le concept de base est celui des sections critiques, ce qui après tout est implémenté facilement par des mutex. Pour ce qui est de perl et ruby, je ne sais absolument pas comment ça se comporte dans ce domaine - le caractère abominable de la syntaxe me suffisant amplement pour me tenir à l'écart.
(*) ça sert à protéger les structures de données de l'interprête en particulier le nombre de références aux objets (qui sert à les détruire quand il tombe à zéro).
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus.
Remarque, Python ne fait pas beaucoup mieux.
Python utilise les threads natifs du système, pour multiplexer son
exécution, puis pose un verrou "global" pour que le code python ne
puisse être exécuté que dans un seul thread à la fois (*). Par contre
les entrées sorties et autres extensions externes programmées pour ça
relachent le verrou, ce qui leur permet une exécution concurrente.
En pratique ça préserve le plus gros des avantages du multithreading,
car le temps mis à faire ces IO est bien plus grand que le temps mis
à interprêter le code python dans la plupart des cas. En ce qui concerne
la méthode de synchronisation, python, qui tourne à la fois sur Unix et
Windows doit utiliser quelque chose qui est supporté partout. Il se
limite donc à une technique simple et efficace, les verrous,
essentiellement des mutex. Avec plusieurs verrous et quelques variables
on peut facilement implémenter les autres procédures de synchronisation
de pthread, après tout c'est bien comme ça qu'elles sont implémentées
dans la librairie pthread. Il existe d'ailleurs un module de threading
dit de "haut niveau" en python, qui implémente toutes ces constructions
en python à partir des verrous de base. En Java je crois que le concept
de base est celui des sections critiques, ce qui après tout est
implémenté facilement par des mutex. Pour ce qui est de perl et ruby, je
ne sais absolument pas comment ça se comporte dans ce domaine - le
caractère abominable de la syntaxe me suffisant amplement pour me tenir
à l'écart.
(*) ça sert à protéger les structures de données de l'interprête en
particulier le nombre de références aux objets (qui sert à les détruire
quand il tombe à zéro).
Le Fri, 15 Dec 2006 23:52:01 +0100, Harpo a écrit :
Benchmarks !
L'implémentations des threads en Ruby est à mourir de rire, en plus. Remarque, Python ne fait pas beaucoup mieux.
Python utilise les threads natifs du système, pour multiplexer son exécution, puis pose un verrou "global" pour que le code python ne puisse être exécuté que dans un seul thread à la fois (*). Par contre les entrées sorties et autres extensions externes programmées pour ça relachent le verrou, ce qui leur permet une exécution concurrente. En pratique ça préserve le plus gros des avantages du multithreading, car le temps mis à faire ces IO est bien plus grand que le temps mis à interprêter le code python dans la plupart des cas. En ce qui concerne la méthode de synchronisation, python, qui tourne à la fois sur Unix et Windows doit utiliser quelque chose qui est supporté partout. Il se limite donc à une technique simple et efficace, les verrous, essentiellement des mutex. Avec plusieurs verrous et quelques variables on peut facilement implémenter les autres procédures de synchronisation de pthread, après tout c'est bien comme ça qu'elles sont implémentées dans la librairie pthread. Il existe d'ailleurs un module de threading dit de "haut niveau" en python, qui implémente toutes ces constructions en python à partir des verrous de base. En Java je crois que le concept de base est celui des sections critiques, ce qui après tout est implémenté facilement par des mutex. Pour ce qui est de perl et ruby, je ne sais absolument pas comment ça se comporte dans ce domaine - le caractère abominable de la syntaxe me suffisant amplement pour me tenir à l'écart.
(*) ça sert à protéger les structures de données de l'interprête en particulier le nombre de références aux objets (qui sert à les détruire quand il tombe à zéro).
