Si trois commentaire et un case c'est trop compliqué, du javadoc c'est quoi, l'himalaya …
C'est vrai que je n'ai jamais pris le temps de voir ce qui lui manquait, donc quelque part, c'est de ma faute, mais j'ai mis ce point pour souligner que ça n'est pas "3 lignes de script" mais plus que ça ! Et aussi que ça n'est pas si trivial que ça, avec des parties non cohérentes (entête non interprété par le shell dans un script shell)
Dans un sens je comprend.
De l'autre coté, le javadoc il est utilisé par les ide java pour stocker des métadonnées dans le code ?
Là tu as des métadonnées dans des commentaires dans un script shell.
le shell pour l'execution du service (stop/start/status/…) proprement dis, les commentaires pour les métadonnées (quel fonction fait quoi, le script doit se lancer quand, …)
Oui c'est un peu particulier, mais pas tant que ça, et ça se retrouve autre part.
Si j'avais pu faire démarrer mon utilitaire sans avoir à ajouter un script, je l'aurais fait avec plaisir. C'est le système qui me force à cela.
Non, c'est ta méconnaissance du système :
- /etc/inittab
- /etc/rc.local
…
Moi j'aurais aimé un outil avec une syntaxe du genre :
utiliser un outil quand un éditeur de texte suffit, ou comment se compliquer la vie.
La complexité pour ces choses ne devrait pas être dans les script, mais dans l'init.
Ca tombe bien ce sont des scripts d'init.
Si tu veux tu peux avoir des scripts "startup.sh" et "shutdown.sh" et avoir un script de démarrage générique.
Ne t'en déplaise : le système d'init est simple. Les scripts d'init sont simples.
Par contre, le système d'init doit s'adapter à tout.
Tu as le choix de faire une grosse usine a gaz, que tu sera obligé de mettre à jour tout le temps pour s'adapter à toutes les façons possible et imaginable de lancer un service ou un script.
Ca c'est le principe "télécom" au niveau réseau : l'intelligence au coeur du réseau (ton init), et des terminaux complètement idiots (scripts de démarrage)
le principe de linux, c'est le principe inverse (et c'est aussi le principe d'internet) :
un réseau "idiot" (init) et des terminaux intelligents (scripts).
On a vu quel architecture est la plus dynamique et la plus scalable.
alors oui ca demande un poil de motivation, mais honnêtement 2 arguments et trois commentaires, j'ai déjà eu plus de propblème.
Perso je suis sur un petit dev, et il faut comprendre le fonctionnement interne du co processeur etc…
Autrement plus compliqué que de voir 3 commentaires et 2 cases.
[^] # Re: Trop d'honneurs...
Posté par briaeros007 . En réponse au journal yet another journal about systemd. Évalué à -2.
Si trois commentaire et un case c'est trop compliqué, du javadoc c'est quoi, l'himalaya …
Dans un sens je comprend.
De l'autre coté, le javadoc il est utilisé par les ide java pour stocker des métadonnées dans le code ?
Là tu as des métadonnées dans des commentaires dans un script shell.
le shell pour l'execution du service (stop/start/status/…) proprement dis, les commentaires pour les métadonnées (quel fonction fait quoi, le script doit se lancer quand, …)
Oui c'est un peu particulier, mais pas tant que ça, et ça se retrouve autre part.
Non, c'est ta méconnaissance du système :
- /etc/inittab
- /etc/rc.local
…
utiliser un outil quand un éditeur de texte suffit, ou comment se compliquer la vie.
Ca tombe bien ce sont des scripts d'init.
Si tu veux tu peux avoir des scripts "startup.sh" et "shutdown.sh" et avoir un script de démarrage générique.
Ne t'en déplaise : le système d'init est simple. Les scripts d'init sont simples.
Par contre, le système d'init doit s'adapter à tout.
Tu as le choix de faire une grosse usine a gaz, que tu sera obligé de mettre à jour tout le temps pour s'adapter à toutes les façons possible et imaginable de lancer un service ou un script.
Ca c'est le principe "télécom" au niveau réseau : l'intelligence au coeur du réseau (ton init), et des terminaux complètement idiots (scripts de démarrage)
le principe de linux, c'est le principe inverse (et c'est aussi le principe d'internet) :
un réseau "idiot" (init) et des terminaux intelligents (scripts).
On a vu quel architecture est la plus dynamique et la plus scalable.
alors oui ca demande un poil de motivation, mais honnêtement 2 arguments et trois commentaires, j'ai déjà eu plus de propblème.
Perso je suis sur un petit dev, et il faut comprendre le fonctionnement interne du co processeur etc…
Autrement plus compliqué que de voir 3 commentaires et 2 cases.