J'ai un peu honte de poser cette question, tellement ça doit être une faq de
débutant, mais bon. J'aimerai apprendre un peu à écrire des scripts shell
pour automatiser des petits trucs, mais je ne sais pas bien par où
commencer. J'aimerais trouver (si possible en ligne, sinon en libraire) un
guide pour apprendre. Je décris ce que serait le guide idéal pour moi :
- il serait assez petit pour être lisible, ou (encore mieux) comporterait
une premier chapitre permettant de commencer rapidement avant
d'approfondir. Cela élimine des truc comme l'advanced bash scripting guide.
- il décrirait le shell POSIX, plutôt qu'un shell comme bash ou zsh, plus
pratique sans doute mais moins standard. Ceci élimine aussi la page de man
de mon shell local
- il orienterait dès le début vers un style propre et sûr de codage.
- ce qui serait génial, c'est qu'il parle aussi un peu des outils unix comme
awk, sed, cut, ou que sais-je, ou au moins qu'il mentionne leur existence
et leurs emplois, après je peux lire la page de man.
Si vous connaissez une telle merveille, ou quelque chose d'approchant, vous
avez droit à toute ma reconnaissance :)
The old format $[expression] is deprecated and will be removed in upcoming versions of bash.
Je suppose donc que cette seconde forme n'est pas POSIX (à vérifier).
En tous cas, ça ne passe effectivement pas en dash.
Je corrige ça, merci.
-- Matthieu
Damien Wyart
* mpg in fr.comp.os.unix:
J'ai un peu honte de poser cette question, tellement ça doit être une faq de débutant, mais bon. J'aimerai apprendre un peu à écrire des scripts shell pour automatiser des petits trucs, mais je ne sais pas bien par où commencer. J'aimerais trouver (si possible en ligne, sinon en libraire) un guide pour apprendre. Je décris ce que serait le guide idéal pour moi :
Sinon, comme dit, les O'Reilly sur les scripts et recettes shells sont plus costauds et complets, mais pas gratuits :)
-- DW
* mpg <manuel.pg@free.fr> in fr.comp.os.unix:
J'ai un peu honte de poser cette question, tellement ça doit être une
faq de débutant, mais bon. J'aimerai apprendre un peu à écrire des
scripts shell pour automatiser des petits trucs, mais je ne sais pas
bien par où commencer. J'aimerais trouver (si possible en ligne, sinon
en libraire) un guide pour apprendre. Je décris ce que serait le guide
idéal pour moi :
J'ai un peu honte de poser cette question, tellement ça doit être une faq de débutant, mais bon. J'aimerai apprendre un peu à écrire des scripts shell pour automatiser des petits trucs, mais je ne sais pas bien par où commencer. J'aimerais trouver (si possible en ligne, sinon en libraire) un guide pour apprendre. Je décris ce que serait le guide idéal pour moi :
Sinon, comme dit, les O'Reilly sur les scripts et recettes shells sont plus costauds et complets, mais pas gratuits :)
-- DW
mpg
Vincent Lefevre wrote:
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données: [...] Il faut prendre l'habitude de mettre des quotes!
Oui, alors voilà, c'est typiquement pour ce genre de raisons que je demande
conseil pour une *bonne* référence, parce faire des scripts moyens qui ont l'air de marcher quand j'essaie et qui me feront un sale coup à la première occasion, ça je crois que je peux le faire tout seul, il suffit que j'essaie. (Enfin pour l'instant je sais pas faire, mais je pourrais l'apprendre tout seul...)
En tout cas ça me fait un exemple de truc précis à regarder dans un bouquin pour déjà en éliminer pas mal :)
Manuel.
Vincent Lefevre wrote:
Surtout mauvais. Un de leurs premiers scripts contient une erreur
classique, qui peut mener à des trous de sécurité et des pertes de
données:
[...]
Il faut prendre l'habitude de mettre des quotes!
Oui, alors voilà, c'est typiquement pour ce genre de raisons que je demande
conseil pour une *bonne* référence, parce faire des scripts moyens qui ont
l'air de marcher quand j'essaie et qui me feront un sale coup à la première
occasion, ça je crois que je peux le faire tout seul, il suffit que
j'essaie. (Enfin pour l'instant je sais pas faire, mais je pourrais
l'apprendre tout seul...)
En tout cas ça me fait un exemple de truc précis à regarder dans un bouquin
pour déjà en éliminer pas mal :)
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données: [...] Il faut prendre l'habitude de mettre des quotes!
Oui, alors voilà, c'est typiquement pour ce genre de raisons que je demande
conseil pour une *bonne* référence, parce faire des scripts moyens qui ont l'air de marcher quand j'essaie et qui me feront un sale coup à la première occasion, ça je crois que je peux le faire tout seul, il suffit que j'essaie. (Enfin pour l'instant je sais pas faire, mais je pourrais l'apprendre tout seul...)
En tout cas ça me fait un exemple de truc précis à regarder dans un bouquin pour déjà en éliminer pas mal :)
Manuel.
mpg
Thierry B. wrote:
--{ mpg a plopé ceci: }--
Si vous connaissez une telle merveille, ou quelque chose d'approchant, vous avez droit à toute ma reconnaissance :)
"Introduction aux scripts shell" chez O'Reilly. Je pense que
ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de lire dans un monde idéal, mais pas forcément dans le monde réel. Je regarderai si le premier chapitre "fondements" a l'air suffisant pour commencer et aller ensuite piocher tranquillement les infos dans les autres chapitres, parce tout lire linéairement, j'y crois pas trop.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts sécurisé" ne soit que le dernier chapitre ?
Manuel.
Thierry B. wrote:
--{ mpg a plopé ceci: }--
Si vous connaissez une telle merveille, ou quelque chose d'approchant,
vous avez droit à toute ma reconnaissance :)
"Introduction aux scripts shell" chez O'Reilly. Je pense que
ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de
lire dans un monde idéal, mais pas forcément dans le monde réel. Je
regarderai si le premier chapitre "fondements" a l'air suffisant pour
commencer et aller ensuite piocher tranquillement les infos dans les autres
chapitres, parce tout lire linéairement, j'y crois pas trop.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts
sécurisé" ne soit que le dernier chapitre ?
Si vous connaissez une telle merveille, ou quelque chose d'approchant, vous avez droit à toute ma reconnaissance :)
"Introduction aux scripts shell" chez O'Reilly. Je pense que
ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de lire dans un monde idéal, mais pas forcément dans le monde réel. Je regarderai si le premier chapitre "fondements" a l'air suffisant pour commencer et aller ensuite piocher tranquillement les infos dans les autres chapitres, parce tout lire linéairement, j'y crois pas trop.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts sécurisé" ne soit que le dernier chapitre ?
Manuel.
Matthieu Moy
Vincent Lefevre <vincent+ writes:
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données:
#!/bin/sh # on veut faire un copie de tous les fichiers for i in * ; do # sous le nom *.bak cp $i $i.bak done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte que cette version marchait très bien chez moi, même avec des espaces dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des blancs avant l'expansion des variables :
$ x='a b' $ echo $x a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
-- Matthieu
Vincent Lefevre <vincent+news@vinc17.org> writes:
Surtout mauvais. Un de leurs premiers scripts contient une erreur
classique, qui peut mener à des trous de sécurité et des pertes de
données:
#!/bin/sh
# on veut faire un copie de tous les fichiers
for i in * ; do
# sous le nom *.bak
cp $i $i.bak
done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte
que cette version marchait très bien chez moi, même avec des espaces
dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des
blancs avant l'expansion des variables :
$ x='a b'
$ echo $x
a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement
bizarre ??
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données:
#!/bin/sh # on veut faire un copie de tous les fichiers for i in * ; do # sous le nom *.bak cp $i $i.bak done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte que cette version marchait très bien chez moi, même avec des espaces dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des blancs avant l'expansion des variables :
$ x='a b' $ echo $x a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
-- Matthieu
Nicolas George
Matthieu Moy wrote in message :
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
zsh a un comportement sain, contrairement à la plupart des autres shells.
Matthieu Moy wrote in message <vpqejf2dsuy.fsf@bauges.imag.fr>:
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement
bizarre ??
zsh a un comportement sain, contrairement à la plupart des autres shells.
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
zsh a un comportement sain, contrairement à la plupart des autres shells.
Matthieu Moy
Nicolas George <nicolas$ writes:
Matthieu Moy wrote in message :
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
Vérification faite, c'est bien par défaut dans zsh: (man zshexpn)
Note in particular the fact that words of unquoted parameters are not automatically split on whitespace unless the option SH_WORD_SPLIT is set; see references to this option below for more details. This is an important difference from other shells.
zsh a un comportement sain, contrairement à la plupart des autres shells.
Je trouve effectivement ce comportement « plus sain », mais je suis surpris qu'il casse la compatibilité avec les autres shells POSIX par défaut sur ce point.
-- Matthieu
Nicolas George <nicolas$george@salle-s.org> writes:
Matthieu Moy wrote in message <vpqejf2dsuy.fsf@bauges.imag.fr>:
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement
bizarre ??
Vérification faite, c'est bien par défaut dans zsh: (man zshexpn)
Note in particular the fact that words of unquoted parameters
are not automatically split on whitespace unless the option
SH_WORD_SPLIT is set; see references to this option below for
more details. This is an important difference from other
shells.
zsh a un comportement sain, contrairement à la plupart des autres
shells.
Je trouve effectivement ce comportement « plus sain », mais je suis
surpris qu'il casse la compatibilité avec les autres shells POSIX par
défaut sur ce point.
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
Vérification faite, c'est bien par défaut dans zsh: (man zshexpn)
Note in particular the fact that words of unquoted parameters are not automatically split on whitespace unless the option SH_WORD_SPLIT is set; see references to this option below for more details. This is an important difference from other shells.
zsh a un comportement sain, contrairement à la plupart des autres shells.
Je trouve effectivement ce comportement « plus sain », mais je suis surpris qu'il casse la compatibilité avec les autres shells POSIX par défaut sur ce point.
-- Matthieu
Stephane Chazelas
2007-11-07, 15:37(+01), Matthieu Moy:
Vincent Lefevre <vincent+ writes:
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données:
#!/bin/sh # on veut faire un copie de tous les fichiers for i in * ; do # sous le nom *.bak cp $i $i.bak done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte que cette version marchait très bien chez moi, même avec des espaces dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des blancs avant l'expansion des variables :
$ x='a b' $ echo $x a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
zsh (quand il n'est pas lancé en emulation sh ou ksh) a corrigé un bon nombre des maladresses de sh/ksh.
En zsh, quand on veut du word splitting ou du globbing sur l'expansion des variables (que sh/ksh font implicitement), il faut le demander explicitement.
Le $var de ksh/sh s'ecrit en zsh $~=var
$~var est pour le globbing (p.e. si var='*x*', $~var est expandé en la list des fichiers non-caché dont le nom contient un x).
$=var est pour le word splitting ($= ressemble a des ciseaux).
Note qu'il reste une maladresse que zsh n'a pas resolue a mon avis:
Si $var est vide, son expansion dans
cmd $var
resulte en pas d'argument du tout au lieu d'un argument vide.
Donc, souvent, en zsh, il faut quand-meme quoter ses variables.
En particulier dans [ -z "$var" ]. Sans les quotes, ca ne marche pas.
Note que zsh fait du word splitting (mais pas du globbing) sur l'expansion des command substitutions (et enleve les NL terminaux).
-- Stéphane
2007-11-07, 15:37(+01), Matthieu Moy:
Vincent Lefevre <vincent+news@vinc17.org> writes:
Surtout mauvais. Un de leurs premiers scripts contient une erreur
classique, qui peut mener à des trous de sécurité et des pertes de
données:
#!/bin/sh
# on veut faire un copie de tous les fichiers
for i in * ; do
# sous le nom *.bak
cp $i $i.bak
done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte
que cette version marchait très bien chez moi, même avec des espaces
dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des
blancs avant l'expansion des variables :
$ x='a b'
$ echo $x
a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement
bizarre ??
zsh (quand il n'est pas lancé en emulation sh ou ksh) a corrigé
un bon nombre des maladresses de sh/ksh.
En zsh, quand on veut du word splitting ou du globbing sur
l'expansion des variables (que sh/ksh font implicitement), il
faut le demander explicitement.
Le $var de ksh/sh s'ecrit en zsh $~=var
$~var est pour le globbing (p.e. si var='*x*', $~var est expandé
en la list des fichiers non-caché dont le nom contient un x).
$=var est pour le word splitting ($= ressemble a des ciseaux).
Note qu'il reste une maladresse que zsh n'a pas resolue a mon
avis:
Si $var est vide, son expansion dans
cmd $var
resulte en pas d'argument du tout au lieu d'un argument vide.
Donc, souvent, en zsh, il faut quand-meme quoter ses variables.
En particulier dans [ -z "$var" ]. Sans les quotes, ca ne marche
pas.
Note que zsh fait du word splitting (mais pas du globbing) sur
l'expansion des command substitutions (et enleve les NL
terminaux).
Surtout mauvais. Un de leurs premiers scripts contient une erreur classique, qui peut mener à des trous de sécurité et des pertes de données:
#!/bin/sh # on veut faire un copie de tous les fichiers for i in * ; do # sous le nom *.bak cp $i $i.bak done
Remarque étonnante : en jouant un peu avec ça, je me suis rendu compte que cette version marchait très bien chez moi, même avec des espaces dans les noms de fichiers.
En fait, mon shell est zsh, et il semble faire l'interprétation des blancs avant l'expansion des variables :
$ x='a b' $ echo $x a b
C'est moi qui ai cassé mon zsh, ou c'est zsh qui a un comportement bizarre ??
zsh (quand il n'est pas lancé en emulation sh ou ksh) a corrigé un bon nombre des maladresses de sh/ksh.
En zsh, quand on veut du word splitting ou du globbing sur l'expansion des variables (que sh/ksh font implicitement), il faut le demander explicitement.
Le $var de ksh/sh s'ecrit en zsh $~=var
$~var est pour le globbing (p.e. si var='*x*', $~var est expandé en la list des fichiers non-caché dont le nom contient un x).
$=var est pour le word splitting ($= ressemble a des ciseaux).
Note qu'il reste une maladresse que zsh n'a pas resolue a mon avis:
Si $var est vide, son expansion dans
cmd $var
resulte en pas d'argument du tout au lieu d'un argument vide.
Donc, souvent, en zsh, il faut quand-meme quoter ses variables.
En particulier dans [ -z "$var" ]. Sans les quotes, ca ne marche pas.
Note que zsh fait du word splitting (mais pas du globbing) sur l'expansion des command substitutions (et enleve les NL terminaux).
-- Stéphane
Stephane Chazelas
2007-11-07, 16:21(+01), Matthieu Moy: [...]
zsh a un comportement sain, contrairement à la plupart des autres shells.
Je trouve effectivement ce comportement « plus sain », mais je suis surpris qu'il casse la compatibilité avec les autres shells POSIX par défaut sur ce point.
En mode POSIX, il se comporte POSIXement, donc incorrectement. Donc, si jamais tu voulais faire interpreter ton script POSIX par zsh, tu pourrais.
Mais le reste du temps, au prompt, tu n'es pas obligé de passer ton temps a te tirer dans le pied parce que quelqu'un n'a pas reflechi assez il y a 30 ans au design de son shell.
-- Stéphane
2007-11-07, 16:21(+01), Matthieu Moy:
[...]
zsh a un comportement sain, contrairement à la plupart des autres
shells.
Je trouve effectivement ce comportement « plus sain », mais je suis
surpris qu'il casse la compatibilité avec les autres shells POSIX par
défaut sur ce point.
En mode POSIX, il se comporte POSIXement, donc incorrectement.
Donc, si jamais tu voulais faire interpreter ton script POSIX
par zsh, tu pourrais.
Mais le reste du temps, au prompt, tu n'es pas obligé de passer
ton temps a te tirer dans le pied parce que quelqu'un n'a pas
reflechi assez il y a 30 ans au design de son shell.
zsh a un comportement sain, contrairement à la plupart des autres shells.
Je trouve effectivement ce comportement « plus sain », mais je suis surpris qu'il casse la compatibilité avec les autres shells POSIX par défaut sur ce point.
En mode POSIX, il se comporte POSIXement, donc incorrectement. Donc, si jamais tu voulais faire interpreter ton script POSIX par zsh, tu pourrais.
Mais le reste du temps, au prompt, tu n'es pas obligé de passer ton temps a te tirer dans le pied parce que quelqu'un n'a pas reflechi assez il y a 30 ans au design de son shell.
-- Stéphane
Thierry B.
--{ mpg a plopé ceci: }--
"Introduction aux scripts shell" chez O'Reilly. Je pense que ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de lire dans un monde idéal, mais pas forcément dans le monde réel. Je
Et si tu as besoin d'un recueil de bonnes recettes de cuisine, j'aime bien aussi, toujours chez ORA, "Linux Server Hacks". Bien penser à aller consulter les liens fournis, il y a du bon derrière.
Mon exemplaire date de 2003, et je pense qu'il y a eu quelques mises à jour depuis.
regarderai si le premier chapitre "fondements" a l'air suffisant pour commencer et aller ensuite piocher tranquillement les infos dans les autres chapitres, parce tout lire linéairement, j'y crois pas trop.
Détrompe toi, cette "Introduction..." se survole facilement, et j'ai trouvé les exemples assez pertinents.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts sécurisé" ne soit que le dernier chapitre ?
Je ne sais pas... Peut-être, tout dépend dans quel contexte tu vas utiliser tes scripts. Mais tu peux commencer par lire ce chapitre avant le reste, hein...
-- Divorce d'état: revenus doublés. C'est la France qui avance.
--{ mpg a plopé ceci: }--
"Introduction aux scripts shell" chez O'Reilly. Je pense que
ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de
lire dans un monde idéal, mais pas forcément dans le monde réel. Je
Et si tu as besoin d'un recueil de bonnes recettes de cuisine, j'aime
bien aussi, toujours chez ORA, "Linux Server Hacks". Bien penser à
aller consulter les liens fournis, il y a du bon derrière.
Mon exemplaire date de 2003, et je pense qu'il y a eu quelques mises
à jour depuis.
regarderai si le premier chapitre "fondements" a l'air suffisant pour
commencer et aller ensuite piocher tranquillement les infos dans les autres
chapitres, parce tout lire linéairement, j'y crois pas trop.
Détrompe toi, cette "Introduction..." se survole facilement, et j'ai
trouvé les exemples assez pertinents.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts
sécurisé" ne soit que le dernier chapitre ?
Je ne sais pas... Peut-être, tout dépend dans quel contexte tu vas
utiliser tes scripts. Mais tu peux commencer par lire ce chapitre
avant le reste, hein...
--
Divorce d'état: revenus doublés. C'est la France qui avance.
"Introduction aux scripts shell" chez O'Reilly. Je pense que ça correspond très bien à ta demande.
Il faudra que j'y jette un oeil attentif alors. La dernière fois que j'y ai
regardé, il avait une tête de bouquin de 500 pages que j'aurais le temps de lire dans un monde idéal, mais pas forcément dans le monde réel. Je
Et si tu as besoin d'un recueil de bonnes recettes de cuisine, j'aime bien aussi, toujours chez ORA, "Linux Server Hacks". Bien penser à aller consulter les liens fournis, il y a du bon derrière.
Mon exemplaire date de 2003, et je pense qu'il y a eu quelques mises à jour depuis.
regarderai si le premier chapitre "fondements" a l'air suffisant pour commencer et aller ensuite piocher tranquillement les infos dans les autres chapitres, parce tout lire linéairement, j'y crois pas trop.
Détrompe toi, cette "Introduction..." se survole facilement, et j'ai trouvé les exemples assez pertinents.
Par contre c'est pas un peu mauvais signe que "introduction aux scripts sécurisé" ne soit que le dernier chapitre ?
Je ne sais pas... Peut-être, tout dépend dans quel contexte tu vas utiliser tes scripts. Mais tu peux commencer par lire ce chapitre avant le reste, hein...
-- Divorce d'état: revenus doublés. C'est la France qui avance.
