benja a écrit 1211 commentaires

• j'ai l'impression que le deuxième while() n'est pas dans le corps d'un fonction, erreur de copier/coller ?
• pour le premier while, je te conseille de toujours mettre son corps sur sa propre ligne (surtout si le corps est vide, i.e. dans le cas d'un simple ';'), voir de l'encadrer d'accolades : cela rend ton code plus clair et évite de commettre une erreur par inadvertance.
• sizeof(char) != sizeof(pointeur) sauf si tu travailles avec une abi qui n'a que 256 octets d'adressage mémoire, ce qui me semble incompatible avec l'utilisation même du C/libc. Bref tu as un gros dépassement de tampon là !
• tu ne free() pas ton malloc dans tous les chemins d'exécutions -> memory leak. (en C, le seul raii qui existe, c'est 'exit(2)' :p).
• sinon qu'est-ce qui ne marche pas, spécifiquement ?

PS: En recherche d'inspiration ou d'une bonne lecture sur l'oreiller ? Je vous conseille les /usr/src/build.sh, /etc/rc.subr et autres /usr/src/Makefile.inc* (tant qu'à faire..) de NetBSD et FreeBSD. Vous me remercierez ensuite (ou pas…).

J'aurais envie de répondre que non mais ça serait un peu malhonnête; je préfère encore me faire taxer d'avoir une double personnalité :D

Pour enfoncer un peu le troll^Wclou, je vais ajouter que le principal problème du shell c'est qu'il est trop simple d'accès et à la fois trop compliqué à utiliser correctement. Un peu comme javascript quoi… Omni-présent, ayant des défauts (mal/méconnus), mais surtout, ils sont utilisés n'importe comment et par n'importe qui!

Il est vrai que je connais pas trop bien perl pour pouvoir le juger et puis quand je l'utilise j'essaye de faire les trucs les plus simples et correctes possible. Et connaissant mes limites, j'essaye à ne jamais avoir à modifier un script de quelqu'un d'autre ! (La fois où j'ai du faire cela, et encore c'était quelque chose de relativement trivial, j'ai quand même tout réécrit).

Par contre, quand j'utilise shell, j'aimes bien l'utiliser au maximum de ses capacités, et, malgré qu'elles soient très réduites, cela permet de faire des choses élégantes, parfois. Donc bref, pour répondre à Kerro, je ne code pas pour me faire relire par des incompétents… :-) C'est valable pour tout les languages. Va-t-on demander à un Chinois s'il trouve que son écriture est illisible ?

Par exemple, je trouve plus élégant de faire

debug=${cond:+echo}
: ${debug=:} # $debug vaut 'echo' ou ':'

$debug "Hello"
$debug "World!"

que

debug=${cond:+true}
: ${debug=false}
$debug || echo "Bonjour"
$debug || echo "Monde!"

Ou encore pire encore, un gros if qui te prend déja 15 lignes rien que pour mettre une valeur à "true" ou "false". Après, les goûts, …

Si true et false n’étaient pas des commandes (ou qu’on utilisait à la place 0 et 1, oui et non…), il faudrait des tests plus lourds du style :

Comme je l'ai montré plus haut, pas besoin de if, true ou &&/|| pour faire une exécution conditionnelle en shell. Il suffit des opérateurs de substitutions !

# commande a exécuter que si la variable COND est nulle ou vide
${COND:+:} ${COND:-commande}
# et inversement, à n'exécuter que si COND n'est ni nulle ni vide
${COND:+commande}

On peut donc très bien se passer de 'test' en utilisant les substitutions par commandes expr, sed, ls, readlink (bon ok là on pousse un peu) et les substitutions sur motifs (${var%motif} et autres) … :-)

Dans l'autre exemple que j'ai montré, utilisé à bon escient ça peut être plus lisible, je trouve (tm)

Notez qu'on peut faire encore plus concis:

