Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Oui mais généralement il appellent quand même des fonctions shell au final, comme tu le faisais remarquer. Et pour peu qu'on sache un peu lire du code, même si on ne comprend pas les fonctions shell appelées, on arrive généralement à recomposer le script avec un minimum d'effort.
Avec une forte intégration POSIX au millieu, ca devient beaucoup plus complexe. Déjà il faut passer par l'étape programmation pour immiter le comportement, et ensuite il faut comprendre véritablement ce qui se passe sous peine de se ramasser à l'execution.
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Sur un script perl imbitable, ou sur un script python imbitable on arrive toujours à savoir ce qui se passe en remplaçant une execution shell par un echo vers fichier. C'est long et casse pied, mais pas à pas on finit par avoir la liste des commandes que le script veut passer.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
STOP. Le projet consiste à mettre dans le système de base NetBSD un iterpreteur LUA avec une forte intégration au système POSIX sous jacent. C'est pas une hypothèse que je fais sur un coup de tête, c'est le but du projet.
Les exemples donnés par le créateur du projet sont la refonte du système d'install, la modification des scripts d'init et le changement d'option du client DHCP. J'invente rien, c'est écrit noir sur blanc dans les deux liens donnés dans le journal.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Si le système d'install et les scripts d'init passent en LUA, ce qui une fois de plus est le but annoncé du projet, je ne vois pas comment je pourrais me passer d'apprendre LUA pour pouvoir mettre les mains dans le camboui. Or il se trouve que mettre les mains dans le camboui c'est mon métier.
Quels points forts?
Le monde Unix effectue traditionellement la séparation des droits au niveau fichier, le monde windows le fait au niveau interface.
Dans les deux cas il y a des avantages et des défauts.
Sous Unix le défaut est que pour faire fonctionner un système complexe il faut donner des droits dans tous les sens, avec des serveurs qui se lancent en root puis abandonnent progressivement leurs privilèges.
Sous windows le défaut est que pour faire fonctionner un système complexe il faut installer et lier whatdouzemille framework même si au final on se sert de 10% des possibilités des frameworks concernés.
Sous Unix l'avantage est que les configs, scripts et autre conneries sont déplaceables et maléables à volonté. Une fois qu'on a une config qui marche, on a la quasi certitude qu'elle va marcher sous tout un tas de système raisonnablement posix. Et on peut le déplacer de droite à gauche sans trop de soucis.
Sous windows l'avantage est l'intégration. Vu qu'on ramasse tout un bloc de fonctions d'un coup on a au moins la certitude qu'on ne va pas avoir à se retourner le crane si un jour on a besoin d'ajouter ou d'enlever une fonctionnalité.Et au moins on a pas à se prendre la tête pour savoir comment tout çà va dialoguer ensemble.
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
Oui. Enfin bon faut pas dire çà aux banques, assurances, instituts de recherche et autres systèmes experts.
[^] # Re: Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 3.
Oui mais généralement il appellent quand même des fonctions shell au final, comme tu le faisais remarquer. Et pour peu qu'on sache un peu lire du code, même si on ne comprend pas les fonctions shell appelées, on arrive généralement à recomposer le script avec un minimum d'effort.
Avec une forte intégration POSIX au millieu, ca devient beaucoup plus complexe. Déjà il faut passer par l'étape programmation pour immiter le comportement, et ensuite il faut comprendre véritablement ce qui se passe sous peine de se ramasser à l'execution.
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Sur un script perl imbitable, ou sur un script python imbitable on arrive toujours à savoir ce qui se passe en remplaçant une execution shell par un echo vers fichier. C'est long et casse pied, mais pas à pas on finit par avoir la liste des commandes que le script veut passer.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
STOP. Le projet consiste à mettre dans le système de base NetBSD un iterpreteur LUA avec une forte intégration au système POSIX sous jacent. C'est pas une hypothèse que je fais sur un coup de tête, c'est le but du projet.
Les exemples donnés par le créateur du projet sont la refonte du système d'install, la modification des scripts d'init et le changement d'option du client DHCP. J'invente rien, c'est écrit noir sur blanc dans les deux liens donnés dans le journal.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Si le système d'install et les scripts d'init passent en LUA, ce qui une fois de plus est le but annoncé du projet, je ne vois pas comment je pourrais me passer d'apprendre LUA pour pouvoir mettre les mains dans le camboui. Or il se trouve que mettre les mains dans le camboui c'est mon métier.
Quels points forts?
Le monde Unix effectue traditionellement la séparation des droits au niveau fichier, le monde windows le fait au niveau interface.
Dans les deux cas il y a des avantages et des défauts.
Sous Unix le défaut est que pour faire fonctionner un système complexe il faut donner des droits dans tous les sens, avec des serveurs qui se lancent en root puis abandonnent progressivement leurs privilèges.
Sous windows le défaut est que pour faire fonctionner un système complexe il faut installer et lier whatdouzemille framework même si au final on se sert de 10% des possibilités des frameworks concernés.
Sous Unix l'avantage est que les configs, scripts et autre conneries sont déplaceables et maléables à volonté. Une fois qu'on a une config qui marche, on a la quasi certitude qu'elle va marcher sous tout un tas de système raisonnablement posix. Et on peut le déplacer de droite à gauche sans trop de soucis.
Sous windows l'avantage est l'intégration. Vu qu'on ramasse tout un bloc de fonctions d'un coup on a au moins la certitude qu'on ne va pas avoir à se retourner le crane si un jour on a besoin d'ajouter ou d'enlever une fonctionnalité.Et au moins on a pas à se prendre la tête pour savoir comment tout çà va dialoguer ensemble.
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
Oui. Enfin bon faut pas dire çà aux banques, assurances, instituts de recherche et autres systèmes experts.