« Je parle de toutes les implémentations de sh sur les systèmes.
On saura jamais qu'elle shell utilise tel ou tel système ! »
Mais on s'en fiche complètement de l'implantation ("implémentation" est une faute de français, soit dit au passage). Tous les systèmes, windows compris, disposent d'une implantation décente de sh.

« C'est au développeur de voir et de faire en sorte de trouver la meilleur solution pour son cas. » discours digne d'un ingénieur incompétent qui ne maîtrise rien. Des solutions, il n'y en a qu'une, et c'est sh. Si tu n'es pas d'accord avec ça, remets-toi en question car tu as tord./
Il n'y a qu'un seul type de personne pour qui faire un script bash peut avoir du sens, ce sont les développeurs d'une distribution basée sur bash. Et ces gens là, il y en a de l'ordre du millier sur la planète, donc c'est assurément pas "#!/bin/bash" qu'il faut enseigner aux étudiants.

« et que j'utilise des spécificités de bash ? » si tu utilises des spécificités de bash, soit tu es développeur d'une distribution que je n'utilise pas, soit tu es un mauvais scripteur.

« Tout ça pour dire je le répète :
C'est au développeur de voir et de faire en sorte de trouver la meilleur solution pour son cas ! »
et je me répète aussi. Sa solution c'est de faire du sh.

« Je vois pas trop en quoi ça me concerne... M'enfin, j'vais changer de pseudonyme si ça te gène tant que ça. » prendre le nom de quelqu'un d'autre sur un forum, c'est de l'usurpation d'identité.

NB: je ne suis pas godrik, et je ne suis pas aussi tolérant que lui. Les gens ne doivent pas faire de script bash, et à chaque fois que j'en verrai un faire ça, il aura droit à mon coup de gueule jusqu'à ce qu'il corrige son erreur ou qu'il s'en aille.

$ ./toto
-bash: ./toto: /bin/bash: bad interpreter: No such file or directory

'nuf said.

Rebonjour!
Les problèmes de syntaxe que je rencontrai au début de ce sujet ont été réglé, si bien qu'aujourd'hui j'ai presque fini mon projet, dont le seul défaut lié à Ubuntu reste la commande convert, non reconnue je le craint (mais ça doit se négocier en téléchargeant le nécessaire).
Ceci dit j'aimerai ajouter une touche personnelle au shell car un piège y subsiste: sur les deux arguments que je dois rentrer, l'un est un dossier. En testant mon shell je me suis aperçu que si le dossier comportait un espace, le shell le prenait les deux parties séparées par l'espace pour deux arguments distincts.
Je me demandais si vous aviez la solution à ce problème? à tous

convert c'est fourni par le paquet imagemagick.

« En testant mon shell je me suis aperçu que si le dossier comportait un espace, le shell le prenait les deux parties séparées par l'espace pour deux arguments distincts. » c'est normal. Si tu veux un argument avec un espace, soit tu protèges l'espace avec un \ devant, soit tu mets le tout entre ".

J'ai dl imagemagick ce matin même mais merci quand même ^^
Sinon tu sais si il y a une commande à rentrer dans le code shell afin que l'utilisateur puisse rentrer son dossier en argument sans avoir à se soucier des espaces (que les dossiers avec un ou plusieurs espaces puissent être écrits, sans qu'il y est besoin d'y ajouter les "")?

« J'ai dl imagemagick » ça sonne faux. Tu as fait quoi exactement ?

Ça s'appelle mettre des ". L'espace (non protégé), c'est ce qui sépare les arguments.

Bah j'ai dll le zip du site officiel d'imagemagick pour Unix.
J'ai plus qu'à mettre les fichiers à leur place et c'est bon
Sinon, dernière chose sur laquelle tu pourrais m'aider: comment vérifier le format d'un argument? Pour une date, par exemple, comment vérifier que le format sous laquelle elle est rentrée soit bien conforme à aammjj?
Une nouvelle fois

« J'ai plus qu'à mettre les fichiers à leur place et c'est bon » non, c'est pas bon du tout. Par contre c'est con. Le gestionnaire de paquets c'est pas fait pour les chiens./

Sinon, je n'ai pas de bonne solution pour vérifier le format d'un argument. Un case peut-être ?