COMPRESS_bz=bzip2
COMPRESS_gz=gzip
eval COMPRESS=\$COMPRESS_${1##*-}
${COMPRESS:+:} ${COMPRESS:-exit 1}

Si on veut avoir un diagnostique, il suffit d'écrire une fonction abort()…

Moi j'aime bien aussi utiliser true pour remplacer un binaire de mon système, par exemple pour overrider une commande défaillante qui est appelée dans un script de post-configure dpkg.
C'est assez gruik et puis le truc c'est qu'on a tendance à oublier cette manip, jusqu'au moment où cette commande a vraiment son utilité… (dédicace perso à la personne qui a débuggé ma debian encore hier soir :p)

Là ou il faut faire bien attention avec ce crochet fermant, c'est de bien mettre une espace avant. Pour éviter le bug suivant: [ "$x" = "$y" -a "$w" = "$z"] . La comparaison de chaîne est à ce titre plus piégeuse car la deuxième condition sera silencieusement toujours fausse (sauf si effectivement on s'attend à ce que $w puisse valoir "$z]"…); par rapport à la comparaison numérique qui va déclencher une erreur de conversion. Du coup, je préfère aussi utiliser backquote test et aussi parce que c'est plus "parlant" :)
Btw l'opérateur == est un bashisme totalement inutile, bref à ne pas utiliser.

Pour le coup des && et || je suis plus partagé. Je n'arrive pas à produire d'exemple mais j'ai le souvenir qu'il y a des situations qui ne sont pas exprimables. Pour les cas simples ok. Il y a aussi l'idiome 'commande qui peut rater sans devoir tout faire exploser || true' utilisé dans un script en "set -e" qui est très pratique.

À part ça, on voit aussi de temps en temps ':' à la place de true… ça fait gagner des caractères… :)
Son autre utilité, c'est pour utiliser l'opérateur : ${var:=defaultvalue}, bien plus concis que d'écrire var=${var:-default}.
Pour rebondir sur l'exemple parent de ce thread:

case .. in
-bz) COMPRESS=bzip2 ;;
-gz) COMPRESS=gzip;;
esac
${COMPRESS:+:} ${COMPRESS:-exit 1}


D'une part, "cd" est aussi une commande interne au shell.

Ok, accordé. Disons que la commande cd aurait très bien pu être externe, voir 2me point.

Et d'autre part […] l'imperméabilité est aussi présente côté Windows.

J'ai bien écris ms-dos/windows, donc implicitement de l'API DOS et des ses implémentations que l'on trouve dans dos >2.0 et windows.
Et là, en dépit de te décevoir, cela n'est pas le cas!

(Au mieux pourrais-tu encore critiquer la pertinence de comparer l'api UNIX à celle de DOS, une api qui n'est certainement plus promue par MS.
J'argumenterais en disais qu'elle est arrivé déjà bien après celle d'UNIX et que cette société aurait pu au moins s'inspirer de l'état de l'art au lieu de torcher un produit dans la seule fin de truster un marcher en faisant fis du développement de l'informatique dans son sens le plus large, quoi que peuvent en dire les médias—encore au jour d'aujourd'hui --.
Je conçois que le posteur de cette question n'a, plus que probablement, aucune expérience avec DOS et donc que cette comparaison s'apparente plus à une expression de type "de mon temps …" sans apporter de vrai valeur pédagogique, néanmoins je souligne ainsi par ce petit retour dans le passé que cette société ne s'est jamais démarquée par l'excellence technique. Car j'estime que sur ce site, il n'est jamais mauvais de faire un peu de prosélytisme, surtout parmi les futurs programmeurs.
Bref, bonjour chez toi et bon week-end)

Et l'âne s'en retourna brouter son herbe…

Bah ça marche, mais le cwd est uniquement modifé pour ton programme (et ses fils, éventuellement).
Immagine le bordel que ça serait si un processus pouvait modifier l'environement du processu qui l'a lancé ?
Note bien que "cd" est une command interne au shell. Au contraire de ms-dos/windows, qui est donc un système qui ne fourni pas cette "imperméabilité" de l'environement d'exécution du parent par son fils ou sous-fils.

