Optimisation du script shell
Fermé
aminam21
Messages postés
2
Date d'inscription
samedi 11 décembre 2010
Statut
Membre
Dernière intervention
26 mai 2011
-
25 mai 2011 à 21:44
mamiemando Messages postés 33361 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 15 novembre 2024 - 28 mai 2011 à 13:02
mamiemando Messages postés 33361 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 15 novembre 2024 - 28 mai 2011 à 13:02
A voir également:
- Optimisation du script shell
- Script vidéo youtube - Guide
- Optimisation pc - Accueil - Utilitaires
- Classic shell windows 11 - Télécharger - Personnalisation
- Optimisation découpe panneau gratuit - Télécharger - Outils professionnels
- Optimisation windows 10 - Guide
2 réponses
mamiemando
Messages postés
33361
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
15 novembre 2024
7 799
26 mai 2011 à 08:57
26 mai 2011 à 08:57
Qu'entends-tu par optimiser un script shell ? C'est un langage interprété donc lent (par exemple par rapport à du C). À part avoir une structure algorithmique bien écrite (éviter d'imbriquer 3 boucles quand 1 suffit....) et utiliser autant que possible des | quand ça permet d'éviter une boucle, il n'y a pas grand chose à dire.
Et pour la sécurisation je ne vois pas trop non plus. Finalement les commandes shell que tu invoques sont soumises aux mêmes droits que les commandes que tu tapes dans un shell donc... Il faut juste faire gaffe si tu ton script a un bit suid a faire attention aux paramètres reçus par ton script shell et vérifier qu'ils ne vont pas avoir un effet de bord imprevu.
https://en.wikipedia.org/wiki/Code_injection#Shell_injection
Enfin si tu lances des transferts de fichiers entre deux machines, autant utiliser le plus possible ssh (scp) pour chiffrer les données qui circulent mais ce n'est pas réservé au shell.
Bonne chance
Et pour la sécurisation je ne vois pas trop non plus. Finalement les commandes shell que tu invoques sont soumises aux mêmes droits que les commandes que tu tapes dans un shell donc... Il faut juste faire gaffe si tu ton script a un bit suid a faire attention aux paramètres reçus par ton script shell et vérifier qu'ils ne vont pas avoir un effet de bord imprevu.
https://en.wikipedia.org/wiki/Code_injection#Shell_injection
Enfin si tu lances des transferts de fichiers entre deux machines, autant utiliser le plus possible ssh (scp) pour chiffrer les données qui circulent mais ce n'est pas réservé au shell.
Bonne chance
aminam21
Messages postés
2
Date d'inscription
samedi 11 décembre 2010
Statut
Membre
Dernière intervention
26 mai 2011
26 mai 2011 à 22:04
26 mai 2011 à 22:04
bonsoir mamiemando
merci pour le lien du "shell injection" je le trouve très intéressant
pour l'optimisation du script shell regardes par exple ce lien http://www.thelinuxblog.com/optimizing-shell-scripts/
mais en fait il est insuffisant pour ma recherche
merci pour le lien du "shell injection" je le trouve très intéressant
pour l'optimisation du script shell regardes par exple ce lien http://www.thelinuxblog.com/optimizing-shell-scripts/
mais en fait il est insuffisant pour ma recherche
lami20j
Messages postés
21331
Date d'inscription
jeudi 4 novembre 2004
Statut
Modérateur, Contributeur sécurité
Dernière intervention
30 octobre 2019
3 569
26 mai 2011 à 22:16
26 mai 2011 à 22:16
Salut,
pour l'optimisation du script shell regardes par exple ce lien
Ce lien ne montre pas l'optimisation des scripts shell mais plutôt quelque chose de genre "la bonne manière d'utiliser le shell" avec les commandes adaptées pour la meilleure tâche, la syntaxe à utiliser, etc
mais en fait il est insuffisant pour ma recherche
Si tu veux optimiser alors tu n'as qu'à optimiser le shell lui même.
Tu prends le code source et tu commences à coder ;-)
Avant de te lancer dans tes recherches, il faut commencer par lire la documentation des shells, étudier les commandes, comprendre le système sur lequel les scripts sont exécutés, etc.
Ensuite, après tout ça, tu verras que les choses deviendront plus claires ou pas ;-)
pour l'optimisation du script shell regardes par exple ce lien
Ce lien ne montre pas l'optimisation des scripts shell mais plutôt quelque chose de genre "la bonne manière d'utiliser le shell" avec les commandes adaptées pour la meilleure tâche, la syntaxe à utiliser, etc
mais en fait il est insuffisant pour ma recherche
Si tu veux optimiser alors tu n'as qu'à optimiser le shell lui même.
Tu prends le code source et tu commences à coder ;-)
Avant de te lancer dans tes recherches, il faut commencer par lire la documentation des shells, étudier les commandes, comprendre le système sur lequel les scripts sont exécutés, etc.
Ensuite, après tout ça, tu verras que les choses deviendront plus claires ou pas ;-)
mamiemando
Messages postés
33361
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
15 novembre 2024
7 799
28 mai 2011 à 13:02
28 mai 2011 à 13:02
Je pense que pour "l'optimisation" lami20j a mis le doigt sur le coeur du problème.
Le shell est fondamentalement un langage lent car c'est un langage interprété. Et je doute que le "moteur" shell soit vraiment optimisable. De plus ça aurait peu d'intérêt.
Ce qui fait qu'un script shell est performant invoque des commandes écrites souvent en langage C qui lui est très performant. Des mécanismes comme les tubes (pipes) | permettent de réduire la présence de l'algorithmie shell (par exemple en faisant une boucle et / ou en passant par un fichier intermédiaire) qui dégraderait les performances.
Remarques indépendantes du langage :
Pour finir sur l'optimisation :
- les opérations en lecture/écriture sur un fichier dégradent les performances, donc quand on peut éviter c'est mieux ;
- la complexité d'un algorithme (ce qui revient à estimer le nombre d'itérations) doit être aussi faible que possible afin que le programme passe à l'échelle. Concrètement cela revient à essayer d'imbriquer trop de boucles les unes dans les autres.
Exemple : je veux dessiner un carré de n étoiles sur n étoiles
* Méthode 1 :
Complexité : n^2 car on fait n itérations dans un bloc répété n fois n * n = n^2.
* Méthode 2
Complexité : un bloc répété n fois suivi d'un autre, soit une complexité n + n = 2*n. Dans la théorie de la complexité on vire les facteurs car quand n est très grand, n^2 devient bien plus important que 2*n.
Conclusion : le second algorithme est plus performant. Mais il nécessite de garder en mémoire la chaîne s (qui contient n étoiles consécutives). Améliorer la complexité d'un algorithme "coûte" souvent de la mémoire (ou alors ça veut dire que la première version était mal codée !) et donc parfois il faut faire des choix.
Le shell est fondamentalement un langage lent car c'est un langage interprété. Et je doute que le "moteur" shell soit vraiment optimisable. De plus ça aurait peu d'intérêt.
Ce qui fait qu'un script shell est performant invoque des commandes écrites souvent en langage C qui lui est très performant. Des mécanismes comme les tubes (pipes) | permettent de réduire la présence de l'algorithmie shell (par exemple en faisant une boucle et / ou en passant par un fichier intermédiaire) qui dégraderait les performances.
Remarques indépendantes du langage :
Pour finir sur l'optimisation :
- les opérations en lecture/écriture sur un fichier dégradent les performances, donc quand on peut éviter c'est mieux ;
- la complexité d'un algorithme (ce qui revient à estimer le nombre d'itérations) doit être aussi faible que possible afin que le programme passe à l'échelle. Concrètement cela revient à essayer d'imbriquer trop de boucles les unes dans les autres.
Exemple : je veux dessiner un carré de n étoiles sur n étoiles
* Méthode 1 :
Pour ligne = 1 à n
Pour colonne = 1 à n
Ecrire *
Fin pour
Passer à la ligne
Fin pour
Complexité : n^2 car on fait n itérations dans un bloc répété n fois n * n = n^2.
* Méthode 2
chaine = '';
Pour colonne = 1 à n
chaine = chaine + *
Fin pour
Pour ligne = 1 à n
Ecrire chaine
Passer à la ligne
Fin pour
Complexité : un bloc répété n fois suivi d'un autre, soit une complexité n + n = 2*n. Dans la théorie de la complexité on vire les facteurs car quand n est très grand, n^2 devient bien plus important que 2*n.
Conclusion : le second algorithme est plus performant. Mais il nécessite de garder en mémoire la chaîne s (qui contient n étoiles consécutives). Améliorer la complexité d'un algorithme "coûte" souvent de la mémoire (ou alors ça veut dire que la première version était mal codée !) et donc parfois il faut faire des choix.
