Matthieu Moy a écrit 3248 commentaires

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: ?

;-)

Le cas de find est particulièrement tordu. En pratique il y a 3 cas :

find . -name '*.jpg'  # ou \*.jpg, ou "*.jpg"

=> Trouve tous les fichiers se terminant par .jpg, dans le répertoire courant et ses sous-répertoires. C'est en général ce qu'on veut. Le shell va passer *.jpg sans expansion à find, qui fait le boulot.

find . -name *.jpg

=> Si il existe un fichier terminant par .jpg dans le répertoire courant (disons foo.jpg), alors le shell va faire l'expansion, et la commande réelle sera find . -name foo.jpg, qui va trouver tous les fichiers nommés foo.jpg dans le répertoire courant et ses sous-répertoires. C'est probablement une bêtise.

=> Si il n'existe pas de fichier terminant par .jpg dans le répertoire courant, alors le shell va tenter l'expansion, qui va échouer. La plupart des shells (bash compris) vont laisser *.jpg tel quel, et la commande sera donc bien find . -name *.jpg qui fera ce qu'on attend. C'est un coup de chance, mais c'est probablement une bêtise aussi.

Tout dépends de ce que tu appelles « projet ». Avec GitLab et GitHub, tu as la notion d'organisation qui peut répondre à ça. Par exemple, l'organisation linuxfr sur GitHub contient plusieurs dépôts, tous liés à linuxfr : https://github.com/linuxfrorg.

Là où le système trouve ses limites, c'est quand tu veux avoir une gestion des bugs globale à un projet qui contient plusieurs dépôts (par exemple un point d'entrée unique pour les rapports de bugs, puis aiguillage sur un sous-projet et ré-aiguillage possible a posteriori).

Euh, le # de C#, c'était 4 + les uns à côté des autres. L'argument marketing, c'était clairement (C++)++.

Après, est ce que c'était un argument raisonnable, c'est une autre histoire.

Au risque de dire une grosse couennerie

Oui ;-).

Plus sérieusement : $IFS est utilisé par le shell pour délimiter les mots (en particulier dans la construction for v in $values), mais pas par grep.

Déjà, -A 10 -B 10, c'est une manière verbeuse d'écrire -C 10 ;-).

Ce que tu cherches n'existe pas à ma connaissance avec grep, mais tu peux toujours transformer le texte en entrée pour transformer les mots en ligne. Quelque chose comme :

tr ' ' '\n' <$fichier | grep -C 10 $mot --color=force | tr '\n' ' '
En remplaçant $mot et $fichier.

ton entreprise a usurpé l'indentité de certains sites, et une autorité de certification a validé cette usurpation.

C'est dit explicitement dans le journal : l'entreprise force à installer un certificat en plus sur les clients, et signe les réponses HTTP avec ce certificat. Pas besoin de passer par une autorité de certification existante (là ça serait effectivement très embêtant), c'est juste une histoire interne au réseau de la boîte.

Attention, « mémoire occupée » peut vouloir dire beaucoup de choses différentes sur un système moderne. Qu'as-tu utilisé pour obtenir tes chiffres ? Que donne la commande vmstat ?

Et j'anticipe sur l'explication : en quoi est-ce problématique que ta RAM soit utilisée ;-) ?

Oui, c'est clair que :

« Les utilisateurs qui concèdent un accès à des services tiers prennent le risque que leurs messages soient scannés »

C'est quand même un peu une tautologie du style (modulo un passage dans le dictionnaire des synonymes).