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.
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
on peut dire que bash est une implémentation de sh avec des extensions.
dire qu'un script est portable parce que l'interpréteur spécifique peut compiler sur la plateforme, j'appelle ça de la mauvaise foi !
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Stephane Chazelas
2003-11-26, 15:37(+01), Pascal Bourguignon: [...]
Quel intérêt? En ce qui me concerne, si c'est pour la portabilité, j'ai décidé d'abandonner définitivement sh...
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
bash est une implémentation du shell standard POSIX sh (avec des extensions, comme la plupart des autres implémentations). Il y a un sh standard sous Linux (/bin/sh = bash, des fois dash), sous *BSD (/bin/sh = ash modifié), sous Solaris (/usr/xpg4/bin/shs un ksh88 (peut-etre modifié)), sous AIX, HPUX (ksh88 modifié).
Je pense que vous confondez tous "sh" et Bourne shell. Le Bourne shell a quasiment disparu des Unix récents. À part sous Solaris, s'il est encore là, il est rangé dans un chemin "musée" (/usr/old/bin/sh, /bin/sh.old, ou /bin/bsh).
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...)
Quel intérêt? En ce qui me concerne, si c'est pour la portabilité,
j'ai décidé d'abandonner définitivement sh...
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce
que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
bash est une implémentation du shell standard POSIX sh (avec des
extensions, comme la plupart des autres implémentations). Il y a
un sh standard sous Linux (/bin/sh = bash, des fois dash), sous
*BSD (/bin/sh = ash modifié), sous Solaris (/usr/xpg4/bin/shs un ksh88 (peut-etre modifié)), sous AIX, HPUX (ksh88 modifié).
Je pense que vous confondez tous "sh" et Bourne shell. Le Bourne
shell a quasiment disparu des Unix récents. À part sous Solaris,
s'il est encore là, il est rangé dans un chemin "musée"
(/usr/old/bin/sh, /bin/sh.old, ou /bin/bsh).
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...)
Quel intérêt? En ce qui me concerne, si c'est pour la portabilité, j'ai décidé d'abandonner définitivement sh...
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
bash est une implémentation du shell standard POSIX sh (avec des extensions, comme la plupart des autres implémentations). Il y a un sh standard sous Linux (/bin/sh = bash, des fois dash), sous *BSD (/bin/sh = ash modifié), sous Solaris (/usr/xpg4/bin/shs un ksh88 (peut-etre modifié)), sous AIX, HPUX (ksh88 modifié).
Je pense que vous confondez tous "sh" et Bourne shell. Le Bourne shell a quasiment disparu des Unix récents. À part sous Solaris, s'il est encore là, il est rangé dans un chemin "musée" (/usr/old/bin/sh, /bin/sh.old, ou /bin/bsh).
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...)
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
on peut dire que bash est une implémentation de sh avec des extensions.
dire qu'un script est portable parce que l'interpréteur spécifique peut compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
-- __Pascal_Bourguignon__ http://www.informatimago.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Living free in Alaska or in Siberia, a grizzli's life expectancy is 35 years, but no more than 8 years in captivity. http://www.theadvocates.org/
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce
que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
on peut dire que bash est une implémentation de sh avec des extensions.
dire qu'un script est portable parce que l'interpréteur spécifique peut
compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas
dans un pur sh, non?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Living free in Alaska or in Siberia, a grizzli's life expectancy is 35 years,
but no more than 8 years in captivity. http://www.theadvocates.org/
Bash est plus portable que sh. Existe-t'il un sh sur Linux? Est ce que bash n'est pas compilable sur tout les unix qui restent en vie? ;-)
on peut dire que bash est une implémentation de sh avec des extensions.
dire qu'un script est portable parce que l'interpréteur spécifique peut compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
-- __Pascal_Bourguignon__ http://www.informatimago.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Living free in Alaska or in Siberia, a grizzli's life expectancy is 35 years, but no more than 8 years in captivity. http://www.theadvocates.org/
DINH Viêt Hoà
dire qu'un script est portable parce que l'interpréteur spécifique peut compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
heu ... si tu vas par là, le fait que QNX propose des extensions non POSIX (pour le temps réel on va dire) en fait un système non-POSIX ?
Tu as un stock de mauvaise foi à revendre ?
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
dire qu'un script est portable parce que l'interpréteur spécifique peut
compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas
dans un pur sh, non?
heu ... si tu vas par là, le fait que QNX propose des extensions non
POSIX (pour le temps réel on va dire) en fait un système non-POSIX ?
Tu as un stock de mauvaise foi à revendre ?
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
dire qu'un script est portable parce que l'interpréteur spécifique peut compiler sur la plateforme, j'appelle ça de la mauvaise foi !
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
heu ... si tu vas par là, le fait que QNX propose des extensions non POSIX (pour le temps réel on va dire) en fait un système non-POSIX ?
Tu as un stock de mauvaise foi à revendre ?
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Stephane Chazelas
2003-11-26, 18:12(+01), Pascal Bourguignon: [...]
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
Ben oui, sinon, on n'appellerait pas ça des "extensions". L'important c'est que bash interprête correctement les scripts écrits dans une syntaxe POSIX compliant, comme tous les shells POSIX compatible (dans le doute inverser "compatible" et "compliant").
Il y a quand même des extensions à bash qui ne fonctionneraient pas
dans un pur sh, non?
Ben oui, sinon, on n'appellerait pas ça des "extensions".
L'important c'est que bash interprête correctement les scripts
écrits dans une syntaxe POSIX compliant, comme tous les shells
POSIX compatible (dans le doute inverser "compatible" et
"compliant").
Il y a quand même des extensions à bash qui ne fonctionneraient pas dans un pur sh, non?
Ben oui, sinon, on n'appellerait pas ça des "extensions". L'important c'est que bash interprête correctement les scripts écrits dans une syntaxe POSIX compliant, comme tous les shells POSIX compatible (dans le doute inverser "compatible" et "compliant").
Je pense que vous confondez tous "sh" et Bourne shell.
Quelle est la différence, ô grand maître? :)
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Stephane Chazelas
2003-11-26, 20:37(+01), Emmanuel Florac:
Je pense que vous confondez tous "sh" et Bourne shell.
Quelle est la différence, ô grand maître? :)
"sh" :
Selon la Single UNIX Specification, voir http://www.opengroup.org/onlinepubs/007904975/utilities/sh.html http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html
Bourne shell :
un shell écrit par Steve Bourne dans les années 70, ya eu plusieurs versions par la suite, parfois différentes d'un système à l'autre. La plupart des shells récents (Bourne Again shell, Korn shell, Almquist shell, Z-shell...) ont leur syntaxe basée sur la sienne. La spécification de POSIX/SUS étant essentiellement basée sur la syntaxe de ksh88 elle même donc basée sur celle du Bourne shell ce qui fait qu'il y a des ressemblances.
C'était le "sh" par défaut de la plupart des Unix commerciaux jusqu'à ya encore une petite dixaine d'années. Aujourd'hui ce n'est plus le cas (pour Solaris, /bin/sh est un shell Bourne mais "getconf PATH" est censé retourner /usr/xpg4/bin devant /bin et system(3) ou popen(3) sont censés utiliser /usr/xpg4/bin/sh qui est un shell se conformant à la norme POSIX)
Pour tout savoir sur le Bourne shell : http://www.in-ulm.de/~mascheck/bourne/
Un diagramme reflettant l'histoire d'Unix et plein d'autres infos sur l'histoire d'Unix chez Éric Lévénez (http://www.levenez.com/)
Les sources originales du shell de Steve Bourne sont à http://www.tuhs.org/ (the UNIX heritage society).
Je pense que vous confondez tous "sh" et Bourne shell.
Quelle est la différence, ô grand maître? :)
"sh" :
Selon la Single UNIX Specification, voir
http://www.opengroup.org/onlinepubs/007904975/utilities/sh.html
http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html
Bourne shell :
un shell écrit par Steve Bourne dans les années 70, ya eu
plusieurs versions par la suite, parfois différentes d'un
système à l'autre. La plupart des shells récents (Bourne Again
shell, Korn shell, Almquist shell, Z-shell...) ont leur syntaxe
basée sur la sienne. La spécification de POSIX/SUS étant
essentiellement basée sur la syntaxe de ksh88 elle même donc
basée sur celle du Bourne shell ce qui fait qu'il y a des
ressemblances.
C'était le "sh" par défaut de la plupart des Unix commerciaux
jusqu'à ya encore une petite dixaine d'années. Aujourd'hui ce
n'est plus le cas (pour Solaris, /bin/sh est un shell Bourne
mais "getconf PATH" est censé retourner /usr/xpg4/bin devant
/bin et system(3) ou popen(3) sont censés utiliser
/usr/xpg4/bin/sh qui est un shell se conformant à la norme
POSIX)
Pour tout savoir sur le Bourne shell :
http://www.in-ulm.de/~mascheck/bourne/
Un diagramme reflettant l'histoire d'Unix et plein d'autres
infos sur l'histoire d'Unix chez Éric Lévénez
(http://www.levenez.com/)
Les sources originales du shell de Steve Bourne sont à
http://www.tuhs.org/ (the UNIX heritage society).
Je pense que vous confondez tous "sh" et Bourne shell.
Quelle est la différence, ô grand maître? :)
"sh" :
Selon la Single UNIX Specification, voir http://www.opengroup.org/onlinepubs/007904975/utilities/sh.html http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html
Bourne shell :
un shell écrit par Steve Bourne dans les années 70, ya eu plusieurs versions par la suite, parfois différentes d'un système à l'autre. La plupart des shells récents (Bourne Again shell, Korn shell, Almquist shell, Z-shell...) ont leur syntaxe basée sur la sienne. La spécification de POSIX/SUS étant essentiellement basée sur la syntaxe de ksh88 elle même donc basée sur celle du Bourne shell ce qui fait qu'il y a des ressemblances.
C'était le "sh" par défaut de la plupart des Unix commerciaux jusqu'à ya encore une petite dixaine d'années. Aujourd'hui ce n'est plus le cas (pour Solaris, /bin/sh est un shell Bourne mais "getconf PATH" est censé retourner /usr/xpg4/bin devant /bin et system(3) ou popen(3) sont censés utiliser /usr/xpg4/bin/sh qui est un shell se conformant à la norme POSIX)
Pour tout savoir sur le Bourne shell : http://www.in-ulm.de/~mascheck/bourne/
Un diagramme reflettant l'histoire d'Unix et plein d'autres infos sur l'histoire d'Unix chez Éric Lévénez (http://www.levenez.com/)
Les sources originales du shell de Steve Bourne sont à http://www.tuhs.org/ (the UNIX heritage society).
A conforming implementation shall meet all of the following criteria: [...] 4. The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application ).
A conforming implementation shall meet all of the following
criteria:
[...]
4. The system may provide additional utilities, functions, or
facilities not required by IEEE Std 1003.1-2001.
Non-standard extensions of the utilities, functions, or
facilities specified in IEEE Std 1003.1-2001 should be
identified as such in the system documentation. Non-standard
extensions, when used, may change the behavior of utilities,
functions, or facilities defined by IEEE Std 1003.1-2001.
The conformance document shall define an environment in
which an application can be run with the behavior specified
by IEEE Std 1003.1-2001. In no case shall such an
environment require modification of a Strictly Conforming
POSIX Application (see Strictly Conforming POSIX Application
).
A conforming implementation shall meet all of the following criteria: [...] 4. The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application ).
