Michaël a écrit 2935 commentaires

Ou une carte russe. Les cartes russes sont (ou étaient) connues pour donner des infos fausses par endroits comme, par exemple, signaler qu'une route est accessible des véhicules lourds comme des camions semi-remorques ou des chars alors qu'elle ne l'est pas.

Je confirme, c'est ce qui a fait foirer ma dernière tentative d'invasion de la Russie. Du coup avec les copains on est rentrés à la caserne et on a pris l'apéro.

Et tu as vu où que les textes de 20 minutes venaient de près ou de loin de l'AFP? Je ne veux pas l'exclure mais le texte de l'article cité dit seulement “20 Minutes avec agence” et le nom de cette agence n'est manifestement pas un motif de fierté.

Y a-t-il de bonnes raisons de lire 20 minutes? Ou bien c'est juste pour le plaisir de lire des textes approximatifs qui servent d'alibi à un déversoir de publicités?

• Frozen Bubble (ce n'est pas le jeu le plus intelligent, …)

À côté de Circus Linux le jeu Frozen Bubble fait très CSP+ qui aide ses enfants à poser des questions aux petits bateaux de Noëlle Bréham.

Avant de commencer, une suggestion: la prochaine fois n'hésite pas à mettre une copie conforme de ton interaction avec le terminal, au besoin avec quelques commentaires, plutôt que de paraphraser cette interaction. Cela rend les choses plus faciles pour les gens qui veulent t'aider!

Ce que tu dis vs. ce que tu crois dire

Si tu envoies /etc/bash.bashrc dans ton terminal, le shell comprend “Je veux charger et exécuter le programme situé dans le fichier /etc/bash.bashrc, sans arguments.” Il te répond que charger et exécuter le fichier /etc/bash.bashrc n'est pas permis, parceque ce fichier n'a pas le bit x – cf. les modes de fichiers.

Si tu envoies sudo /etc/bash.bashrc tu dis quelque chose comme “Je veux charger et exécuter le programme situé dans le fichier /etc/bash.bashrc, sans arguments et comme super utilisateur.” et sudo te répond que cette commande n'existe pas, ce qui est essentiellement le même message que le premier.

Si tu envoies su /etc/bash.bashrc tu dis quelque chose comme “Ouvre un terminal pour l'utilisateur /etc/bash.bashrc.” qui bien-sûr n'existe pas.

Pour éditer ton fichier

Pour éditer ton fichier, tu peux essayer quelque chose comme

% sudo su -
# nano /etc/bash.bashrc

si nano est ton éditeur préféré.

Et non, c'est pas parce qu'on fait plein de bonnes choses qu'on peut se permettre d'en faire/dire une mauvaise (sauf si on parle du karma sur DLFP, certes).

Ou qu'on fait une baguette extraordinaire! (Merci Blanche Gardin.)

https://www.youtube.com/watch?v=fxdROcLj0Ww

Puisqu‘on fait des efforts de traduction «homme de paille» a un sens en français (grosso modo celui de «prête nom» ou de «faux-nez») qui est assez différent de celui de «strawman» dans le contexte d‘un débat. Peut-être que contre-feu ou enfumage pourraient mieux faire l‘affaire?

Un expédient facile consiste à créer un script shell privilégié qui exécute la seule commande autorisée pour l'utilisateur puis à permettre à l'utilisateur d'utiliser ce script (par exemple via sudo) tout en lui interdisant de lire les codes d'accès à la BDD.

Il faut un peu de soin et quelques groupes/utilisateurs intermédiaires si tu ne veux pas que tout tourne en root mais toute l'implémentation ne présente pas de difficulté particulière.

Voici une excellente introduction à sudo:

https://www.bsdcan.org/2014/schedule/attachments/283_2014-04-29%20sudo%20tutorial%20-%20bsdcan%202014.pdf

Et comme disait mon ancien boss : "la différence entre perl et whitespace, c'est que dans whitespace, l'obfuscation c'est fait exprès". La même marche aussi avec lisp, évidemment.

Blage à part, écrire des programmes illisibles ou difficiles à modifier pour d'autres raisons est plus une question d'état d'esprit que de langage.

Qu'il s'agisse de Java, Perl, Lisp, C, Python ou quoique ce soit d'autre. Même en Shell on peut écrire des programmes propre et maintenables, c'est dire!

J'ai des notions en Python et je ne cesse d'apprendre plus

Salut, les autres ont déjà suggéré des outils, j'élabore en te proposant un “mini plan de travail”:

1. Choisi un outil (par exemple Python + openpyxl comme suggéré)
2. Fait un petit programme qui démontre que ton outil peut parcourir ta fiche excel, par exemple fait un “print” des noms des onglets puis des contenus de chaque onglet – ainsi tu es sûr que ton outil te permet de lire toutes les données.
3. Fait un petit programme qui te permet de générer un nouveau fichier excel, avec un contenu de ton choix, similaire à celui que tu veux générer – mais tu peux partir d'une donnée statique au lieu du résultat d'un traitement conpliqué. Ainsi tu démontres que ton outil te permet de générer le document que tu souhaites.
4. Implémente ton traitement qui traite une structure de données adaptée (celle qui te permet de vérifier rapidement que ton traitement fait ce que tu veux!) et la transorme en une autre.

Un fois que tu as tout ça, tu as traité chaque problème difficile de façon isolée et tu as aussi réduit le risque de passer trop de temps à programmer une solution qui ne marche pas (en commençant par 2 et3 au lieu de faire “1 4 3”).

Bon courage et amuse toi bien!

Si tu veux trouver la voie je te suggère la vidéo de la présentation de Aaron Bieber:Evil Mode: Or, How I Learned to Stop Worrying and Love Emacs

C'est l'histoire d'un mec qui va au “Boston Vim user group” pour dire “ben maintenant j'utilise Emacs”. Son raisonnement est que le evil-mode donne une bonne partie de la puissance de vim et que Emacs est bien plus simple à configurer que Vi.

XMPP C'est bien mais il convenir d'un RDV pour tchatcher un peu. Par exemple ce soir dimanche pourquoi pas, ou bien lundi matin vers 9:30 par exemple?

Salut comme je viens de démissionner et que je joue à l'ingénieur DevOps / consultant infrastructure depuis quelques années, je peux prêter main-forte pour faire une belle pipeline d'intégration et déploiement continus, si ça peut aider. :)