Bref soit tu lance un nouveau shell depuis ton programme, soit tu demande au shell qui lance ton programme d'exécuter quelle que chose à la suite, genre output=`./monprog|tail -1`; ret=$?; if test $ret eq 42 then eval cd $output; fi En mieux tu peux utiliser un autre descripteur de sortie pour ne pas devoir réserver ton stdout à cette seule fin. IIRC, certaines distribution configurent un "alias" dans le shell pour midnight commander (mc) afin de pouvoir positionner le répertoire courant du shell sur le dernier visité par mc à la sortie de celui-ci. Tu peux t'inspirer de celà si cela est vraiment nécessaire. Perso, je trouve bizard d'attendre un tel comportement… Dans tout les cas tu devras trouver un système qui demande la coopération du shell appellant :-/

J'essayais juste d'apporter une hypothèse de réponse à la question du pourquoi faut-il laisser un projecteur refroidir.

Mais c'est la répétition le problème,[…]

Je suppose que oui, néanmoins un pc n'est pas un projecteur où il ne suffit que d'une fois, heureusement pour toi d'ailleurs ;-) Par contre, c'est clair que ton cpu ne risque pas de vivre vieux si cela lui arrive tous les jours, comme tu les dis bien c'est une mesure de "sécurité" (pour le cpu).

Bref, je pense qu'on a tous les deux bien compris qu'il s'agit d'un compromis entre le coût, la performance, la fiabilité et la sécurité. Pour cette dernière, il y a des minima imposés (i.e. ton pc ne devrait jamais brûler ta maison en cramant). En passant, tu parlais principalement de fiabilité là. 'fin bref j'imagine que tu es tombé ("loi du marché oblige" marche aussi) sur une conception qui penche plus du côté perf/coût que du côté fiable, à part cela je n'ai rien d'autre à apporter :P

Probablement parce que ce n'est pas la "source" de chaleur que tu tiens à protèger, mais quelques chose d'assez proche ?
Genre quand tu coupes l'alimentation, la température à la source n'augmente pas (voire diminue), tandis que l'objet (ou le gaz?) qui est à son voisinage, n'ayant plus de refroidissement, subit une augmentation de sa température par l'influence de la dite source qui possède à ce moment une température encore largement plus importante.

Une solution imaginable c'est de refroidir une "masse" jusqu'à un niveau plus bàs que la température ambiante, afin d'"absorber" le surplus de chaleur en cas de rupture d'alimentation électrique. Mes notions de physiques sont assez éloignée, mais quelque chose me dit que ce serait très peu efficace en terme de rendement énergétique. Une autre solution c'est d'avoir une batterie… ou (moins cher) de ne pas retirer l'alimentation :p

Il faut changer le /* Cela marche jusqu'à gpio <= 99 */ par 999, car on compte deux fois un charactère '\0'… bref :)

L'important à retenir c'est que même si l'on se plante dans le calcul, ben le code ne risque pas de se planter trop violemment car après on utilise sizeof() sur l'objet construit et snprintf tronquera toujours avec un \0 (sauf si size = 0).

Hormis la question de l'empreinte, je ne trouve pas que pour ce genre de trivalité le python soit beaucoup plus facile, surtout si l'on ne maîtrise ni l'un ni l'autre à priori. Dans les 2 cas tu vas devoir passer autant de temps dans la documentation.
Maintenant pour faire des choses plus complexes, il y aurait probablement matière à débat.

true n'existe pas en C

Ça dépend dans quel C, visiblement dans C99 cela existe après avoir inclu <stdbool.h>.
Après il reste certainement une question de bon goût :)

Du coup je me suis planté d'endroit…

oumayma, réponse ici :

http://linuxfr.org/forums/programmation-c--2/posts/shell-script-langage-c#comment-1631988

