J'aimerais renommer les fichiers images transférés d'un appareil
photonumérique dans un répertoire à l'aide d'un script bash.
par exemple : dscf4125.jpg -> 4125paysage.jpg
- éliminer les 4 premières lettres (dscf)
- conserver le n° de quatres chiffres
- ajouter un nom descriptif au fichier (paysage)
- conserver le suffix (.jpg)
Comme vous pouvez vous en douter mes connaissances en programmation sont
(trés) faibles...
Si quelqu'un avait la bonté (et le temps) d'écrire ce script avec moult
commentaires "pas à pas" pour mon éducation.
Dans l'article , Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je me souviens bien) et qui ne fonctionnent plus en bash, car ça devient des mots qui ont une signification spéciale (e.g. "term" pour le signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <slrnbsa2dl.v46.lwa@victor.teaser.fr>,
Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur
lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je
me souviens bien) et qui ne fonctionnent plus en bash, car ça devient
des mots qui ont une signification spéciale (e.g. "term" pour le
signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article , Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je me souviens bien) et qui ne fonctionnent plus en bash, car ça devient des mots qui ont une signification spéciale (e.g. "term" pour le signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre
Dans l'article , Stephane Chazelas écrit:
Ce qui est important, c'est d'écrire des *script* sh (POSIX), pas d'utiliser tel ou tel *shell* POSIX. Un script POSIX sera interprêté correctement par tous les shells POSIX (ksh, emulations sh de bash et zsh, dash, les shells des *BSD...)
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on trouve encore installées sur certaines machines).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <slrnbs9i9u.48.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> écrit:
Ce qui est important, c'est d'écrire des *script* sh (POSIX),
pas d'utiliser tel ou tel *shell* POSIX. Un script POSIX sera
interprêté correctement par tous les shells POSIX (ksh,
emulations sh de bash et zsh, dash, les shells des *BSD...)
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante
renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on
trouve encore installées sur certaines machines).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Ce qui est important, c'est d'écrire des *script* sh (POSIX), pas d'utiliser tel ou tel *shell* POSIX. Un script POSIX sera interprêté correctement par tous les shells POSIX (ksh, emulations sh de bash et zsh, dash, les shells des *BSD...)
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on trouve encore installées sur certaines machines).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Stephane Chazelas
2003-11-26, 23:02(+00), Vincent Lefevre: [...]
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on trouve encore installées sur certaines machines).
De cet acabit-là, il y en a plein que ce soit chez bash, ksh, zsh ou dash. Il y en a chez zsh qui sont plus ennuyeuses que ça (je me souviens de quand t'avais signalé le problème, je ne trouve pas POSIX très clair là-dessus), par exemple le ${1+"$@"} qui fait du word splitting.
Mais il y a pas mal de points /à la con/ où zsh est plus POSIX-compliant que bash (par exemple l'expansion de "$*").
Bref, il n'y a pas de shell « tout-à-fait POSIX » tout comme il n'y a pas de programme totalement exempt de bug. Et la norme POSIX est loin d'être parfaite, il y a un formulaire pour signaler les problèmes et il y en a.
Cela dit, bash avait pour but premier d'être compatible, zsh non. Je constate que ça a handicapé bash au point qu'il est presque encore moins utilisable que ksh (!) et que zsh ne s'en sort pas si mal côté compatibilité (ils ont eu le bon sens, dès le départ de se détacher de POSIX [qui est un non-sens] et de fournir un mode de compatibilité, bash s'en est rendu compte trop tard et a fait les mauvais choix au départ).
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante
renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on
trouve encore installées sur certaines machines).
De cet acabit-là, il y en a plein que ce soit chez bash, ksh,
zsh ou dash. Il y en a chez zsh qui sont plus ennuyeuses que ça
(je me souviens de quand t'avais signalé le problème, je ne
trouve pas POSIX très clair là-dessus), par exemple le
${1+"$@"} qui fait du word splitting.
Mais il y a pas mal de points /à la con/ où zsh est plus
POSIX-compliant que bash (par exemple l'expansion de "$*").
Bref, il n'y a pas de shell « tout-à-fait POSIX » tout comme il
n'y a pas de programme totalement exempt de bug. Et la norme
POSIX est loin d'être parfaite, il y a un formulaire pour
signaler les problèmes et il y en a.
Cela dit, bash avait pour but premier d'être compatible, zsh
non. Je constate que ça a handicapé bash au point qu'il est
presque encore moins utilisable que ksh (!) et que zsh ne s'en
sort pas si mal côté compatibilité (ils ont eu le bon sens, dès
le départ de se détacher de POSIX [qui est un non-sens] et de
fournir un mode de compatibilité, bash s'en est rendu compte
trop tard et a fait les mauvais choix au départ).
zsh n'est pas tout à fait POSIX, car unset d'une variable inexistante renvoie une erreur. Idem pour d'anciennes versions de bash (mais qu'on trouve encore installées sur certaines machines).
De cet acabit-là, il y en a plein que ce soit chez bash, ksh, zsh ou dash. Il y en a chez zsh qui sont plus ennuyeuses que ça (je me souviens de quand t'avais signalé le problème, je ne trouve pas POSIX très clair là-dessus), par exemple le ${1+"$@"} qui fait du word splitting.
Mais il y a pas mal de points /à la con/ où zsh est plus POSIX-compliant que bash (par exemple l'expansion de "$*").
Bref, il n'y a pas de shell « tout-à-fait POSIX » tout comme il n'y a pas de programme totalement exempt de bug. Et la norme POSIX est loin d'être parfaite, il y a un formulaire pour signaler les problèmes et il y en a.
Cela dit, bash avait pour but premier d'être compatible, zsh non. Je constate que ça a handicapé bash au point qu'il est presque encore moins utilisable que ksh (!) et que zsh ne s'en sort pas si mal côté compatibilité (ils ont eu le bon sens, dès le départ de se détacher de POSIX [qui est un non-sens] et de fournir un mode de compatibilité, bash s'en est rendu compte trop tard et a fait les mauvais choix au départ).
Dans l'article , Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je me souviens bien) et qui ne fonctionnent plus en bash, car ça devient des mots qui ont une signification spéciale (e.g. "term" pour le signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris n'est vraiment pas clair] n'est pas un shell POSIX mais un shell Bourne) et en effet, le shell Bourne n'est pas POSIX conformant ET un script écrit pour un shell Bourne ne fonctionnera pas _forcément_ correctement s'il est interprêté par un shell POSIX.
Cela dit, le /usr/xpg4/bin/sh de Solaris est POSIX conformant, mais ça ne veut pas dire qu'un script qui marche pour ce shell marchera sous un autre shell lui aussi POSIX conformant vu que le /usr/xpg4/bin/sh de Solaris a lui aussi des extensions et qu'il y a des comportements /unspecified/ ou /undefined/ dans la spécification POSIX. Donc, je répète, ce qui est important c'est d'écrire un *script* POSIX conformant, pas de s'assurer qu'il marche avec *une* implementation de sh POSIX conformant, si on veut être portable.
Je sens qu'on va avoir besoin d'un cours d'algèbre booléenne bientôt...
Dans l'article <slrnbsa2dl.v46.lwa@victor.teaser.fr>,
Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur
lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je
me souviens bien) et qui ne fonctionnent plus en bash, car ça devient
des mots qui ont une signification spéciale (e.g. "term" pour le
signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh
sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris
n'est vraiment pas clair] n'est pas un shell POSIX mais un shell
Bourne) et en effet, le shell Bourne n'est pas POSIX conformant
ET un script écrit pour un shell Bourne ne fonctionnera pas
_forcément_ correctement s'il est interprêté par un shell POSIX.
Cela dit, le /usr/xpg4/bin/sh de Solaris est POSIX conformant,
mais ça ne veut pas dire qu'un script qui marche pour ce shell
marchera sous un autre shell lui aussi POSIX conformant vu que
le /usr/xpg4/bin/sh de Solaris a lui aussi des extensions et
qu'il y a des comportements /unspecified/ ou /undefined/ dans la
spécification POSIX. Donc, je répète, ce qui est important c'est
d'écrire un *script* POSIX conformant, pas de s'assurer qu'il
marche avec *une* implementation de sh POSIX conformant, si on
veut être portable.
Je sens qu'on va avoir besoin d'un cours d'algèbre booléenne
bientôt...
Dans l'article , Laurent Wacrenier <lwa@ teaser . fr> écrit:
Il ne me semble pas que la norme impose de renvoyer une erreur lorsqu'une fonctionalité non normalisée est appelée.
Il y a des choses qui fonctionnent en sh (de Solaris et d'OSF si je me souviens bien) et qui ne fonctionnent plus en bash, car ça devient des mots qui ont une signification spéciale (e.g. "term" pour le signal, alors que sh ne reconnaît que la forme "TERM" en majuscules).
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris n'est vraiment pas clair] n'est pas un shell POSIX mais un shell Bourne) et en effet, le shell Bourne n'est pas POSIX conformant ET un script écrit pour un shell Bourne ne fonctionnera pas _forcément_ correctement s'il est interprêté par un shell POSIX.
Cela dit, le /usr/xpg4/bin/sh de Solaris est POSIX conformant, mais ça ne veut pas dire qu'un script qui marche pour ce shell marchera sous un autre shell lui aussi POSIX conformant vu que le /usr/xpg4/bin/sh de Solaris a lui aussi des extensions et qu'il y a des comportements /unspecified/ ou /undefined/ dans la spécification POSIX. Donc, je répète, ce qui est important c'est d'écrire un *script* POSIX conformant, pas de s'assurer qu'il marche avec *une* implementation de sh POSIX conformant, si on veut être portable.
Je sens qu'on va avoir besoin d'un cours d'algèbre booléenne bientôt...
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris n'est vraiment pas clair] n'est pas un shell POSIX mais un shell Bourne) et en effet, le shell Bourne n'est pas POSIX conformant ET un script écrit pour un shell Bourne ne fonctionnera pas _forcément_ correctement s'il est interprêté par un shell POSIX.
Oui, mais le problème est que quand on écrit un script "sh", on commence toujours par
#!/bin/sh
Solaris aurait dû mettre le shell standard en standard...
L'autre problème est d'avoir un mécanisme de validation (ou tout du moins un truc genre lint qui détecte les problèmes éventuels).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <slrnbsajhc.48.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> écrit:
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh
sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris
n'est vraiment pas clair] n'est pas un shell POSIX mais un shell
Bourne) et en effet, le shell Bourne n'est pas POSIX conformant
ET un script écrit pour un shell Bourne ne fonctionnera pas
_forcément_ correctement s'il est interprêté par un shell POSIX.
Oui, mais le problème est que quand on écrit un script "sh", on
commence toujours par
#!/bin/sh
Solaris aurait dû mettre le shell standard en standard...
L'autre problème est d'avoir un mécanisme de validation (ou tout du
moins un truc genre lint qui détecte les problèmes éventuels).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Je pense que tu parles de Bourne shell en l'occurrence (/bin/sh sous Solaris [qui n'est pas le "sh" standard, ce en quoi Solaris n'est vraiment pas clair] n'est pas un shell POSIX mais un shell Bourne) et en effet, le shell Bourne n'est pas POSIX conformant ET un script écrit pour un shell Bourne ne fonctionnera pas _forcément_ correctement s'il est interprêté par un shell POSIX.
Oui, mais le problème est que quand on écrit un script "sh", on commence toujours par
#!/bin/sh
Solaris aurait dû mettre le shell standard en standard...
L'autre problème est d'avoir un mécanisme de validation (ou tout du moins un truc genre lint qui détecte les problèmes éventuels).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Erwan David
Vincent Lefevre <vincent+ écrivait :
Oui, mais le problème est que quand on écrit un script "sh", on commence toujours par
#!/bin/sh
Solaris aurait dû mettre le shell standard en standard...
Y'avait Ultrix aussi où le shell posix s'appelait sh5
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Oui, mais le problème est que quand on écrit un script "sh", on
commence toujours par
#!/bin/sh
Solaris aurait dû mettre le shell standard en standard...
Y'avait Ultrix aussi où le shell posix s'appelait sh5
