Matthieu Moy a écrit 3257 commentaires

compilateurs [programmes qui transforment un code source en un code objet]

Quand on lit ceci (en gras dans la citation ), on peu se demander si l'auteure de l'article maîtrise son sujet

Euh, qu'est-ce que tu reproches à cette définition d'un compilateur ? C'est code objet qui te chagrine ?

# $f va prendre successivement toutes les valeurs correspondant aux fichiers *.ARW dans le répertoire courant
for f in *.ARW           
do
        # ${f%.ARW} = contenu de f, en ayant supprimé le suffixe .ARW
        echo ${f%.ARW}.JPG
done

Plus qu'à remplacer la commande echo par autre chose, mais il vaut mieux tester avec echo d'abord ;-).

Bah oui, mais là tail lit sur un pipe …

Non, il ne veut pas que tu écrives plus, mais que tu lises plus ;-) (si j'étais taquin, j'ajouterais que tu l'aurais compris si tu avais lu son commentaire, mais n'allons pas jusque là ;-) ). En particulier le moment où il dit qu'on ne peut pas se baser sur les timestamps je suppose.

https://stackoverflow.com/questions/5117393/number-of-character-cells-used-by-string

Et d'ailleurs, tu as pu remarquer que les heures de l'école s'adaptaient en fonction de l'heure d'été et de l'heure d'hiver, que le journal de 20h était changeait de créneau quand on passait à l'heure d'été, …

À moins que … ?

C'est justement l'enjeu, là : plutôt que d'adapter tous les horaires à l'heure solaire, on décide une bonne fois pour toutes de l'heure locale, avec l'idée que c'est peu probable que les horaires des trucs fixes (école, télé, ouverture des magasins, …) changent une fois qu'on aura fixé ça. Ces horaires n'ont pas changé pendant les années de changements d'heures été/hiver, je ne vois pas bien pourquoi ils se mettraient à changer magiquement maintenant.

• Rendez-vous le 9 mars, après déjeuner (23h30)
• Je ne suis pas dispo, on peut repousser d'une heure
• OK, alors le 10 mars à 0h30

Ou bien

• Le lundi de pâques tombe les 22 et 23 avril cette année

Ça fait pas envie, perso. Enfin, ça c'est en supposant un changement de date à 0h00 pour tout le monde. On pourrait aussi jouer à le mettre à minuit heure solaire, et donc avoir des changements de dates à des heures locales différentes pour tout le monde, et du coup il faudrait décider de tranches de la carte du monde qui changeraient de date à 0h00, 1h00, 2h00, … et ça ressemblerait très très fort à des fuseaux horaires …

Et comme ça, certains pays changeraient de date au milieu de la journée, ça serait rigolo ça.

En clair c'est une mauvaise idée, mais la tradition unixienne est plutôt de ne rien afficher du tout. C'est ce que j'ai toujours vu pour su et sudo en tous cas.

Bizarre : sauf erreur de ma part, POSIX impose que le fichier soit lu au fur et à mesure. C'est une bizarerie de POSIX, les interprètes classiques plus modernes lisent et parsent tout le fichier d'un coup, c'est beaucoup plus logique. Donc a priori, ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ, ton bash doit être dans un mode où il s'autorise des non-POSIXeries. Peut-être une variable POSIXLY_CORRECT bizarrement positionnée ou un truc qui ressemble. En tous cas moi j'ai bien le comportement où la modif en cours d'exécution est prise en compte.

Sinon, si on veut être sûr que tout le fichier est lu au démarrage, l'astuce classique est de l'encapsuler dans une paire d'accolades :

{
...
tout le script
...
}

Et là le shell est obligé d'aller jusqu'au } fermant avant de démarrer l'exécution.

Bon, tout ça de mémoire, je ne retrouve plus mes sources.

Tiens, personne n'a encore crié sur l'absence de "" autour de $fichier. Ouille ouille ouille si $fichier contient des espaces … ;-)

Tu confonds avec monotone.

