Y a-t-il sous bash une commande permettant de récupérer :
- le nom d'un fichier sans son extension ?
- l'extension d'un fichier sans son nom ?
- le chemin d'un fichier ?
Je souhaiterais en effet créer un petit script qui facilite la décompression
de fichiers OpenOffice .sxw
et je n'y connais rien en bash ...
Cela se présenterait comme cela :
#!/bin/sh
mkdir mon_fichier(sans l'extension) ;
cd mon_fichier(sans l'extension);
unzip mon_fichier.extension;
La seule chose que je sache est qu'un argument s'appelle avec $1 ...
#!/bin/sh mkdir --"${1%.sxw}" "--" #qui ne sert à rien ...
mkdir -- "${1%.sxw}"
Sans quoi tu ne pourra pas creer un repertoire qui commence par un "-" (ou un "+" dans certains cas). Pour tout ce qu'il y a avant le "--", il y a des contraintes de format des arguments, on ne peut donc pas mettre de variable (de donnee exterieure au script plutot)
-- Stephane
2004-10-21, 16:04(+02), Olivier V:
[...]
mkdir "${1%.sxw}"
unzip -d "${1%.sxw}" "$1"
Manque un "--" apres mkdir et avant "$1"
Cela donne donc :
#!/bin/sh
mkdir --"${1%.sxw}" "--" #qui ne sert à rien ...
mkdir -- "${1%.sxw}"
Sans quoi tu ne pourra pas creer un repertoire qui commence par
un "-" (ou un "+" dans certains cas). Pour tout ce qu'il y a
avant le "--", il y a des contraintes de format des arguments,
on ne peut donc pas mettre de variable (de donnee exterieure au
script plutot)
#!/bin/sh mkdir --"${1%.sxw}" "--" #qui ne sert à rien ...
mkdir -- "${1%.sxw}"
Sans quoi tu ne pourra pas creer un repertoire qui commence par un "-" (ou un "+" dans certains cas). Pour tout ce qu'il y a avant le "--", il y a des contraintes de format des arguments, on ne peut donc pas mettre de variable (de donnee exterieure au script plutot)
-- Stephane
Nicolas George
"TiChou" wrote in message :
Faudrait peut être nuancer... Ce n'est pas, l'utilisation de && et de || qui fait que ça ne fonctionne pas mais plutôt parce que j'ai commis une (petite) erreur dans mon code.
Disons que l'usage de || et && dans les cas non-triviaux est plus propice aux erreurs.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je vois qu'ici vous faites usage de la commande 'printf', qui certes a ses avantages dans de nombreux cas mais guère ici. Pensez-vous alors que la syntaxe de la commande 'printf' est ici beaucoup plus lisible que la commande echo ? Où est-ce juste un excès de zèle ? ;)
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en début d'argument ou un quelque part, et probablement d'autres cas bizarres. Pour afficher un message constant, ça passe, mais dès qu'il y a une donnée extérieure, ça peut donner des résultats bizarres. Évidemment, ce n'est pas bien grave, et celui qui appelle son fichier « -en » cherche les coups, mais on est perfectionniste ou un ne l'est pas.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
"TiChou" wrote in message <gniii.20041021160421@florizarre.tichou.org>:
Faudrait peut être nuancer... Ce n'est pas, l'utilisation de && et de || qui
fait que ça ne fonctionne pas mais plutôt parce que j'ai commis une (petite)
erreur dans mon code.
Disons que l'usage de || et && dans les cas non-triviaux est plus propice
aux erreurs.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je
suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je
vois qu'ici vous faites usage de la commande 'printf', qui certes a ses
avantages dans de nombreux cas mais guère ici. Pensez-vous alors que la
syntaxe de la commande 'printf' est ici beaucoup plus lisible que la
commande echo ? Où est-ce juste un excès de zèle ? ;)
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en
début d'argument ou un quelque part, et probablement d'autres cas
bizarres. Pour afficher un message constant, ça passe, mais dès qu'il y a
une donnée extérieure, ça peut donner des résultats bizarres. Évidemment, ce
n'est pas bien grave, et celui qui appelle son fichier « -en » cherche les
coups, mais on est perfectionniste ou un ne l'est pas.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
Faudrait peut être nuancer... Ce n'est pas, l'utilisation de && et de || qui fait que ça ne fonctionne pas mais plutôt parce que j'ai commis une (petite) erreur dans mon code.
Disons que l'usage de || et && dans les cas non-triviaux est plus propice aux erreurs.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je vois qu'ici vous faites usage de la commande 'printf', qui certes a ses avantages dans de nombreux cas mais guère ici. Pensez-vous alors que la syntaxe de la commande 'printf' est ici beaucoup plus lisible que la commande echo ? Où est-ce juste un excès de zèle ? ;)
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en début d'argument ou un quelque part, et probablement d'autres cas bizarres. Pour afficher un message constant, ça passe, mais dès qu'il y a une donnée extérieure, ça peut donner des résultats bizarres. Évidemment, ce n'est pas bien grave, et celui qui appelle son fichier « -en » cherche les coups, mais on est perfectionniste ou un ne l'est pas.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
Olivier V
Merci à tous pour vos explications.
Mais pour la ligne unzip, c'est bien unzip -d "${1%.sxw}" "$1" ? pas de -- si j'ai compris ?
#!/bin/bash [ -f "$1" ] || { echo "$1 n'est pas un fichier" >&2 ; exit 1 ; } [ "${1%.*}.sxw" != "$1" ] && echo "$1 n'est pas un fichier .sxw" >&2 && exit 1 mkdir -- "${1%.sxw}" unzip -d "${1%.sxw}" "$1"
par contre le troisième ne fonctionne pas.
Enfin, tout cela me va très bien !
Olivier V
Stephane Chazelas
2004-10-21, 20:40(+02), Olivier V:
Merci à tous pour vos explications.
Mais pour la ligne unzip, c'est bien unzip -d "${1%.sxw}" "$1" ? pas de -- si j'ai compris ? [...]
Ben si. Comme j'ai dit, la ou se trouve "$1" au dessus, unzip n'a pas moyen de savoir si c'est une option ou un fichier si le nom du fichier commence par "-"
unzip -d "${1%.sxq}" -- "$1"
-- Stephane
2004-10-21, 20:40(+02), Olivier V:
Merci à tous pour vos explications.
Mais pour la ligne unzip, c'est bien
unzip -d "${1%.sxw}" "$1"
? pas de -- si j'ai compris ?
[...]
Ben si. Comme j'ai dit, la ou se trouve "$1" au dessus, unzip
n'a pas moyen de savoir si c'est une option ou un fichier si le
nom du fichier commence par "-"
Mais pour la ligne unzip, c'est bien unzip -d "${1%.sxw}" "$1" ? pas de -- si j'ai compris ? [...]
Ben si. Comme j'ai dit, la ou se trouve "$1" au dessus, unzip n'a pas moyen de savoir si c'est une option ou un fichier si le nom du fichier commence par "-"
unzip -d "${1%.sxq}" -- "$1"
-- Stephane
Stephane Chazelas
2004-10-21, 14:37(+00), Nicolas George: [...]
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en début d'argument ou un quelque part, et probablement d'autres cas bizarres. [...]
Bah, c'est deja pas mal. Il y aura des "echo" qui ne marcheront plus avec une liste d'arguments trop grande, mais on peut en dire autant de printf.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
Il est builtin dans la plupart des shells. Mais contrairement a bash ou a ksh, son comportement ne depend pas des options de compilations du shell ou de l'environnement.
zsh supporte:
echo -E - $var
mais aussi
print -r -- $var
comme ksh. J'aurais trouvé plus logique que -r soit l'option par defaut et qu'il faille un disont -e pour activer l'expansion des t, n... mais bon.
printf n'est builtin dans zsh que depuis les versions 4.1.
-- Stephane
2004-10-21, 14:37(+00), Nicolas George:
[...]
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en
début d'argument ou un quelque part, et probablement d'autres cas
bizarres.
[...]
Bah, c'est deja pas mal. Il y aura des "echo" qui ne marcheront
plus avec une liste d'arguments trop grande, mais on peut en
dire autant de printf.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
Il est builtin dans la plupart des shells. Mais contrairement a
bash ou a ksh, son comportement ne depend pas des options de
compilations du shell ou de l'environnement.
zsh supporte:
echo -E - $var
mais aussi
print -r -- $var
comme ksh. J'aurais trouvé plus logique que -r soit l'option par
defaut et qu'il faille un disont -e pour activer l'expansion des
t, n... mais bon.
printf n'est builtin dans zsh que depuis les versions 4.1.
La commande echo est totalement imprévisible dès qu'elle a affaire a un - en début d'argument ou un quelque part, et probablement d'autres cas bizarres. [...]
Bah, c'est deja pas mal. Il y aura des "echo" qui ne marcheront plus avec une liste d'arguments trop grande, mais on peut en dire autant de printf.
À noter qu'avec zsh, echo est un builtin, de comportement prévisible :-Þ
Il est builtin dans la plupart des shells. Mais contrairement a bash ou a ksh, son comportement ne depend pas des options de compilations du shell ou de l'environnement.
zsh supporte:
echo -E - $var
mais aussi
print -r -- $var
comme ksh. J'aurais trouvé plus logique que -r soit l'option par defaut et qu'il faille un disont -e pour activer l'expansion des t, n... mais bon.
printf n'est builtin dans zsh que depuis les versions 4.1.
-- Stephane
Stephane Chazelas
2004-10-21, 16:27(+02), TiChou: [...]
if [ ! -f "$1" ]; then printf > &2 '"%s" n'''est pas un fichier regulier' "$1"
printf > &2 '"%s" n'''est pas un fichier reguliern' "$1"
Me semble pas que j'aie ecris "> &2" qui n'est pas portable.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je vois qu'ici vous faites usage de la commande 'printf', qui certes a ses avantages dans de nombreux cas mais guère ici.
Voir le post de Nicolas George.
Pensez-vous alors que la syntaxe de la commande 'printf' est ici beaucoup plus lisible que la commande echo ? Où est-ce juste un excès de zèle ? ;)
"echo" est une commande a bannir d'apres la "Single Unix Specification", et c'est une des moins portables.
-- Stephane
2004-10-21, 16:27(+02), TiChou:
[...]
if [ ! -f "$1" ]; then
printf > &2 '"%s" n'''est pas un fichier regulier' "$1"
printf > &2 '"%s" n'''est pas un fichier reguliern' "$1"
Me semble pas que j'aie ecris "> &2" qui n'est pas portable.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je
suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je
vois qu'ici vous faites usage de la commande 'printf', qui certes a ses
avantages dans de nombreux cas mais guère ici.
Voir le post de Nicolas George.
Pensez-vous alors que la
syntaxe de la commande 'printf' est ici beaucoup plus lisible que la
commande echo ? Où est-ce juste un excès de zèle ? ;)
"echo" est une commande a bannir d'apres la "Single Unix
Specification", et c'est une des moins portables.
if [ ! -f "$1" ]; then printf > &2 '"%s" n'''est pas un fichier regulier' "$1"
printf > &2 '"%s" n'''est pas un fichier reguliern' "$1"
Me semble pas que j'aie ecris "> &2" qui n'est pas portable.
Vous vous souciez précédement de la lisibilité du code, point sur lequel je suis assez d'accord avec vous si on s'adresse à un débutant. Seulement je vois qu'ici vous faites usage de la commande 'printf', qui certes a ses avantages dans de nombreux cas mais guère ici.
Voir le post de Nicolas George.
Pensez-vous alors que la syntaxe de la commande 'printf' est ici beaucoup plus lisible que la commande echo ? Où est-ce juste un excès de zèle ? ;)
"echo" est une commande a bannir d'apres la "Single Unix Specification", et c'est une des moins portables.
