ah oui, j'ai aussi enlevé un niveau d'indirection sur items dans le memset. Ton memset travaillait juste sur l'entrée i de ton tableau items au lieu de travailler sur le tableau.
et oui, mais ça, ça ne va pas !
ITEM_SIZE_STEP vaut 1, mais tu veux mettre 0 pour un pointeur, qui tient sur plus qu'un seul octet.
ça serait mieux comme ça:
memset(items+i,0,ITEM_SIZE_STEP*sizeof(char**));
tu aurais pu ajouter un log en fin de boucle pour afficher *(items + i), ça t'aurais permis de te rendre compte que memset ne faisait pas ce que tu attendais (en tout cas, c'est comme ça que j'ai fait).
Pour conclure (désolé, je radote :), n'oublie pas de libérer la mémoire allouée par getline.
hmmm faut voir comment il était. Peux-tu poster la version avec memset ?
(sinon, pour info, j'ai fait 2/3 tests avant de poster, j'ai une version qui marche que je pourrais mettre si tu veux, mais je pense que c'est plus intéressant si on réfléchit sur ton code)
pour moi, ce qui caractérise un Fanboy, c'est qu'il pense que le truc dont il est fan est le meilleur dans l'absolu, et que le truc en question répond à tous les besoins que quiconque pourrait avoir en la matière.
Avec la multiplicité/vivacité des différentes distribs Linux, au bout de quelques années, je dirais qu'on est vacciné. On comprend que Ubuntu n'est pas pour le même public que Slack/Arch/Redhat/..., que enlightenment/gnome/kde/... ont chacun des forces et des faiblesses, que Windows c'est très bien pour pleins de gens, que vim c'est mieux et que le Python, c'est bon ... ah mince, une résurgence :)
If *lineptr is NULL, then getline() will allocate a buffer for storing the line, which should be freed by the user program. (In this case, the value in *n is ignored.)
Alternatively, before calling getline(), *lineptr can contain a pointer to a malloc(3)-allo‐cated buffer *n bytes in size. If the buffer is not large enough to hold the line, getline() resizes it with realloc(3), updating *lineptr and *n as necessary.
le problème ici c'est que tu laisses getline faire l'allocation de chaque ligne, mais tu ne t'assures pas que items + i soit bien NULL avant chaque entrée dans getline.
Au passage, il faudrait aussi que tu libères les blocs alloués par getline.
dans le paragraphe "la locomotive" (<- ce Steve Jobs alors, il a même inventé le train !?), sous la photo des iPod de toute génération, le sous paragraphe commence par:
comment ne pas oublier
je serais assez d'accord, mais je pense que c'est un contre sens. Il faudrait plutôt "comment oublier" ou "comment ne pas mentionner". Au passage, on pourrait aussi finir la phrase (à rallonge) par un point d'exclamation.
sinon, à chaque fois que j'utilise un GPS, j'ai une pensée émue pour le fournisseur de stylos d'Albert Einstein.
j'ai eu le temps de l'apercevoir, je l'ai trouvé plus drôle que méchant. Il était évidemment d'un intérêt nul (mais il me semble que c'était assumé :), donc il méritait largement autant d'exister que celui ci.
bizarre, à la lecture, il n'y a rien qui me saute aux yeux.
Si tu es en bash, tu peux ajouter, vers le début de ton script:
set -x
bash passe en mode debug et affiche le déroulement du script.
attention aussi au piège classique, cron démarre les jobs avec /bin/sh
si tu veux utiliser un autre shell, la première ligne du script doit être le chemin vers l'interpréteur. Par exemple, pour bash :
#!/bin/bash
juste pour savoir, tu essaies déjà de mettre ton script en cron ou tu le testes à la main pour l'instant ?
je pense avoir déjà fait des trucs plus complexes que ça ;) il me semble que j'ai compris.
ce que je dis, c'est pour que ton script de watchdog (que tu es en train d'écrire) effectue une action en fonction de l'état du service, il faut que ton script de service dans /etc/init.d/ton_service status renvoie des valeurs différentes selon que le service est démarré ou pas.
donc, pour reformuler ma question, quand ton service est arrété, est-ce que /etc/init.d/ton_service renvoie bien une valeur différente de 0 ?
Vérifie que ton script de démarrage de service renvoie bien quelque chose différent de 0 sur la commande status quand ton service est arrété, sinon, $? vaut toujours 0, et tu ne passes jamais dans le start.
"ça ne fonctionne pas", c'est un peu juste. Prend l'habitude de décrire plus précisément ce qui ne marche pas, les éventuels messages affichés par ton script, etc.
sinon, là, si tu as copié/collé ton script tel quel, il faut que tu rajoutes quelques espaces pour bien séparer les différents éléments du test.
essaie aussi d'indenter ton code, ça le rend plus lisible.
if[$? -ne 0]; then
logguer "Processus ${PS} not started"
start
fi
devient
if[$? -ne 0 ]; thenlogguer "Processus ${PS} not started"
start
fi
je plussoie. Les descriptions dans les offres sont toujours terrifiantes, et pas toujours écrites par des techos. Il me semble avoir vu des offres demandant 5 à 10 ans d'expérience en Java ... au début des années 2000 :)
Est-il possible pour un administrateur réseau de métier, de trouver quelques miettes de temps extra-professionnelles pour développer des compétences autour de la programmation ;
ça dépend de tes objectifs en programmation. Je pense que c'est un plus pour admin sys s'il est capable de coder ses propres outils. Python est un bon choix de langage pour ça (avec Perl, Ruby, le bon vieux shell, et un peu de C à l'occasion). Après, tu n'auras je pense pas le temps de rentrer dans du développement un peu lourd (50000+ lignes de code)
Connaissez vous un bon moyen pour l'autoformation, ou encore des formations non-payantes (ou rémunérées) ;
Le CNAM, c'est payant, mais d'un très bon rapport qualité/prix.
sinon, Internet et des cas d'applications pratiques. Par exemple, se donner un objectif précis, comme d'héberger son propre serveur de mail, un serveur DNS local, un petit serveur web perso dans une DMZ, un serveur d'impression ou stocker sa liste de contact dans un annuaire ldap et configurer son client mail pour s'en servir.
Je suis développeur, pas admin sys, mais je pense que ces quelques exemples de trucs que tu peux faire chez toi, pas particulièrement évidents, peuvent te faire apprendre des montagnes de trucs utiles en environnement professionnel. Attention, ne pas s'éparpiller dans tous les sens. Choisis un objectif, et ne lâche pas l'affaire tant que tu n'es pas satisfait du résultat.
ah désolé, j'avais mal compris ton commentaire initial. A ma décharger, à lire la réponse de patrick_g, j'ai l'impression que je suis pas seul dans ce cas là :)
En traduisant RC en version candidate, la notion de Release est carrément évacuée. En français, "Release Candidate (version)" serait plutôt "version candidate à la libération". Simple petit pinaillage sur les mots, sur le fond, ton explication est juste.
Pour répondre au commentaire grand père, le concept (et le nom) de RC ne sont pas spécifiques à Linux, mais utilisés par pleins de logiciels. En règle générale, leur diffusion est restreinte, vu que ce sont des versions non finales. Hors la visibilité du noyau (et les dépèches de patrick_g !), ça resterait du jargon de gens du métier.
sinon, excellente dépêche comme d'habitude. Les micro interviews sont vraiment une bonne idée.
pour la dernière phrase, peut-être un peu, mais sur le reste non.
J'ai en fait raté d'autres éléments de la phrase que je soulignais, l'implication "plus près de l'expérience humaine" => "potentiellement moins complexe que l'approche procédurale". En dehors du fait que le lien logique ne me parait pas établi, le mot "potentiel" laisse en fait beaucoup de marge d'interprétation.
A mon sens, l'approche objet est une autre façon d'aborder ce qu'on appelait "modularité" auparavant. Évidemment, il n'est pas question de remettre en cause l'intérêt de la modularisation dans la conception et le développement, mais d'interroger l'affirmation selon laquelle la POO serait moins complexe que l'approche procédurale. En fait, la question est de savoir dans quelle mesure le "potentiel" cité ci dessus est réalisé.
Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.
On notera aussi que par rapport au C++ (qui reste un langage emblématique de la POO), Java a supprimé certains concepts et en a simplifié d'autres. Quelles sont les raisons de ces choix conceptuels ? Il me semble que c'était la trop grande complexité de certains concepts, ce qui tendrait à indiquer que l'approche objet est pas si évidente que ça.
L'approche objet est utile, voire même agréable dans certains cas, mais, à mon avis, la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages. Pour le dire autrement, le langage vient dans un second temps et permet l'implémentation plus ou moins rapide de telle ou telle approche, mais n'est pas un élément déterminant : un bon langage ne débouche pas forcément sur des bons programmes, une bonne approche ne fait pas forcément des bons développeurs. (oui, bon, là, j'enfonce un peu des portes ouvertes ... :)
Regarder son contexte professionnel pour répondre à la question est très biaisé, non ?
oui, note que je répondais à ta question, en précisant bien que ça ne faisait pas avancer le débat.
C'est aussi pour ça qu'on discute sur des rapports produits par des organismes sur le sujet et pas à partir de nos appréciations personnelles.
D'ailleurs, je ne vois pas bien comment ça a pu t'échapper, à moins que tu ne fasses que répondre à un commentaire en ayant raté les autres sur le sujet ... ?
[^] # Re: vive le man
Posté par gaaaaaAab . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
ah oui, j'ai aussi enlevé un niveau d'indirection sur items dans le memset. Ton memset travaillait juste sur l'entrée i de ton tableau items au lieu de travailler sur le tableau.
[^] # Re: vive le man
Posté par gaaaaaAab . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
et oui, mais ça, ça ne va pas !
ITEM_SIZE_STEP vaut 1, mais tu veux mettre 0 pour un pointeur, qui tient sur plus qu'un seul octet.
ça serait mieux comme ça:
tu aurais pu ajouter un log en fin de boucle pour afficher *(items + i), ça t'aurais permis de te rendre compte que memset ne faisait pas ce que tu attendais (en tout cas, c'est comme ça que j'ai fait).
Pour conclure (désolé, je radote :), n'oublie pas de libérer la mémoire allouée par getline.
[^] # Re: vive le man
Posté par gaaaaaAab . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
hmmm faut voir comment il était. Peux-tu poster la version avec memset ?
(sinon, pour info, j'ai fait 2/3 tests avant de poster, j'ai une version qui marche que je pourrais mettre si tu veux, mais je pense que c'est plus intéressant si on réfléchit sur ton code)
# fanboy = absolu
Posté par gaaaaaAab . En réponse au journal Suis-je un FanBoy ?. Évalué à 6.
pour moi, ce qui caractérise un Fanboy, c'est qu'il pense que le truc dont il est fan est le meilleur dans l'absolu, et que le truc en question répond à tous les besoins que quiconque pourrait avoir en la matière.
Avec la multiplicité/vivacité des différentes distribs Linux, au bout de quelques années, je dirais qu'on est vacciné. On comprend que Ubuntu n'est pas pour le même public que Slack/Arch/Redhat/..., que enlightenment/gnome/kde/... ont chacun des forces et des faiblesses, que Windows c'est très bien pour pleins de gens, que vim c'est mieux et que le Python, c'est bon ... ah mince, une résurgence :)
[^] # Re: id
Posté par gaaaaaAab . En réponse au message Contrôle de l'utilisateur dans un shell de service. Évalué à 2.
c'est vrai, mais il y a des pièges vicieux avec les variables d'environnement :
# vive le man
Posté par gaaaaaAab . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
man getline:
le problème ici c'est que tu laisses getline faire l'allocation de chaque ligne, mais tu ne t'assures pas que items + i soit bien NULL avant chaque entrée dans getline.
Au passage, il faudrait aussi que tu libères les blocs alloués par getline.
# grammaire
Posté par gaaaaaAab . En réponse à la dépêche Steve Jobs (1955-2011). Évalué à 3.
dans le paragraphe "la locomotive" (<- ce Steve Jobs alors, il a même inventé le train !?), sous la photo des iPod de toute génération, le sous paragraphe commence par:
je serais assez d'accord, mais je pense que c'est un contre sens. Il faudrait plutôt "comment oublier" ou "comment ne pas mentionner". Au passage, on pourrait aussi finir la phrase (à rallonge) par un point d'exclamation.
sinon, à chaque fois que j'utilise un GPS, j'ai une pensée émue pour le fournisseur de stylos d'Albert Einstein.
[^] # Re: Ce commentaire a été supprimé par l'équipe de modération.
Posté par gaaaaaAab . En réponse au journal Décence et respect autour d'un décès. Évalué à 6.
j'ai eu le temps de l'apercevoir, je l'ai trouvé plus drôle que méchant. Il était évidemment d'un intérêt nul (mais il me semble que c'était assumé :), donc il méritait largement autant d'exister que celui ci.
[^] # Re: En résumé…
Posté par gaaaaaAab . En réponse au journal Décence et respect autour d'un décès. Évalué à 7.
franchement, regarde le niveau des réactions que tu cites. Il n'aurait déjà plus du te rester de bras à perdre après les avoir lus ...
[^] # Re: [ est une commande
Posté par gaaaaaAab . En réponse au message Script de controle et de redémarrage de service. Évalué à 2.
tu as du zappé un des espaces dont je parlais là
[^] # Re: [ est une commande
Posté par gaaaaaAab . En réponse au message Script de controle et de redémarrage de service. Évalué à 2.
ça viendra :)
bizarre, à la lecture, il n'y a rien qui me saute aux yeux.
Si tu es en bash, tu peux ajouter, vers le début de ton script:
set -x
bash passe en mode debug et affiche le déroulement du script.
attention aussi au piège classique, cron démarre les jobs avec /bin/sh
si tu veux utiliser un autre shell, la première ligne du script doit être le chemin vers l'interpréteur. Par exemple, pour bash :
juste pour savoir, tu essaies déjà de mettre ton script en cron ou tu le testes à la main pour l'instant ?
[^] # Re: [ est une commande
Posté par gaaaaaAab . En réponse au message Script de controle et de redémarrage de service. Évalué à 2.
je pense avoir déjà fait des trucs plus complexes que ça ;) il me semble que j'ai compris.
ce que je dis, c'est pour que ton script de watchdog (que tu es en train d'écrire) effectue une action en fonction de l'état du service, il faut que ton script de service dans /etc/init.d/ton_service status renvoie des valeurs différentes selon que le service est démarré ou pas.
donc, pour reformuler ma question, quand ton service est arrété, est-ce que /etc/init.d/ton_service renvoie bien une valeur différente de 0 ?
[^] # Re: [ est une commande
Posté par gaaaaaAab . En réponse au message Script de controle et de redémarrage de service. Évalué à 3.
c'est ton script de service dont tu parlais là : http://linuxfr.org/forums/programmationshell/posts/contr%C3%B4le-de-lutilisateur-dans-un-shell-de-service qui t'affiche ça ?
Vérifie que ton script de démarrage de service renvoie bien quelque chose différent de 0 sur la commande status quand ton service est arrété, sinon, $? vaut toujours 0, et tu ne passes jamais dans le start.
# [ est une commande
Posté par gaaaaaAab . En réponse au message Script de controle et de redémarrage de service. Évalué à 3.
"ça ne fonctionne pas", c'est un peu juste. Prend l'habitude de décrire plus précisément ce qui ne marche pas, les éventuels messages affichés par ton script, etc.
sinon, là, si tu as copié/collé ton script tel quel, il faut que tu rajoutes quelques espaces pour bien séparer les différents éléments du test.
essaie aussi d'indenter ton code, ça le rend plus lisible.
devient
[^] # Re: id
Posté par gaaaaaAab . En réponse au message Contrôle de l'utilisateur dans un shell de service. Évalué à 1.
ah oui, pour tout ça, man est ton ami, même si je veux bien admettre que le man de bash (ou autre shell) est un peu touffu :)
[^] # Re: id
Posté par gaaaaaAab . En réponse au message Contrôle de l'utilisateur dans un shell de service. Évalué à 2.
pour lancer la commande cmd en tant que tata quand tu es root,
pour décider si tu lances cmd ou su -c cmd, quelque chose comme:
avec ces quelques briques, tu devrais pouvoir avancer vers (voire atteindre) ton objectif
# id
Posté par gaaaaaAab . En réponse au message Contrôle de l'utilisateur dans un shell de service. Évalué à 2.
avec la commande id, tu peux faire des vérifications sur l'utilisateur
tu peux aussi récupérer l'id/nom du groupe avec -g/-gn
du coup, je ne sais pas si je répond à côté :)
[^] # Re: Les offres d'emploi...
Posté par gaaaaaAab . En réponse au message recette pour obtenir des compétences. Évalué à 1.
ah mince, j'ai formatté ma réponse comme un goret. C'est con, j'étais fier de mon dernier paragraphe :)
[^] # Re: Les offres d'emploi...
Posté par gaaaaaAab . En réponse au message recette pour obtenir des compétences. Évalué à 3.
je plussoie. Les descriptions dans les offres sont toujours terrifiantes, et pas toujours écrites par des techos. Il me semble avoir vu des offres demandant 5 à 10 ans d'expérience en Java ... au début des années 2000 :)
ça dépend de tes objectifs en programmation. Je pense que c'est un plus pour admin sys s'il est capable de coder ses propres outils. Python est un bon choix de langage pour ça (avec Perl, Ruby, le bon vieux shell, et un peu de C à l'occasion). Après, tu n'auras je pense pas le temps de rentrer dans du développement un peu lourd (50000+ lignes de code)
[^] # Re: RC
Posté par gaaaaaAab . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 4.
ah désolé, j'avais mal compris ton commentaire initial. A ma décharger, à lire la réponse de patrick_g, j'ai l'impression que je suis pas seul dans ce cas là :)
[^] # Re: RC
Posté par gaaaaaAab . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 2.
ok merci, pas de regrets alors :)
[^] # Re: RC
Posté par gaaaaaAab . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 4.
'R' comment 'veRsion' bien sûr ;-)
En traduisant RC en version candidate, la notion de Release est carrément évacuée. En français, "Release Candidate (version)" serait plutôt "version candidate à la libération". Simple petit pinaillage sur les mots, sur le fond, ton explication est juste.
Pour répondre au commentaire grand père, le concept (et le nom) de RC ne sont pas spécifiques à Linux, mais utilisés par pleins de logiciels. En règle générale, leur diffusion est restreinte, vu que ce sont des versions non finales. Hors la visibilité du noyau (et les dépèches de patrick_g !), ça resterait du jargon de gens du métier.
sinon, excellente dépêche comme d'habitude. Les micro interviews sont vraiment une bonne idée.
Juste un petit regret, https://lwn.net/Articles/452117/ n'est pas en accès libre.
[^] # Re: heu ...
Posté par gaaaaaAab . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
pour la dernière phrase, peut-être un peu, mais sur le reste non.
J'ai en fait raté d'autres éléments de la phrase que je soulignais, l'implication "plus près de l'expérience humaine" => "potentiellement moins complexe que l'approche procédurale". En dehors du fait que le lien logique ne me parait pas établi, le mot "potentiel" laisse en fait beaucoup de marge d'interprétation.
A mon sens, l'approche objet est une autre façon d'aborder ce qu'on appelait "modularité" auparavant. Évidemment, il n'est pas question de remettre en cause l'intérêt de la modularisation dans la conception et le développement, mais d'interroger l'affirmation selon laquelle la POO serait moins complexe que l'approche procédurale. En fait, la question est de savoir dans quelle mesure le "potentiel" cité ci dessus est réalisé.
Franchement, au vu des questions fleurissant dans les forums sur les problématiques purement objet, il me semble qu'on peut se poser la question.
On notera aussi que par rapport au C++ (qui reste un langage emblématique de la POO), Java a supprimé certains concepts et en a simplifié d'autres. Quelles sont les raisons de ces choix conceptuels ? Il me semble que c'était la trop grande complexité de certains concepts, ce qui tendrait à indiquer que l'approche objet est pas si évidente que ça.
L'approche objet est utile, voire même agréable dans certains cas, mais, à mon avis, la qualité de l'architecture du code et de la modélisation de structures/base de données/objets dépendent plus des qualités d'abstractions des concepteurs/développeurs que des facilités des différents langages. Pour le dire autrement, le langage vient dans un second temps et permet l'implémentation plus ou moins rapide de telle ou telle approche, mais n'est pas un élément déterminant : un bon langage ne débouche pas forcément sur des bons programmes, une bonne approche ne fait pas forcément des bons développeurs. (oui, bon, là, j'enfonce un peu des portes ouvertes ... :)
[^] # Re: Suivons la procedure
Posté par gaaaaaAab . En réponse au journal À quoi servent les fichiers hosts et comment les supprimer sous linux ?. Évalué à 2.
oui, note que je répondais à ta question, en précisant bien que ça ne faisait pas avancer le débat.
C'est aussi pour ça qu'on discute sur des rapports produits par des organismes sur le sujet et pas à partir de nos appréciations personnelles.
D'ailleurs, je ne vois pas bien comment ça a pu t'échapper, à moins que tu ne fasses que répondre à un commentaire en ayant raté les autres sur le sujet ... ?
[^] # Re: Chacun son style
Posté par gaaaaaAab . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
c'est clair que faire du java toute la journée, ça fait pas rêver ... (troll inside :)