"Mackall first announced Mercurial on 19 April 2005" (https://en.wikipedia.org/wiki/Mercurial#Adoption). C'est quelques jours après Git.

Les modifs sont faites en temps réel, mais les tuiles utilisées sur http://openstreetmap.org/ ne sont pas mises à jour immédiatement, ça met environ 24h selon l'échelle.

Ça veut dire qu'il manque une tabulation en début de ligne 4.

Attention, la syntaxe de Make est « particulière » :

nom-de-cible: dépendances
<tabulation>action

Si tu mets des espaces à la place de la tabulation, ça ne marche pas.

Sinon, y'a une variante :

str(x)[-1] in ('0', '2', '4', '6', '8')

(Traduction littérale de la méthode apprise à l'école primaire …)

;-)

M-x woman marche déjà ;-).

Et comme pour chaque chose importante dans la vie, il y a un xkcd approprié :

Pour Oracle, l'achat d'entreprise est assez clairement un moyen de recrutement. SUN était en train de couler au moment du rachat, personne n'aurait mis un kopek sur les technos SUN à ce moment là, par contre des gens compétents chez SUN, il devait en rester pas mal.

Et re-tant qu'à faire, ne pas utiliser echo sur une donnée venant de l'utilisateur et qui pourrait commencer par -. Pour être robuste, préférer printf :

printf '%s' "$mot" >> temp

Mais je pinaille un peu là.

As-tu bien sélectionné la source HDMI sur l'écran ? Est-ce que l'écran marche sur une autre machine ?

Où alors j'ai rien compris :(

Bah ….

Le ./configure est un fichier généré par les autotools, tu n'as pas besoin du générateur (donc des autotools) pour le lancer.

C'est un choix discutable, mais c'est ce choix qui est à la fois une force d'autotools (besoin de très peu de chose sur la machine où on compile) et à l'origine de la plupart des ennuis des autotools : toute la chaîne de génération est coupée en deux, une partie « développeur » et une partie « utilisateur qui compile à partir des sources ». Avec automake par exemple, as un Makefile généré à partir d'un Makefile.in par un script généré par le configure, qui est généré à partir du configure.ac par autoconf. Le Makefile.in est généré à partir du Makefile.am par automake. Simple, hein ? ;-)

il t'a bien fallut installer un tas d'outils (en particulier les autotools

Non justement, le principe des autotools c'est qu'ils sont installés sur la machine du développeur, mais on n'en a pas besoin pour installer.

Le C veut dire « Comme ».

Pas de VM au sens « environnement d'exécution d'un langage », mais VM au sens « hyperviseur ». Le message auquel tu réponds fait juste remarquer qu'un langage efficace à l'exécution réduit la facture d'hébergement cloud. Bon, au final, dans un environnement pas virtualisé, on payait aussi au CPU et à la RAM parce qu'un gros serveur coûtait plus cher qu'un petit, hein … ;-)

donc en fait techniquement c'est une mauvaise idée, il vaudrait mieux faire '*.jpg' afin d'être certain que le shell (quel qu'il soit) n'expande rien et envoie la formule telle quelle.

Oui, clairement.

En fait, ce qui aurais été bien, c'est que le shell provoque une erreur quand l'expansion de wildcard ne marche pas. C'est ce que fait zsh par exemple :

bash$ echo *.nosuchext
*.nosuchext
zsh$ $ echo *.nosuchext
zsh: no matches found: *.nosuchext

La solution de bash, qui sauf erreur de ma part date du Bourne Shell original, est à mon avis choisie par flemme des concepteurs de faire des erreurs propres : le shell passe le wildcard en l'état à la commande en espérant que la commande en fasse quelque chose de pertinent. Des fois, ça marche :

$ ls *.nosuchext
ls: cannot access '*.nosuchext': No such file or directory

Pour find, le résultat est on ne peut moins déroutant.

Un intérêt de la solution zsh est aussi que ça permet un super jeu de mots :

$ have fire ?
zsh: no matches found: ?

;-)