Je ne sais pas en fait. On m'a conseillé de la comparé avec l'heure système mais bon... Sinon, pour le peu de temps que j'ai passé dessus, je n'ai pas vu de gestionnaire de paquet (il doit bien y être mais bon) parce qu'il me l'a automatiquement ouvert avec l'assistant pour les fichiers compressés. Je sais comment utilisé un gestionnaire de paquets, j'avais un ordi sous slitaz il n'y a pas si longtemps.

"e sais comment utilisé un gestionnaire de paquets"
C'est raconte dans la FAQ avec une jolie video.

« On m'a conseillé de la comparé avec l'heure système mais bon... » tu devrais faire encore plus goret.

Sinon, apprend à utiliser le gestionnaire de paquets. Si tu ne l'utilises pas, je t'enverrais bientôt balader. Je n'ai aucune pitié contre ceux qui n'utilisent pas le gestionnaire de paquets.

Mais JE l'utilise nuance, c'est juste que la seule fois où il me l'a ouvert c'était en lecture automatique, donc avec l'outil pour les zip.
Sinon ça ne me dit toujours pas comment m'occuper de cette histoire du format de date...

"si tu utilises des spécificités de bash, soit tu es développeur d'une distribution que je n'utilise pas, soit tu es un mauvais scripteur"

Bon, j'ai une question un peu HS, mais au point ou en est le topic, je crois que ça va aller.

L'autre jour j'écrivais un script et j'avais besoin depuis le script de connaître le nom du fichier (et le chemin, relativement au dossier courant) du script lui même et cela avec une méthode qui soit compatible, si possible, avec les cas les plus courant d'exécution d'un script (donc "./script", "sh script" ou ". script" disons). Or la seul chose que j'ai trouvée qui permette de faire ça c'est le "bashisme" $BASH_SOURCE qui donne cette information. Est-ce qu'il y a une autre méthode à coté de laquelle je serais passée ?

Avec dirname(1), basename(1) et $0, on doit pouvoir faire ça de façon portable.

`basename $0` ça m'a l'air de remplir parfaitement le cahier des charges, oui.

sand-snake : j'ai rien compris à ton histoire là ? Tu utilises une distribution linux ?

Ouais, mais ma virtual box a des problèmes je crois... après avoir parfaitement installer imagemagick grâce au gestionnaire de paquets et après avoir suivi les instructions du site officiel à la lettre, la commande convert ne marche toujours pas (elle est reconnue mais ne marche pas).
Et pour le problème de format de date c'est règlé

"`basename $0` ça m'a l'air de remplir parfaitement le cahier des charges, oui. "

Non :
$ mkdir foo
$ echo "echo $0" > foo/bar
$ sh foo/bar
bash

Car $0 contient le nom du programme qui a été lancé et ici c'est sh (bon bash sur ma debian) et non pas le script. Point intéressant, $1 ne contient pas non plus le nom du script, parce que le shell s'arrange pour que les $1, $2, ... soit les arguments que le script attend. Donc ceux qui viendraient après le nom du fichier sur la ligne de commande de sh, si j'en avait donné.

J'ai dit "`basename $0`", pas juste "$0".

En vrai, j'ai fais le même test que toi et chez moi ça marche parfaitement bien. Enfin, j'ai fais presque le même test, parce que :

chris@totorJr:~$ mkdir foo
chris@totorJr:~$ echo "echo $0" > foo/bar
chris@totorJr:~$ cat foo/bar
echo bash

EPIC FAIL

chris@totorJr:~$ echo 'echo `basename $0`' > foo/bar
chris@totorJr:~$ cat foo/bar
echo `basename $0`
chris@totorJr:~$ sh foo/bar
bar

Par ailleurs, tu te trompes sur $0. Quand tu fais "sh machin", tu lances certes sh, mais ce sh ouvre ensuite ton fichier pour l'interpréter comme si tu avais "./foo/bar" donc au final tu as :

Au niveau de ton bash, £SHELL == bash, $0 == sh et $1 ** foo/bar, MAIS dans ton sh (et c'est lui qui compte), tu as $SHELL == sh et $0 == foo/bar.

"cat foo/bar
echo bash

EPIC FAIL"

au temps pour moi ...

Par contre, avec :

$ cat foo/bar
echo `basename $0`
$ . foo/bar
bash

j'ai toujours le même problème. Hors, ultimement, ce script sert jute à augmenter le PATH avec un nouveau dossier (dont je connais le chemin relativement à la position du script) avant de rendre la main. Donc le "sourcer" est assez naturel. Pour l'instant, l'autre possibilité est de lancer un nouveau shell depuis le script, mais ce n'est pas très agréable non plus.