Houaaa, CDE, je l'ai utilisé sur des stations UNIX (je ne sais plus lesquelles).

À la fac de Rennes cela tournait sur des stations Sun Solaris au début des années 2000. :)

Je trouve qu'il est très souvent plus pertinent d'utiliser un éditeur WYSIWIG utilisant un sous-ensemble bien réduit du HTML qu'un texte Markdown, par exemple CKeditor5.

C'est un contresens historique. Le format, ou plutôt les formats, Markdown sont en gros une formalisation du marquage informel qu'on utilise ou utilisait dans les courriels et les messages Usenet, formalisation à laquelle s'ajoutent des extensions (notamment pour les hyperliens les images et les tableaux). Mais le cœur de la syntaxe (le gras, l'italique, les listes, les citations et les “snippets”) sont compris depuis longtemps par certains clients mails, et n'a pas été définit a priori mais résulte d'une pratique existante.

Le Markdown est né d'un usage légitime puisqu'il s'agissait d'ajouter un peu de formatage à un support purement textuel.

Sinon il me semble que le Rich Text Format est sémantiquement équivalent à un sous-ensemble du HTML et si on tient à préparer son texte avec un éditeur WYSIWYG ce serait peut-être un choix plus intéressant qu'un sous-ensemble du HTML, à cause du nombre d'éditeurs disponible.

Le truc, c'est que j'essaie de cultiver des idiomes, et l'usage de printf me semble en être un bon: […]

C'est exact, personnellement je préfère aussi utiliser printf systématiquement. echo n'a presque que des inconvénients… pourtant on l'utilise et le rencontre encore souvent.

Il me reste tant à apprendre, et ce n'est pas en me croyant bon que je le deviendrais.

Ce que je voulais dire est que le fait de programmer le shell n'a pas forcément à voir avec celui d'être admin! Les sources qui m'ont fait faire beaucoup de progrès sont la lecture des divers scripts shell qu'on trouve dans FreeBSD notamment.

une ligne de bash "illisible" (de mon point de vue, ce concentré de caractères sans espaces est pénible à lire du moins) et qui risque de se retourner contre moi, je préfère les 50 lignes de C standard.