PS: N'esite pas à poster ta version corrigée dans les commentaires cette fois ci…

Tu ne maîtrise pas du tout le C semble-t-il

J'imagine que s'il le maîtrisait, il ne viendrait pas poser de questions du coup, non ?

(Ou bien c'est encore un chinois du FBI ??)

C'est bon début !

 /* charge les déclarations de fopen,fclose,fprintf */
#include <stdio.h>

Tu rajouteras ici aussi les autres entêtes pour stat() et cie, cf. suite.
Aussi stdlib.h pour utiliser exit() dans la gestion des erreurs…

int main()
{
int p; char tab[max_N];

max_N ?
1) c'est une définition non standard
2) admettons que cela équivaut à INT_MAX ou autre provenant de /usr/include/limits.h,
tu risque au pire d'allouer beaucoup de mémoire sur la pile pour rien, au mieux d'exploser la pile directement…
Tu pourrais utiliser PATH_MAX, mais bon essayons de calculer au plus juste :

#define GPIO_DIRECTORY_FORMAT "/sys/class/gpio/gpio%d/"
/* Cela marche jusqu'à gpio <= 99 */
/* invariant: strlen("direction") > strlen("value"), cf. plusbàs */
char tab[sizeof(GPIO_DIRECTORY_FORMAT)+sizeof("direction")]

int gpio = 26;
p=open("/sys/class/gpio/export", O_WRONLY);
sprintf(tab, "%d", gpio);
write(p, tab, strlen(tab));
close(p);

On peut remplacer write par fprintf, pas besoin de créer une chaîne temporaire du coup. Cela devient:

FILE *f = fopen("/sys...", O_WRONLY);
fprintf(f,"%d", gpio);
fclose(f);

sprintf(tab, "/sys/class/gpio/gpio%d/direction", gpio);

Toujours éviter les fonctions de formatage et d'io qui ne sont non-bornées pour éviter un dépassement de tampon.

-> snprintf(tab,sizeof(tab), GPIO_DIRECTORY_FORMAT "direction", gpio);

p = open(tab, O_WRONLY);
write(p, "out", 1);

le 1 n'est pas bon…

write(p, "in", 3);
close(p);

Idem j'utiliserais plustôt le IO haut niveau, open -> fopen, write -> fputs/fprintf.

if [ -d "$GPIOPIN" ] then

devient:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

struct stat sb;
if (0 != stat("....", &sb)) {
  /* traiter l'erreure... */
}

if ((sb.mode & S_IFMT) == S_IFREG) {

fprintf ("Blinking LED connected to Pin $PIN …")

fprintf -> printf ou fprint(stdout,...)
}
else {

else
// echo $PIN > /sys/class/gpio/export

Idem, couple fopen, fprintf/fputs, fclose…

fprintf("Blinking LED connected to Pin $PIN …")
idem, fprintf prent un FILE* comme premier argument, printf utilise stdout implicitement.

//sleep 1
usleep () ???

else

Utilise systématiquement des accolades quand tu imbriques les instructions de contrôles, cela est plus lisible et moins sujet à se tromper.

while (true) do
{

sprintf(tab, "/sys/class/gpio/gpio%d/value", gpio);

Déplace cela hors de la boucle, pas besoin de recalculer le chemin à chaque itération
-> snprintf(tab,sizeof(tab), GPIO_DIRECTORY_FORMAT "/value", gpio);

p = open(tab, O_WRONLY);
write(p, "1", 1);

write(p, "0", 1);
close(p);

ok

return 0;
}

Pour apprendre, rien de mieux que de consulter les manpages de toutes les fonctions/headers mentionnés précedemment.
genre sur manpages.debian.net ou sur ton système (man 2 xx ou man 3 xx).

De rien, ravis d'avoir fait avancé le débat (et le PIB de ton pays). Et désolé d'avoir été/d'être quelques peu abrasif…

J'ai déja lu la RFC concernant vCalendar et je ai déja écris un sérialiseur (ok c'est la partie la plus simple), je continue de penser que cela est loin d'être complexe et je penses que sortir un moteur de grammaire risque d'être contre-productif, enfin bon libre à toi d'expérimenter et de nous faire part de tes nouvelles expériences.

