il faut d'abord s'avoir qu'il faut utiliser la commande ls pour voir tes fichiers
pour ton exercice, tu eut utiliser la commande test.

Essayez ce script :

#!/bin/bash
for i in `ls`
do
if test -x $i && test -f $i
then
echo "$i"
fi
done


il faut ensuite rendre votre script exécutable par la commande chmod

Poste le Saturday 29 April 2006 20:05:15

The International Obfuscated Shell script Contest

ls_binaries () {  rep="./" ;  [  ${#1}  -gt 0  ] &&  rep=$1     ;  find $rep  -type f  -perm +a+x;  }

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Sunday 30 April 2006 00:31:28

Bonjour,

Ce "script" fera les deux : si tu ne donnes pas de répertoire en argument, il opérera sur le répertoire courant. Par défaut 'find' est une commande récursive, le "-maxdepth 1" inhibe ce comportement pour le rapprocher de celui de 'ls'.

#!/bin/sh

find ${1:-.} -type f -perm +111 -maxdepth 1

# FDF

Note: attention car si ton unix n'utilise pas bash, certaines syntaxes peuvent ne pas fonctionner. Celle-ci passe en ash, elle ne devrait donc pas poser de problème. ;-)

Poste le Sunday 30 April 2006 09:37:00

Citation
Kaka
Bonjour !!

je ne connais pas bien unix, je suis en train de
l'étudier et je dois faire un petit exercice :
je dois écrire un script qui affiche uniquement
les fichiers exécutables présent dans le
repertoire courant.
Ensuite le modifier pour qu'il puisse recevoir le
nom d'un repertoire en paramètre.
"lsx" est le nom du repertoire.

Bon, pas mal de solutions ont été données. Je ne vais pas en donner d'autre mais essayer de repérer les avantages et inconvénients de chacune

La solution de romy est simple et élégante et correspond généralement à ce qu'on attend d'un exercice pour débutant. Il ne manque plus que le répertoire à prendre en argument mais c'est un détail.
Juste 2 remarques
- for i in `ls` => le pb du for est qu'il utilise l'espace pour séparer ses mots. Si jamais on a un fichier contenant un espace dans son nom (rare mais possible), i prendra comme valeur le début du nom, puis la fin du nom. Mais le fichier ne sera pas traité
Vaut mieux utiliser le read qui s'arrête au return
=> ls |while read i
Mais cette syntaxe est généralement hors de portée d'un débutant donc le "for i in `ls`" est parfait

if test -x $i && test -f $i
Teste si le fichier est exécutable et, si le test est vrai, teste si c'est un fichier régulier. On peut aussi inclure le "and" dans le test
=> test -f $i -a -x $i
La différence est que dans ce cas, même si -f renvoie "faux" et que le test est donc définitivement faux, il vérifiera quand-même "-x" alors que dans le premier cas, il n'évalue -f que si -x est vrai

La solution de Brugmans est comme toujours remarquablement concise. Lui il crée non pas un script mais une fonction qui devient donc interne et n'a plus besoin d'être supportée par un script externe pour être utilisée. Dommage cependant d'avoir assigné "rep" puis testé que $1 existait sans avoir pensé à faire directement:
rep=${1:-./}
En ce qui concerne la vérification de l'argument, Vaut-il mieux tester ${#1} -gt 0 ou -n "$1" ou $# -gt 0 ???

La solution de Mushroom utilise aussi la commande "find" qui permet de rechercher les fichiers ayant une certaine caractéristique (ici exécutable). Et l'idée de prendre ${1:-.} est jolie.
Je pense cependant que ces 2 solutions à base de "find" sont trop élaborées. A mon avis, le but de ce TP est d'apprendre à voir l'imbrication des variables dans des boucles avec des tests. Si on passe par des commandes qui font déjà tout ce qu'il faut faire, ça marchera mais le but réel ne sera pas atteint...

Citation
Kaka
Pouvez-vous m'aider s'il vous plait.

Cours complet de shell ici
[fr.lang.free.fr]



L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Sunday 30 April 2006 20:16:38

Je vous remercie pour votre aide.
J'ai trouvé la solution de Romy plus simple, pour les autres c'est bien aussi mais un peu compliqué par rapport à mon niveau.
Je vais donc essayer la solution de Romy et je donnerai le resultat.
Merci

Poste le Sunday 30 April 2006 21:38:12

Compliqué, il ne faut rien exagérer, si le code de Frédéric Brugmans introduit effectivement la notion de fonction, le mien est à 99% une simple exploitation de man find. ;-)

Mais si vraiment tu veux rester avec des commandes de base, voici qui peut aussi convenir :

ls -F | grep "\*" | tr -d "*"

Un for/do/done pour effectuer un tri, je trouve tout de même ça un peu overkill car rien ici ne justifie d'individualiser le traitement des fichiers.

echo "2¢">>fontaine ^o^

Poste le Monday 1 May 2006 17:02:24

Sauf que ton exemple est embêtant si le nom de ton fichier contient des *. Ben oui, il y a toujours des boulets.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Monday 1 May 2006 17:45:20

Citation
Mushroom
Mais si vraiment tu veux rester avec des commandes
de base, voici qui peut aussi convenir :
ls -F |
grep "\*" | tr -d "*"

Hum, moi je dis non. Autant j'aimais bien le find que je trouvais élégant, autant j'aime pas du tout cette solution qui utilise un effet d'affichage de "ls" pour extraire les lignes contenant "*" (d'ailleurs on peut mettre grep "\*$" pour ne prendre que ce qui finit par "*").
Elle présente l'inconvénient de n'être pas portable. Ce script ne fonctionnera que si le "ls" local accepte l'option "-F" et seulement s'il affiche "*" pour les exécutables et dépend donc de plusieurs éléments qu'on ne contrôle pas. Ca restreint la portabilité...

Citation
Mushroom
Un for/do/done pour effectuer un tri, je trouve tout de même ça un peu overkill car rien ici ne justifie d'individualiser le traitement des
fichiers.

En fait, je pense que ce TP a été "inventé" (car l'utilité réelle d'un tel script reste un peu limite) uniquement pour forcer Kaka (super le pseudo !!!) à décomposer son pb en succession de tâches élémentaires. La solution de Romy présente donc, pour moi, celle qui répond le mieux aux exigences du TP et elle est 100% pur Bourne Shell.

Le pb d'un TP est qu'on ne demande pas forcément la meilleure solution mais celle qui montre le mieux qu'on arrive à utiliser les éléments connus pour résoudre un pb simple avec des éléments simples. Evidemment, dans la vraie vie, on a des pb plus ardus et là, on est forcé d'utiliser des solutions plus complexes à base de commandes subtiles comme find, awk, tr, sed, etc. Mais on arrivera d'autant mieux à résoudre ces pb complexes si on maîtrise déjà les structures de base du shell. Je présume que Kaka vient d'apprendre le if, la commande interne "test" et les boucles, donc forcément son TP sera en rapport avec ces éléments pour que le prof puisse juger qu'il les possède parfaitement avant de passer à la suite...



L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Monday 1 May 2006 17:50:28

Citation
Mushroom
Compliqué, il ne faut rien exagérer, si le code de
Frédéric Brugmans introduit effectivement la
notion de fonction, le mien est à 99% une simple
exploitation de man find.

Mais si vraiment tu veux rester avec des commandes
de base, voici qui peut aussi convenir :
ls -F |
grep "\*" | tr -d "*"
Un for/do/done pour effectuer un tri, je trouve
tout de même ça un peu overkill car rien ici ne
justifie d'individualiser le traitement des
fichiers.

echo "2¢">>fontaine

Deux petites choses :

1- Tu utilises non pas simplement find, mais également une particularité certains shells
2 - ls -F ... bof bof bof

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Monday 1 May 2006 18:58:18

Et bé... :-)