Pour bien connaître (ou avoir connu) les deux, chacun se défend bien en termes d'illisibilité. Pour améliorer les choses quand on programme le shell, il faut utiliser des fonctions dont les noms sont explicatifs, je fais la traduction:

listen_udp()
{
  nc -u 12345 -l
}

sendto_udp()
{
  # Sur ma version de NC j'ai besoin du -w 0
  #  pour que NC arrête d'essayer de lire STDIN après
  #  la fin du message.
  nc -w 0 -u 127.0.0.1 12345
}

Et le programme s'écrit

listen_udp & echo "le résultat" | sendto_udp

Cela démarre en arrière-plan (&) un serveur qui écrit tous les messages reçus sur UDP puis envoie un message sur ce serveur.

Aussi, j'ai appris à me méfier d'echo, et une pratique que j'essaie de faire au max est de toujours utiliser printf, pour éviter les surprises.

La “bonne pratique” est de n'utiliser echo que sur un texte constant (c'est le cas ici) qui de plus ne commence pas par un tiret. Pour tout le reste on utilise printf en utilisant une chaîne de format constante.

a doit être lié au fait que je suis un dev qui joue aux admins, et pas un vrai admin

On a le droit de bien connaître le shell même sans être admin. :-)

Je ne comprends pas trop quel problème tu veux résoudre, est-ce que tu peux en dire deux mots? (Quitte à changer, pourquoi pas simplement “publié”?)

Je pense que l'approche d'effacer n'est pas la meilleure, il vaudrait mieux déplacer les fichiers ARW dans le même dossier que les fichiers JPEG qui leur correspondent. L'intérêt est que c'est une fonction qui a son utilité en soit, et qu'elle résout le problème: il suffit de déplacer les fichiers JPEG qu'on ne veut pas dans un dossier spécial, d'e faire suivre les fichiers ARW puis des procéder à l'effacement.

La logique serait, étant donné SRCDIR (dossier où étaient tous les fichiers) et TARGETDIR (fichier d'arrivée):

• On examine TARGETDIR et con construit la liste de tous les fichiers JPG qui n'ont pas le fichier ARW correspondant.
• On examine SRCDIR à la recherche des ces fichiers, lorsqu'ils existent on les déplace à côté du fichier JPG et dans le cas contraire on afficher un avertissement.

Des points bonus pour l'écriture d'un fichier “undo”, un shell script qui permet d'annuler la dernière opération! :-)

L'azerty amélioré a l'air d'être une galère pour les dev/ops, (double)quote, dollar & co passent forcément par alt-gr.

Cela fait depuis plus de dix ans que je suis passé au QWERTY – avec la touche compose de Xorg, tous les accents sont faciles à faire, et si d'aventure on travaille sur un Mac, les caractères nécessaires au français – y compris guillemets et œ, æ – sont faciles à faire.

Pour programmer, le QWERTY US est le clavier le plus facile, probablement. L'AZERTY est peut-être plus utile pour la dactylographie, mais pour la programmation j'ai toujours trouvé que c'était un inconvénient.

En pratique, c'est utilisé pour, justement, utiliser des variables du shell. Sinon, l'intérêt est limité.

Ça dépend des pratiques, et ça dépend des occurrences du caractère $ ou des contr'apostrophes dans le document.

Dans ma pratique, j'utilise très souvent la forme “qui ne remplace pas les variables.”

en utilisant l'astuce

Pourquoi astuce? :-)

Il y a deux choses à améliorer:

cat << EOF | python
…

Est plutôt

python <<'EOF'
…

Pas de cat et apostrophes simples autour du EOF dans l'ouverture du document ad hoc. Les apostrophes simples disent au shell de ne pas toucher au contenu – pas de remplacement de variables notamment. Par contre la marque de fin reste EOF sans apostophes simples.

Si si, tu en apprend que si tu es en face d'une bande d'illuminés armés jusqu'aux dents, eh bien t'as intérêt à vénérer le barbu imaginaire comme il faut.

Vu l'actualité troublée de l'Église (notamment France, Allemagne, USA et Australie) cette phrase semble être à double, tripe voire quadruple tranchant!

Caster c'est un fanpôme, mais un gentil.

C'est vrai mais Caster reste un anglicisme, en français ce serait Gastard.

Et puis de toute façon on peut pas faire confiance à une carte où le Groenland est presque aussi gros que l’Afrique.

Les angles y sont corrects. ;)