Je persiste à penser que la complexité se retrouve dans l'organisation logique des données, par exemple (pour vcal) comment représentes-tu les timezones ? Comment gèrer les différentes addresse et leur rôle (je pense que c'est une notion que la RFC utilise), les liste d'adresses, les groupes, etc.. Bref, vCard c'est un peu plus que un format, l'interropérabilité se joue vraiment dans la couche plus haut. Et je ne suis pas sur que toutes les recommandation de la RFC suffisent à avoir une interopérabilité maximale. Maintenant là où c'est paradoxal, c'est qu'avoir une bibliothèque "haut-niveau" (qui au passage adhère à toutes les recommandation de la RFC mais celon moi c'est anecdotique cf. phrase précédente) va t'imposer des choix d'organisation logique de tes données; ce qui risque de enter en conflit avec ta base de code actuelle ou future (mais bon disons que c'est accessoire comme difficulté) et en même temps limiter ton interropérabilité avec les autres solutions… Oui c'est paradoxal. De ce point de vue, il me semble qu'avoir une bibliothèque la plus simple possible est un avantage (reste à toi de combiner les briques ensembles). Objectivement, ce n'est que mon avis, je ne prétends pas parler en connaissance de cause et je conçois que tu puisses avoir un avis contraire.

Aussi, en ce qui concerne la couche "transport" c'est sans doutes dommage pour toi qu'il n'y aie rien de tout-en-un, mais, je me répète, et comme pour le problème d'organisation logique "high-level", je consière que cela est plustôt une bonne chose. Un jour peut-être vas-tu devoir supporter imap, où le protocol X ? Conceptuellement, cela me semble plus propre de découpler ces partie et plus à même de s'adapter aux contraintes futures…

La question de l'usage que tu comptes en faire reste. I.e. avec quoi tu veux interragir et de quelle façon. Cela nous permettra de t'aider à trouver une solution clef-en-main, si elle existe. (Aussi cela permet d'assouvir ma curiosité). Bon on sait déja que ce n'est pas une GUI Qt :P

Au plaisir :)

http://curl.haxx.se/libcurl/competitors.html
boost_asio
http://stackoverflow.com/search?q=[c++]+http+library ??

Je n'ai pas de réelle suggestion à te faire n'ayant jamais eu de besoin similaire en C++.

il est plus sain pour cette librairie de se limiter à la partie vcard.

J'ai l'impression qu'il serait bon que j'explique ce raisonnement. Lire/écrire du vcard, cela se fait en quelques classes (cf. la bibliothèque mentionnée). Par contre, un "client" CardDAV, qui je le rappelle n'est ni plus ni moins qu'un client HTTP supportant les verbes WedDAV et qui utilise vcard comme format déchange, ben tu peux le faire, à priori, avec n'"importe quelle" bibliothèque HTTP suffisemment aboutie. Il va de soit que la complexité d'une bibliothèque HTTP est bien plus grande.
Donc, il n'y a aucune raison que les deux soient couplées, au contraire tu n'aurais que des inconvénients d'avoir deux implémentation incomplète (ah tiens je voudrais de l'http-pipelining maintenant, et puis de l'http-auth, et puis intégrer dans ma boucle d'évènement pour ne pas avoir de freeze de ma gui, etc. at infinitum).