Citation
nicola
Sauf que ton exemple est embêtant si le nom de ton fichier contient des *. Ben oui, il y a toujours des boulets.

Certes, d'un autre côté c'est pas la seule commande à qui ça posera problème, donc l'erreur est côté utilisateur pas côté script. D'expérience, la phase où un script s'alourdit le plus est celle où tu imagines quelles bêtises pourraient avoir été commises en entrée... donc à un moment il faut dire "zut ! tant pis pour lui." et celle-ci est àmha plus que border-line.

Citation
Sve@r
Hum, moi je dis non. Autant j'aimais bien le find que je trouvais élégant, autant j'aime pas du tout cette solution qui utilise un effet d'affichage de "ls" pour extraire les lignes contenant "*" (d'ailleurs on peut mettre grep "\*$" pour ne prendre que ce qui finit par "*").

C'est clair que par rapport à un find, c'est de la semoule trop cuite. D'un autre côté, -F est référencée par le man dans les options POSIX, on peut donc supposer une certaine portabilité. Mais bon, je la donnais juste pour éviter le for/do/done qui est assez lourd (surtout en bash qui n'a tout de même rien d'un guépard côté vitesse d'exécution). Personnellement, je ne l'utiliserais pas, tout comme je n'utiliserais jamais un for/do/done.

