utiliser xargs sur un input qui n'a pas ete mis au bon format.
utiliser echo.
utiliser une boucle while read, utiliser read sans -r et sans changer IFS.
variable non-quotee, pas de -- pour separer options des arguments.
Franchement, là, ça tiens de la paranoïa !
Un point en paticulier, ou l'ensemble ? Personnellement, ça me semble plutôt rigoureux.
--drkm
Stephane Chazelas
2004-12-20, 23:33(+01), Etienne de Tocqueville:
Stephane Chazelas a écrit sur fr.comp.os.unix :
postprocesser ls (dans l'absolu)
utiliser xargs sur un input qui n'a pas ete mis au bon format.
utiliser echo.
utiliser une boucle while read, utiliser read sans -r et sans changer IFS.
variable non-quotee, pas de -- pour separer options des arguments.
Franchement, là, ça tiens de la paranoïa !
Rien a voir avec de la paranoia, je parle de correctness.
read sans -r et sans changer IFS lit une liste de mots (generalement, de l'utilisateur) en enlevant les blancs au debut et a la fin, en donnant la possibilité d'echapper le separateur par un backslash ou de continuer la phrase sur une nouvelle ligne quant on depasse de l'ecran.
Il est normal que pour lire une ligne brute d'input, ce soit une autre syntaxe (IFS= read -r line), ce n'est pas de la paranoia, c'est connaitre la syntaxe (je le reconnais, ici absconce) du language de programmation que l'on utilise.
Meme chose pour echo. Ses arguments (enfin, pour la plupart des echo), c'est une chaine de characteres ou par exemple "n" represente le character <NL>. Donc, si on veut afficher chaque caractere litteralement, on ne doit pas l'utiliser.
ls "$var"
et "$var" peut etre aussi bien une option qu'un fichier.
Si on veut consider un shell comme un language de programmation, il faut assumer et faire avec sa syntaxe a la con.
-- Stephane
2004-12-20, 23:33(+01), Etienne de Tocqueville:
Stephane Chazelas <cette.adresse@est.invalid> a écrit sur fr.comp.os.unix :
postprocesser ls (dans l'absolu)
utiliser xargs sur un input qui n'a pas ete mis au bon format.
utiliser echo.
utiliser une boucle while read, utiliser read sans -r et sans
changer IFS.
variable non-quotee, pas de -- pour separer options des
arguments.
Franchement, là, ça tiens de la paranoïa !
Rien a voir avec de la paranoia, je parle de correctness.
read sans -r et sans changer IFS lit une liste de mots
(generalement, de l'utilisateur) en enlevant les blancs au debut
et a la fin, en donnant la possibilité d'echapper le separateur
par un backslash ou de continuer la phrase sur une nouvelle
ligne quant on depasse de l'ecran.
Il est normal que pour lire une ligne brute d'input, ce soit une
autre syntaxe (IFS= read -r line), ce n'est pas de la paranoia,
c'est connaitre la syntaxe (je le reconnais, ici absconce) du language
de programmation que l'on utilise.
Meme chose pour echo. Ses arguments (enfin, pour la plupart des
echo), c'est une chaine de characteres ou par exemple "n"
represente le character <NL>. Donc, si on veut afficher chaque
caractere litteralement, on ne doit pas l'utiliser.
ls "$var"
et "$var" peut etre aussi bien une option qu'un fichier.
Si on veut consider un shell comme un language de programmation,
il faut assumer et faire avec sa syntaxe a la con.
utiliser xargs sur un input qui n'a pas ete mis au bon format.
utiliser echo.
utiliser une boucle while read, utiliser read sans -r et sans changer IFS.
variable non-quotee, pas de -- pour separer options des arguments.
Franchement, là, ça tiens de la paranoïa !
Rien a voir avec de la paranoia, je parle de correctness.
read sans -r et sans changer IFS lit une liste de mots (generalement, de l'utilisateur) en enlevant les blancs au debut et a la fin, en donnant la possibilité d'echapper le separateur par un backslash ou de continuer la phrase sur une nouvelle ligne quant on depasse de l'ecran.
Il est normal que pour lire une ligne brute d'input, ce soit une autre syntaxe (IFS= read -r line), ce n'est pas de la paranoia, c'est connaitre la syntaxe (je le reconnais, ici absconce) du language de programmation que l'on utilise.
Meme chose pour echo. Ses arguments (enfin, pour la plupart des echo), c'est une chaine de characteres ou par exemple "n" represente le character <NL>. Donc, si on veut afficher chaque caractere litteralement, on ne doit pas l'utiliser.
ls "$var"
et "$var" peut etre aussi bien une option qu'un fichier.
Si on veut consider un shell comme un language de programmation, il faut assumer et faire avec sa syntaxe a la con.
-- Stephane
Pascal Bourguignon
Stephane Chazelas writes:
Si on veut consider un shell comme un language de programmation, il faut assumer et faire avec sa syntaxe a la con.
Ou autrement dit, si on veut programmer un script, oublier le shell et passer à Common Lisp ! (ou à la limite, scsh).
There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him. -- Robert Heinlein
drkm
Etienne de Tocqueville <et+ writes:
drkm writes:
Franchement, là, ça tiens de la paranoïa !
Un point en paticulier, ou l'ensemble ?
L'ensemble, les 5 points...
Personnellement, ça me semble plutôt rigoureux.
Oh oui, très rigoureux... et paranoïaque ! ;-)
Mais bon, après, ça dépends bien sur de si on programme un script qui sera diffusé dans des distribution à des milliers d'utilisateurs, ou si c'est juste un petit script pour soit qu'on compte utiliser une 10ène de fois
Bof. Une dizaine d'exécutions d'un script peut déjà provoquer pas mal de dégats. J'ai déjà eu assez de (mauvaises) surprises avec de « petits scripts à usage unique » développés trop vite, et de manière trop peu rigoureuse.
Je pense que l'investissement dépensé en essayant d'éviter les pièges mêmes subtiles est rentable à moyen terme. Bien sûr, sur un unique script, ça ne l'est pas des masses. Mais si tu comptes écrire plus d'un script, autant prendre les bonnes habitudes. Une fois acquises, elles ne prennent pas plus de temps à être mises en place que les mauvaises (je parle du temps d'écriture du script, pas du temps consacré à la réparation des dégats).
--drkm
Etienne de Tocqueville <et+news@steph.teaser.fr> writes:
drkm <usenet@fgeorges.org> writes:
Franchement, là, ça tiens de la paranoïa !
Un point en paticulier, ou l'ensemble ?
L'ensemble, les 5 points...
Personnellement, ça me semble plutôt rigoureux.
Oh oui, très rigoureux... et paranoïaque ! ;-)
Mais bon, après, ça dépends bien sur de si on programme un script qui
sera diffusé dans des distribution à des milliers d'utilisateurs, ou si
c'est juste un petit script pour soit qu'on compte utiliser une 10ène de
fois
Bof. Une dizaine d'exécutions d'un script peut déjà provoquer pas
mal de dégats. J'ai déjà eu assez de (mauvaises) surprises avec de
« petits scripts à usage unique » développés trop vite, et de manière
trop peu rigoureuse.
Je pense que l'investissement dépensé en essayant d'éviter les
pièges mêmes subtiles est rentable à moyen terme. Bien sûr, sur un
unique script, ça ne l'est pas des masses. Mais si tu comptes écrire
plus d'un script, autant prendre les bonnes habitudes. Une fois
acquises, elles ne prennent pas plus de temps à être mises en place
que les mauvaises (je parle du temps d'écriture du script, pas du
temps consacré à la réparation des dégats).
Mais bon, après, ça dépends bien sur de si on programme un script qui sera diffusé dans des distribution à des milliers d'utilisateurs, ou si c'est juste un petit script pour soit qu'on compte utiliser une 10ène de fois
Bof. Une dizaine d'exécutions d'un script peut déjà provoquer pas mal de dégats. J'ai déjà eu assez de (mauvaises) surprises avec de « petits scripts à usage unique » développés trop vite, et de manière trop peu rigoureuse.
Je pense que l'investissement dépensé en essayant d'éviter les pièges mêmes subtiles est rentable à moyen terme. Bien sûr, sur un unique script, ça ne l'est pas des masses. Mais si tu comptes écrire plus d'un script, autant prendre les bonnes habitudes. Une fois acquises, elles ne prennent pas plus de temps à être mises en place que les mauvaises (je parle du temps d'écriture du script, pas du temps consacré à la réparation des dégats).