Permettez moi (je m'adresse aussi aux autres lecteurs/moinsseurs) de trouver cela curieux de devoir expliquer cela à un développeur de C++, cela me semble évident. Tout comme il me semble évident que parser du vCard est "trivial", au point qu'utiliser une bibliothèque déja faite entraine des contraintes: cela nécessite une transformation d'une représentation interne des données vers la représentation qu'utilise cette bibliothèque.

J'avoue que j'ai l'impression que la personne postrice est incompétente, peut-être devrais-je plustôt supposer qu'est-elle novice (le "vCard >= v4.0" ressemble à un /requirement/ de type professionnel…). Ceci mis de côté, j'aimerais pouvoir lire vos arguments afin de savoir en quoi je me trompes et de ce fait apprendre moi aussi de vos opinions. Pour la même raison j'aimerais savoir ce que Viish essaye de faire. Enfin bon je ne vais pas mettre l'espoir d'avoir un retour trop haut, mon ratio énergie/(satisfaction d'aider + satisfaction d'apprendre) est déja passé au travers du plafond :P

La lib est pas maintenue,

Peut-être que l'auteur n'éprouve pas le besoin de l'améliorer ?

elle ne gère pas l'export

Faux.
https://github.com/drppublic/libVCard4/blob/master/VCard4.cpp#L127

et pas le protocole CardDAV.

Et ? Ah mon avis il est plus sain pour cette librairie de se limiter à la partie vcard. Trouves toi une autre librairie pour faire la partie webdav/carddav qui s'intègre bien avec le reste de ton programme.

En plus la lib ne compile pas sur ma machine (bien que ça puisse se réparer).

OK. J'allais te dire te regarder du côté du code de kdepim pour d'autre resources, mais bon cela serait une perte de mon temps vu les efforts que tu sembles prêt à mobiliser… :)

PS: ce n'est pas vrai qu'une écriture se fait en un cycle. Et puis même si c'était le cas, je crois que tu confonds avec un problème d'accès concurrentiel multi-CPU (et cela nécessite toujours un volatile_t pour empêcher le compilo d'aliaser dans un registre). Un signal n'a rien à voir et c'est une opération très coûteuse: cela correspond à un déscheduling puis rescheduling (donc en passant par le kernel), de quoi vider le pipeline du cpu :-)

Désolé, cela n'a rien à voir avec le nombre de cycles. Le problème vient des optimisations que le compilateur peut faire. Si please_exit est optimisé pour être accèdé via un registre dans main, alors lorsque que le programme va se retrouvé préempté pour exécuter le signal, ben ce registre va se retrouver sauvegardé dans le "contexte" avec les autres registres sauvegardés au niveau du kernel et puis au retour, il sera restauré et, au final, la mauvaise valeur sera utilisée, voir réécrite, par main. Dans une main-loop telle que celle là, c'est sans doutes peu probable que cette optimisation se fasse (quoi qu'il faudrait que le compilateur puisse déterminer que toutes les fonctions appellées ne modifient pas la variable globale, ce qui est loin d'être impenssable) mais sur le fond, Krunch a raison…

Ah je crois que tu te fourvoies sur ce coup par contre ;-) Ce qui est listé dans la page signal ne sont bien évidemment que les appels systèmes "async-signal-safe"… printf est une fonction de la bibliothèque C, qui (aux dernières nouvelles) appelle le syscall write() qui lui est même est "safe".

Pour répondre à flavien75, le problème n'est pas tellement que les sorties seraient entre-mellées au milieu de séquence d'échapemment (le terminal y survivra, éventuellement faire une restauration de l'état à la sortie du programme), mais bien que le comportement d'un syscall non async-signa-safe est indéfini car, à cause de la nature préemptive du signal, il pourrait être en cours d'éxécution deux fois. Comme dit juste avant, ce n'est pas un problème pour printf.

Fin bref pour en revenir à des considérations plus générales, c'est à cause de toutes ces subtilités que l'on recommande de faire un handler générique qui va retransmettre le signal dans la boucle d'évènement du programme (le fammeux "select()"). Pour l'ensemble complet des "recommandations" (c.à.d. ce qui fait la différence entre un programme buggé et un programme correcte), je ne peux que vivement conseiller la lecture/compréhension de toutes les pages man associées ou d'un bouquin de programmation système unix :-P

Bien vu.