Sur le fond autrement, je suis d'accord, un TP c'est (souvent) assez bête (inutile et ennuyeux). Néanmoins le shell devient àmha intéressant à partir du moment où on se met à exploiter le potentiel des commandes... d'ailleurs qu'est la programmation shell si ce n'est la combinaison des sorties de différentes commandes ? ...et puis, les forums ont-ils vocation à faire des TP ? ;-)

Citation
Frédéric Brugmans
1- Tu utilises non pas simplement find, mais également une particularité certains shells

Comme le sujet mentionnait unix sans autres précisions, j'ai testé le code en Ash Shell qui a vocation à rester le plus proche possible du Bourne Shell... àmha si ça passe en Ash, ça passe partout ou presque (avec tous les dérivés du Bourne Shell).

Poste le Monday 1 May 2006 22:46:12

Citation
Mushroom
Néanmoins le shell devient àmha intéressant à partir du moment où on se met à exploiter le
potentiel des commandes... d'ailleurs qu'est la
programmation shell si ce n'est la combinaison des
sorties de différentes commandes ?

Totalement d'accord...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Monday 1 May 2006 22:59:14

Citation
Mushroom
Comme le sujet mentionnait unix sans autres
précisions, j'ai testé le code en Ash Shell qui a
vocation à rester le plus proche possible du
Bourne Shell... àmha si ça passe en Ash, ça passe
partout ou presque (avec tous les dérivés du
Bourne Shell).

Ce n'est pas un reproche :-)) c'est une précision ;-)

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Tuesday 2 May 2006 06:38:12

Bonjour,

Citation
Frédéric Brugmans
Ce n'est pas un reproche image c'est une précision

D'accord, en fait j'ai eu un peu de mal à saisir le ton car le 1% manquant au man find faisait précisément référence à ça. ;-)
En poussant un peu les recherches, il semble d'ailleurs que cette syntaxe ne soit effectivement pas reconnue ni avec csh ni avec tcsh (qui ne sont, il est vrai, pas des dérivés du Bourne Shell).

Poste le Tuesday 2 May 2006 12:00:13

Citation
Mushroom
En poussant un peu les recherches, il semble
d'ailleurs que cette syntaxe ne soit effectivement
pas reconnue ni avec csh ni avec tcsh

Etonnant !!! Ton script n'utilise pas une syntaxe particulière de shell mais des options de la commande "find". Une commande est bien indépendante de l'environnement qui l'a lancée non ?
De toute façon, en écrivant "#!/bin/sh" en début de script, on s'affranchit de l'environnement de celui qui lancera le script puisque celui-ci sera traité (interprété+exécuté) par "/bin/sh"...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Tuesday 2 May 2006 13:35:08

