Et si mes déchets d’été devenaient mes meilleurs alliés pour affronter l’hiver ?
L’article Comment j’allume mon poêle à bois gratuitement et sans aucun produit chimique ?, rédigé par Méline Kleczinski, est apparu en premier sur NeozOne.
2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.
En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.
Connexion> - Écrire dans un fichier (et tout écraser)echo "Salut" > fichier.txt
Ça redirige stdout vers fichier.txt. Si le fichier existe déjà... c'est mort, il est écrasé sans sommation. Du coup, faites gaffe avec vos logs, une commande mal placée et ce sont des heures de données qui disparaissent.
D'ailleurs, si vous êtes du genre parano (et oui, vous avez raison !), set -o noclobber dans votre .bashrc empêchera > d'écraser un fichier existant lors d'une commande tapée à la main. Pour y arriver, il faudra utiliser >| pour forcer.
>> - Ajouter à la suiteecho "Ligne 2" >> fichier.txt
Même principe que >, sauf que ça ajoute à la fin au lieu d'écraser. C'est ce que vous voulez 99% du temps pour des logs (sauf si vous voulez repartir de zéro, là > fait le job). Une lettre de différence entre "tout va bien" et "où sont passés mes logs, boudiouuu ???".
2> - Rediriger les erreurscommande_foireuse 2> erreurs.log
Le 2 c'est stderr, en gros (y'a pas d'espace entre le 2 et le >, sinon bash croit que 2 est un argument). Tout ce qui sort en erreur finit dans erreurs.log au lieu de polluer votre terminal. Perso, je trouve ça super pratique pour garder une trace propre quand vous lancez des scripts via crontab -e.
Et 2>> existe aussi, pour cumuler les erreurs au fil du temps au lieu d'écraser le fichier à chaque exécution.
2>&1 - Fusionner erreurs et sortie normalecommande > output.log 2>&1
Le fameux ! Le &1 dit à bash "le 1 c'est un file descriptor, pas un fichier qui s'appelle littéralement 1". Du coup stderr (2) est redirigé vers le même endroit que stdout (1), ou plutôt vers là où stdout pointe au moment où bash évalue la ligne. Ça va, vous suivez toujours ? ^^
Attention, l'ordre compte ! Bash lit les redirections de gauche à droite. > output.log 2>&1, stdout pointe vers le fichier, puis stderr suit... tout va dans le fichier. 2>&1 > output.log, stderr copie stdout qui pointe ENCORE vers le terminal, puis stdout est redirigé vers le fichier. Résultat, les erreurs restent dans votre terminal. Le piège classique.
Et &> fait la même chose en plus court :
commande &> output.log
&> est super pratique, mais spécifique à bash / zsh donc pour la portabilité, préférez quand même > fichier 2>&1.
2>/dev/null - Le trou noirfind / -name "*.conf" 2>/dev/null
/dev/null, c'est le trou noir d'Unix. Tout ce que vous envoyez là-dedans disparaît. Super pratique avec find qui vous crache 200 "Permission denied" pour un seul résultat utile.
Et si vous voulez TOUT faire disparaître (stdout + stderr) ? Un petit &>/dev/null et c'est réglé. Pratique dans vos scripts /etc/cron.d/ quand vous voulez zéro bruit (bon, j'exagère un chouïa, je sais...).
Si vous aimez les raccourcis bash , j'ai aussi ce qu'il faut.
Bref, voilà ce sont juste 5 opérateurs à retenir, et avec ça vous couvrez à peu près tout. Donc la prochaine fois que vous copierez un 2>&1, au moins vous saurez pourquoi.
Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...
En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !
Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.
Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"
Et la réponse des devs : Won't Fix. Circulez les relous !
En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.
D'ailleurs,
en 2013 je vous expliquais comment activer ces étoiles manuellement
avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.
Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...
Alors pour désactiver ces jolies zétoiles :
sudo visudo
Et ajoutez cette ligne à la fin de /etc/sudoers :
Defaults !pwfeedback
Sauvegardez (Ctrl+X sous nano), et c'est réglé. Attention, ne touchez à rien d'autre dans ce fichier, une erreur de typo et sudo ne marchera plus. Grâce à cette manip, ce sera retour au trou noir ! Youpi !
Mars arrive, la tondeuse trépigne… mais êtes-vous sûr de choisir le bon moment pour cette première coupe ?
L’article Quand faut-il tondre sa pelouse pour la première fois en 2026 ?, rédigé par Nathalie Kleczinski, est apparu en premier sur NeozOne.
Where can I go for $X? Budget-first travel destination finder with flights, hotels, and daily expenses.
Des faux entretiens d'embauche avec des repos GitHub vérolés pour piéger les devs Next.js... on croit rêver et pourtant, Microsoft vient de documenter cette campagne ciblée et vous allez voir, c'est violent.
En fait, un groupe de hackers se fait actuellement passer pour des recruteurs et contacte des développeurs JavaScript en leur proposant un entretien technique. Le deal c'est de cloner un repo GitHub pour un "test de compétences"... sauf que le repo en question est truffé de malware.
Microsoft a ainsi identifié plusieurs vecteurs d'infection planqués dans ces repos. Le premier, c'est via les fichiers de configuration VS Code, c'est à dire ceux dans le dossier .vscode/, qui peuvent exécuter du code dès que vous cliquez "Trust" à l'ouverture du projet (ce que la plupart des devs font sans réfléchir).
Le deuxième passe par un npm run dev piégé, la commande de dev classique qui lance le malware en même temps que le serveur (car oui, c'est aussi simple que ça...).
Et le troisième est encore plus sournois puisqu'il s'agit d'un module backend qui décode une URL depuis le fichier .env, exfiltre toutes les variables d'environnement (tokens cloud, clés API...), puis exécute du JavaScript reçu en retour. Sympaaaaaa....
Du coup, le malware est plutôt bien pensé. C'est un loader JavaScript qui se télécharge depuis l'infrastructure Vercel (comme ça, ça a l'air légitime), et qui s'exécute entièrement en mémoire, et spawne un processus Node.js séparé pour ne pas éveiller les soupçons. Une fois installé, il se connecte alors à un serveur C2 qui change d'identifiant régulièrement, histoire de compliquer la détection. Et là, ça se met à exfiltrer tout ce qui traîne... code source, secrets, credentials cloud... bref, tout ce qui a de la valeur.
Alors, comment on se protège de ce genre de menace quand on est un simple dev ? Hé bien déjà, vérifiez le profil du "recruteur". Pas de site d'entreprise vérifiable, des messages génériques... c'est un joli red flag !
Ensuite, avant de lancer quoi que ce soit, lisez le package.json à la recherche de scripts suspects dans preinstall, postinstall ou prepare, inspectez le dossier .vscode/ (surtout tasks.json), et faites un npm install --ignore-scripts pour bloquer l'exécution automatique des hooks. Lancez aussi un
safe-npm
et un npm audit une fois les dépendances installées. Et côté VS Code, désactivez l'exécution auto des tasks avec "task.allowAutomaticTasks": "off" dans vos settings.
Ça me rappelle les campagnes type Shai-Hulud et les packages npm vérolés , mais avec un vecteur social bien plus élaboré. Le piège, c'est qu'on ne balance plus des packages malveillants dans le registry en espérant qu'un dev les installe par erreur... non, non, on cible directement les développeurs, un par un, en exploitant ce stress de la recherche d'emploi comme le ferait un conseiller France Travail quand vous arrivez en fin de droits chomdu...
Et si vous êtes en pleine recherche d'emploi, attention, ne lancez JAMAIS un projet d'un inconnu dans votre environnement principal. Utilisez une VM, un container Docker (docker run --rm -it -v $(pwd):/app node:20 bash et c'est réglé), ou au minimum un compte utilisateur séparé sans accès à vos tokens et clés SSH. On n'est jamais trop prudent !
Maintenant vous savez... si un recruteur vous envoie un repo GitHub sans profil LinkedIn ni site d'entreprise véritable et vérifiable... c'est que c'est pas un recruteur. Voilà voilà...
Claude Code tourne en local et c'est son gros avantage car ça permet par exemple d'agir sur votre machine, de lancer des scripts...etc. Mais c'est aussi sa grosse limite car à cause de ça, vous êtes cloué devant votre terminal. J'étais en quête depuis un moment d'une solution et je vous avais déjà parlé de Vibe Companion y'a pas longtemps mais tous ces outils vont disparaitre puisque Anthropic vient de sortir Remote Control, une feature qui transforme claude.ai ou l'app mobile en télécommande pour votre session locale. Comme ça, vos fichiers restent chez vous et seule l'interface voyage.
Votre ordi fait tourner Claude Code normalement, et vous, vous pouvez continuer à lui parler depuis votre iPhone, votre Android, votre iPad ou n'importe quel navigateur Chrome, Firefox, Safari... Pas de serveur exposé, pas de port ouvert, que du HTTPS sortant. C'est plutôt bien foutu vous allez voir !
Bon déjà, un abonnement Pro (Édit : ? on me dit que c'est pas encore actif pour les pro ?) ou Max (pas le choix, les clés API ne marchent pas et les plans Team/Enterprise sont exclus pour le moment). Ensuite, vérifiez que Claude Code est installé et que vous êtes connecté via /login. Acceptez ensuite le "workspace trust" dans votre projet et hop, c'est tout côté prérequis.
Deux options s'offrent à vous ensuite... Soit vous démarrez une nouvelle session dédiée :
claude remote-control
Soit vous êtes déjà en train de bosser dans Claude Code et vous tapez /rc (alias de /remote-control). Avec claude remote-control, seule l'URL apparaît... donc appuyez sur espace pour afficher le joli QR code.
3 flags utiles (uniquement avec claude remote-control, pas /rc) : --verbose pour voir ce qui transite, --sandbox pour forcer le mode bac à sable (désactivé par défaut) et --no-sandbox pour le couper si vous l'avez activé dans votre config.
Ensuite, la méthode la plus rapide c'est de scanner le QR code avec votre téléphone. Sinon, copiez l'URL affichée et collez-la dans n'importe quel navigateur. Dernière option, allez sur claude.ai/code et votre session apparaît dans la liste (les sessions actives ont un petit point vert).
Une fois connecté, vous récupérez votre conversation en cours, vos fichiers, votre contexte... tout. Vous pouvez envoyer des messages, voir les résultats, approuver les modifications de fichiers. Bref, comme si vous étiez devant votre terminal, sauf que vous êtes dans votre canapé, votre lit ou en train de pousser le caddie chez Auchan !
Maintenant, si vous voulez que CHAQUE session Claude Code soit automatiquement accessible à distance, tapez /config dans une session Claude Code, puis activez l'option "Enable Remote Control for all sessions". Et voilà, plus besoin d'y réfléchir ! Chaque claude lancé dans un terminal sera pilotable depuis votre navigateur ou l'app mobile.
Vos sessions prennent le nom de votre dernier message (ou "Remote Control session" par défaut), donc utilisez /rename mon-projet-cool pour les retrouver facilement dans la liste sur claude.ai/code.
Sinon, dans Claude Code avec /mobile vous pouvez aussi afficher directement le QR code pour télécharger l'app Claude sur iOS ou Android.
Bon, après c'est pas non plus parfait car déjà, c'est cappé à UNE SEULE session à distance par instance de Claude Code (si vous en lancez une deuxième, la première se déconnecte). Par contre, plusieurs instances dans des terminaux différents peuvent chacune avoir leur session remote. Le terminal doit également rester ouvert (si vous le fermez, c'est fini). Mais bonne nouvelle quand même, si le laptop passe en veille ou que le réseau saute, ça se reconnectera tout seul au réveil. Le piège, c'est si la machine reste sans réseau plus de 10 minutes... là, la session expire et il faudra relancer claude remote-control.
Soyez rassurés quand même côté sécurité c'est propre (uniquement du HTTPS sortant sur le port 443, zéro port entrant et des identifiants éphémères), mais gardez en tête que
Claude Code a accès à votre terminal
donc sauf si vous activez --sandbox, il peut de ce fait exécuter n'importe quelle commande... donc les mêmes précautions qu'en local s'appliquent !
Du coup si vous en avez marre de rester scotché devant votre terminal, maintenant vous savez quoi faire.
Merci à Lorenper !
