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.
Nvidia attire l’attention des joueurs PC sous Linux après la publication de plusieurs offres d’emploi très explicites.
Cet article Nvidia recrute pour booster le jeu sous Linux a été publié en premier par GinjFo.
Ce tutoriel explique comment installer et utiliser Mariabackup (MariaDB-Backup) pour sauvegarder à chaud des instances MariaDB et comment restaurer les données.
Le post Mariabackup : sauvegarder à chaud les bases de données MariaDB a été publié sur IT-Connect.
Linux 7.0-rc1 assure une prise en charge initiale de Nova Lake, Diamond Rapids et Zen 6 et de nouvelles fonctions côté performances.
Cet article Linux 7.0-rc1 est là avec le support de Nova Lake et Zen 6 a été publié en premier par GinjFo.
AsteroidOS , c'est une distro Linux open source qui tourne... sur des montres connectées ! Oui oui, du manchot au poignet et l'idée en fait, c'est de virer WearOS et toute la télémétrie Google qui va avec, pour le remplacer par un OS libre sans tracking ou de compte à se créer.
Ce projet existe depuis 2015 et supporte aujourd'hui une trentaine de montres (LG Watch, Huawei Watch, TicWatch, Asus Zenwatch, Fossil Gen 4/5/6...). Vous flashez votre tocante connectée, et vous récupérez un OS avec agenda, météo, chronomètre, boussole, moniteur cardiaque, contrôle musical et même un petit jeu. Le tout en Qt/QML, avec des cadrans communautaires et un affichage permanent !
Côté vie privée , c'est même le JOUR ET LA NUIT avec WearOS donc pour ceux qui flippent que leur montre balance tout à Mountain View, c'est plutôt rassurant.
Pour la synchro avec votre téléphone, y'a également AsteroidOSSync sur F-Droid ou Gadgetbridge . Si vous hésitez, sachez que Gadgetbridge est plus maintenu et plus universel. Ça couvre l'essentiel et si vous avez les chocottes, un mode dual-boot permet de tester sans virer WearOS.
Attention par contre, c'est pas la fête du slip non plus car y'a pas de store d'apps (faut pousser les APK en ligne de commande via ADB), pas de réponse aux appels depuis le poignet, et les apps WearOS ne tournent évidemment pas dessus. A moins que votre montre soit dans la liste officielle, n'y pensez même pas ! Faut aimer bidouiller, en fait mais ça, je sais que vous adorez ^^.
Et grâce à cet OS, vous atteindrez peut-être les 48h d'autonomie annoncées sur le site. Après faut voir en vrai évidemment... mais pour une distro communautaire portée par des passionnés depuis 11 ANS quand même, c'est honnête.
Merci à l'ami Lorenper pour la découverte !
Ce tutoriel explique comment installer et utiliser ISOMan, un outil open source qui permet de créer facilement une bibliothèque d'image ISO.
Le post ISOMan : un outil open source pour centraliser vos images ISO a été publié sur IT-Connect.
Ce tutoriel pas à pas explique comment installer et configurer Redis sous Linux (Debian) pour bénéficier du cache objet avec un site web WordPress.
Le post WordPress : comment configurer le cache objet Redis ? a été publié sur IT-Connect.
-v3.2.png)
KDE Plasma 6.6 apporte un gestionnaire de connexion inédit, de l’OCR dans l’outil de capture d’écran et de nombreuses améliorations pour les joueurs.
Cet article KDE Plasma 6.6 débarque, quelle amélioration change réellement l’expérience ? a été publié en premier par GinjFo.
Sur le marché des PCs, Windows profite d'une position dominante depuis des décennies. Pourquoi Linux n'arrive pas à percer ?
Cet article Pourquoi Windows domine toujours Linux sur le marché des PC ? a été publié en premier par GinjFo.
GNOME 50 entre en bêta publique avec gel des fonctionnalités. Voici une bilan des avancées et des nouveautés les plus importantes.
Cet article GNOME 50 propose Wayland par défaut, VRR natif et de nombreuses améliorations a été publié en premier par GinjFo.
Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ?
Hé bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution basée sur systemd (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif déjà installé qui permet de diagnostiquer tout ça : systemd-analyze
Ce truc c'est un peu le médecin légiste de votre démarrage système. Il dissèque chaque étape, identifie les unités qui traînent la patte, et vous permet de comprendre où part votre précieux temps. Pour ceux qui débarquent, systemd est le système d'initialisation adopté par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parallèle pour gagner du temps.
Pour commencer, la commande de base c'est tout simplement :
systemd-analyze time
Elle vous sort un récapitulatif du temps passé dans chaque phase, généralement le kernel, l'initrd (le RAM disk initial), et l'espace utilisateur. Selon votre configuration, vous pourriez aussi voir passer le firmware ou le bootloader. Ça donne un truc du genre "Startup finished in 2.5s (kernel) + 19s (initrd) + 47s (userspace)". Déjà là, vous savez si le problème vient de votre noyau ou de vos services.
Mais le truc vraiment cool pour fouiller un peu plus dans le détail, c'est :
systemd-analyze blame
Cette commande vous balance la liste des unités systemd, triées par le temps qu'elles ont mis à s'initialiser. C'est un peu comme un classement des cancres de la Ve République. Vous voyez direct qui sont les boulets qui ralentissent tout le monde. Genre ce service réseau qui attend 20 secondes une connexion qui n'arrivera jamais, ou ce truc de logs qui prend son temps pour se réveiller.
Attention quand même, y'a un petit piège car un service qui met 10 secondes à démarrer ne signifie pas forcément que votre boot est rallongé de 10 secondes. Pourquoi me diriez-vous ? Hé bien parce que systemd lance plein de trucs en parallèle. Un service peut donc prendre son temps tranquille pendant que d'autres bossent en même temps sans bloquer personne.
Pour vraiment piger ce qui coince sur le chemin critique, lancez plutôt :
systemd-analyze critical-chain
Ça, c'est le top car ça vous montre la chaîne critique, c'est-à-dire la séquence exacte d'événements qui détermine vraiment votre temps de démarrage final. Vous voyez exactement quelles unités sont sur le chemin et lesquelles attendent les autres. Le temps après le "@" indique quand l'unité est devenue active, et le temps après le "+" montre combien de temps elle a pris pour démarrer. C'est bien plus fiable que blame pour identifier les vrais goulots d'étranglement.
Et si vous êtes du genre visuel, y'a même :
systemd-analyze plot > boot.svg
Et avec ça, hop, ça génèrera un magnifique graphique SVG qui représentera la chronologie de votre séquence de boot. Vous pourrez ensuite l'ouvrir dans votre navigateur et voir en un coup d'oeil ce qui démarre quand et combien de temps ça dure. C'est super pratique pour épater la galerie ou juste visualiser l'ordre de lancement.
Maintenant, une fois que vous avez identifié les coupables, comment on fait pour accélérer tout ça ?
Déjà, vous pouvez désactiver les services dont vous n'avez pas besoin avec :
sudo systemctl disable nom-du-service
Gardez en tête que disable supprime seulement le lancement automatique au boot, mais n'empêche pas une activation indirecte via une dépendance ou un socket. Si vous voulez vraiment qu'un service ne démarre plus jamais, utilisez mask. Et surtout, ne désactivez pas n'importe quoi comme un bourrin, hein ! Je vous connais ! Non, non, avant de toucher à un service, vérifiez d'abord ce qui en dépend :
systemctl list-dependencies nom-du-service
Car si vous cassez un truc important, votre système risque de ne plus démarrer correctement. Donc si vous n'êtes pas sûr, gardez vos mimines dans vos poches. D'ailleurs, si vous bidouillez vos fichiers d'unité (comme pour automatiser Shiori par exemple), sachez que vous pouvez aussi les vérifier pour débusquer les erreurs avec :
systemd-analyze verify /chemin/vers/unite.service
C'est super pratique pour éviter les mauvaises surprises au prochain redémarrage. Voilà et si vous cherchez d'autres astuces pour optimiser votre machine Linux , n'hésitez pas à jeter un oeil à mon article sur TLP.
Ah j'oubliais, y'a aussi la commande systemd-analyze security qui permet d'analyser le niveau d'exposition sécurité de vos services. Elle attribue un score heuristique d'exposition basé sur les options de durcissement (hardening) actives. Plus le score est bas, mieux le service est protégé contre d'éventuelles failles. C'est donc un excellent point de départ pour identifier les services qui mériteraient un peu plus de love côté isolation.
Bref, cet analyseur de démarrage c'est vraiment l'outil indispensable pour qui veut comprendre et optimiser son boot Linux. C'est natif, c'est puissant, et ça vous évite de passer des heures à chercher pourquoi votre machine met autant de temps que vous à se réveiller le matin ^^.
Ce guide technique explique comment bien utiliser la commande awk sous Linux pour traiter les données de fichiers textes : filtrer, analyser, compter, etc.
Le post Maîtriser la commande awk sous Linux pour le traitement de données a été publié sur IT-Connect.
Rsync est un outil de synchronisation de données autant polyvalent que performant, très largement utilisé sur les machines Linux, y compris pour la sauvegarde.
Le post Maîtriser Rsync sous Linux : le guide complet de la synchronisation de données a été publié sur IT-Connect.
Pour lutter contre les bots IA, Debian a pris la décision de protéger les données d'intégration continue. Le code produit par IA est également critiqué.
Le post Debian verrouille son infrastructure face à l’appétit insatiable des bots d’IA a été publié sur IT-Connect.