Théoriquement le shell n'influe pas sur les commandes non, même si certaines sont implémentées avec des syntaxes différentes selon l'OS (c'est le cas de sed si on se fie à sa FAQ).

Mais en fait tcsh ne semble pas admettre la valeur par défaut : ni dans le man ni en pratique. Le code lancé avec tcsh (qui est un csh augmenté) renvoie :

Bad : modifier in $ (-)

En fait les syntaxes ne semblent pas du tout les mêmes qu'avec les dérivés Bourne Shell... si j'ai bien compris, le but des Shell Unix Berkeley était de rester proches de la syntaxe C.

Citation
Sve@r
De toute façon, en écrivant "#!/bin/sh" en début de script, on s'affranchit de l'environnement de celui qui lancera le script puisque celui-ci sera traité (interprété+exécuté) par "/bin/sh"...

Oui, peu de chances que sh pointe sur autre chose qu'un dérivé Bourne Shell... même sur les BSD, il semble que ce soit le cas. :-)

Poste le Tuesday 2 May 2006 13:56:15

Citation
Mushroom
Oui, peu de chances que sh pointe sur autre chose
qu'un dérivé Bourne Shell... même sur les BSD, il
semble que ce soit le cas.

/bin/sh ne pointe pas sur quoi que ce soit. Il s'agit du programme interprétant des commandes développé par Bourne.

Maintenant, sur Linux, étant donné que :
- le bash a aussi été développé par Bourne
- le bash est 100% compatible sh
alors le fichier "/bin/sh" est en effet un lien symbolique vers "/bin/bash" (d'où le terme "pointer"). Mais si l'une des conditions ci-dessus n'est pas respectée, alors on aura à la place de ce lien un vrai exécutable 100% Bourne Shell. En tout état de cause, on n'aura jamais autre chose qu'un Bourne Shell en "/bin/sh"


L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Tuesday 2 May 2006 15:31:25

Non, bash n'est pas 100% compatible sh. Enfin si, dans le sens sh -> bash, mais l'inverse (bash -> sh) n'est pas vrai (d'où l'intérêt de shells comme ash). Aussi une syntaxe bash peut ne pas passer en Bourne Shell pur :

#!/bin/sh

if [ "toto" == "toto" ]; then

        echo "ça marche 1"
fi

if [ "toto" = "toto" ]; then

        echo "ça marche 2"

fi
#FDF

La première est rejetée par le Ash Shell mais admise par Bash, ou encore :

#!/bin/sh

COUNT=1
echo $((COUNT+1))

# FDF

qui ne passe pas en Ash Shell. Donc oui, une syntaxe Bourne Shell passera partout, mais quelque chose qui passe lancé en sh sur un système ne passera pas forcément sur un autre. Et sous GNU/Linux tu peux faire pointer sh sur ce que tu veux (par exemple, le très populaire zsh a aussi son petit caractère par rapport à la syntaxe bash)...

Mais bon, si on veut vraiment faire du portable, àmha on scripte en autre chose qu'en shell (python, perl,...).

Poste le Tuesday 2 May 2006 16:44:05

Citation
Mushroom
Non, bash n'est pas 100% compatible sh. Enfin si,
dans le sens sh -> bash, mais l'inverse (bash -> sh) n'est pas vrai.

Oui, j'aurais dû dire "un script en sh est 100% compatible sur du bash"

Citation
Mushroom

#!/bin/sh 

COUNT=1 
echo $((COUNT+1)) 

# FDF

qui ne passe pas en Ash Shell.

=> Ni même en pur Bourne Shell

Citation
Mushroom
Donc oui, une
syntaxe Bourne Shell passera partout, mais quelque
chose qui passe lancé en sh sur un système ne
passera pas forcément sur un autre.

Euh, oui c'est vrai puisque sur Linux, tu bosses sans le savoir en bash donc t'es pas certain que ce que t'écrives soit 100% compatible sh

Citation
Mushroom
Mais bon, si on veut vraiment faire du portable,
àmha on scripte en autre chose qu'en shell
(python, perl,...).

Ben je connais pas (et ça me manque...)


L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Tuesday 2 May 2006 17:55:55

Je ne connais pas perl, un petit peu le python... il faudrait d'ailleurs que je m'y replonge. Le problème c'est que lorsque tu te débrouilles dans un langages, tu as tendance à penser les solutions par son crible, si bien qu'apprendre autre chose pour faire ce que tu sais déjà faire n'est pas très motivant....

J'ai aussi goûté un peu d'Ocaml : syntaxe sympa et chouette compilateur. Malheureusement les tutos sont assez rares et ce qu'on trouve est soit de la pure introduction pas très intéressante au niveau pratique soit - par rapport à mon niveau - difficile à aborder.

Mais ma meilleure impression reste sur python, ne serait-ce que pour la définition des blocs par indentation que je trouve très élégante. :-)

D'ailleurs pour python, si tu veux t'y essayer, il y a un bon tutoriel : Apprendre à programmer avec Python de Gérard Swinnen.

Poste le Tuesday 2 May 2006 18:57:28