Sur un poste Linux, la commande cut fait partie de ces petits outils qui sauvent une astreinte à 3 h du matin. Elle permet d’extraire très vite des champs dans un fichier texte, un flux de logs ou la sortie d’une commande, en s’appuyant sur des délimiteurs ou sur des positions de caractères fixes. Dans un terminal, quelques options bien choisies suffisent pour isoler une colonne CSV, récupérer un identifiant dans un log applicatif ou préparer un jeu de données pour un pipeline shell plus élaboré. Cet article détaille l’usage concret de cut Linux, avec des exemples reproductibles, quelques pièges classiques et des comparaisons avec d’autres outils de traitement de texte.
Dans un contexte IoT ou industriel, où s’enchaînent exports CSV, trames sérialisées et fichiers de mesures, un opérateur qui maîtrise cut gagne des minutes à chaque diagnostic. Les architectes systèmes le combinent volontiers avec tail, grep, awk ou un broker MQTT pour filtrer au plus près des machines, dans un simple shell. Les exemples qui suivent s’appuient sur des cas typiques rencontrés sur des passerelles de terrain et sur des serveurs d’agrégation, avec un fil rouge simple : aller droit au but sans scripts lourds. Ceux qui conçoivent des architectures d’edge computing IoT y trouveront une boîte à outils minimaliste mais robuste pour nettoyer rapidement leurs données avant ingestion.
En bref
- cut sert à extraire des colonnes ou des plages de caractères dans des flux texte structurés, directement depuis le terminal Linux.
- Les trois options clés sont -b (octets), -c (caractères) et -f (champs) combinées avec -d pour définir les délimiteurs.
- Pour des CSV simples ou des logs bien formés, cut reste plus rapide à utiliser qu’un script Python ou un tableur.
- Les limites de cut apparaissent avec les délimiteurs multiples, les champs optionnels ou l’UTF‑8 exotique, cas où awk ou sed deviennent plus adaptés.
- Recommandation pratique : standardiser les séparateurs dans vos exports (souvent « ; » ou « , ») et documenter les indices de colonnes pour pouvoir les cibler immédiatement avec cut en production.
Commande cut Linux : principe et usages typiques dans un terminal
La commande cut lit une entrée texte, découpe chaque ligne selon une règle, puis renvoie uniquement les segments demandés. L’entrée peut venir d’un fichier, d’un pipe ou d’une redirection, ce qui la rend particulièrement pratique dans un enchaînement de commandes shell. Le principe reste le même : décrire quels octets, quels caractères ou quels champs doivent être extraits, et laisser le noyau faire le reste.
La syntaxe minimale ressemble à ceci :
cut [options] [fichier]
En production, on la voit surtout au bout d’un pipe :
commande | cut [options]
Chez un intégrateur IoT qui récupère les données de capteurs dans un CSV de quelques centaines de milliers de lignes, cut est souvent le premier réflexe pour vérifier que le format promis par le fournisseur est bien respecté. Une simple extraction de la première et de la troisième colonne révèle tout de suite si un timestamp manque ou si un identifiant de capteur déborde sur la colonne suivante. Cette vérification sommaire évite parfois une longue chasse aux erreurs bien plus tard dans le pipeline.
Options cut indispensables pour extraire des champs et des colonnes
Les options de cut tournent autour de trois axes : octets, caractères et champs. Elles se combinent rarement entre elles sur une même commande, ce qui simplifie la mémorisation. La vraie différence se joue sur la granularité : position fixe ou séparation par un délimiteur.
Les options de base sont :
- -b liste : sélectionne des positions en octets (utile sur des formats bien stricts, moins sur de l’UTF‑8 varié).
- -c liste : sélectionne des positions en caractères, souvent plus intuitif pour un humain.
- -f liste : sélectionne des champs numérotés, séparés par un délimiteur.
- -d « caractère » : définit le séparateur de champs (par défaut tabulation).
- –complement : renvoie tout sauf les positions ou les champs indiqués.
La liste suit une notation compacte : 1,3,5 pour les positions 1,3 et 5, 2-4 pour de 2 à 4, -3 pour tout jusqu’à 3, 7- pour 7 jusqu’à la fin. Sur des exports de supervision, cette notation permet de jouer rapidement avec des sous-ensembles de colonnes sans réécrire de scripts en boucle. Une équipe qui monitore des passerelles a, par exemple, isolé en quelques commandes les colonnes liées au RSSI et à la qualité radio, simplement en testant plusieurs combinaisons de -f sans toucher au reste du système.
Cut et extraction de champs avec délimiteurs dans les fichiers texte
Dès qu’un fichier texte possède des colonnes séparées par un caractère régulier, cut -f devient le bon outil. Les CSV, TSV, exports de base de données ou listes d’utilisateurs Unix y passent sans broncher. Le cœur du sujet reste alors le choix du bon délimiteur et l’indexation des champs.
Pour un fichier capteurs.csv contenant :
id;site;type;valeur;unite
c001;Lille;temp;21.3;C
c002;Arras;hygro;45.2;%
Extraire uniquement l’identifiant et la valeur revient à écrire :
cut -d « ; » -f 1,4 capteurs.csv
Cette commande renvoie :
id;valeur
c001;21.3
c002;45.2
Dans un atelier mécanique, un responsable production a adopté cette approche pour refiler à un technicien qualité un CSV réduit aux colonnes utiles, plutôt que l’export brut à 40 colonnes. Quelques lignes de shell avec cut ont remplacé un tableur partagé qui dérivait lentement, ce qui a eu un effet direct sur le temps de validation des lots.
Combiner cut avec tail, grep et les pipelines shell
Cut prend tout son sens une fois intégré dans une chaîne de commande Linux. Le trio classique tail | grep | cut couvre à lui seul une grande partie des diagnostics au pied d’une machine. C’est d’autant plus vrai si l’on sait déjà suivre un fichier avec tail sous Linux.
Exemple sur un log applicatif contenant des lignes comme :
2026-02-09 14:21:03;GW-12;TEMP;21.7;OK
Pour suivre uniquement le timestamp et le code capteur sur les dernières lignes :
tail -f app.log | grep « TEMP » | cut -d « ; » -f 1,2
Résultat :
2026-02-09 14:21:03;GW-12
Sur une passerelle IoT dans une salle de réunion connectée, ce genre de ligne en direct sur le terminal donne une vision rapide des trames utiles sans être noyé dans le reste. C’est moins joli qu’un dashboard Grafana, mais pour remettre un équipement d’aplomb pendant qu’une réunion tourne mal, cette sobriété vaut de l’or.
Zones de texte fixe : cut avec positions de caractères ou d’octets
Certains formats issus d’outils anciens ou de systèmes temps réel s’appuient encore sur des zones à longueur fixe. Dans ce cas, les options -c ou -b deviennent pertinentes, car les champs sont alignés en colonnes, sans délimiteurs apparents. Cela se rencontre encore dans des exports SCADA et dans des journaux historiques migrés sans conversion.
Pour une ligne du type :
GW12 20260209 142103 TEMP 21.7 OK
Supposons que les caractères 1 à 4 contiennent l’identifiant de passerelle, et les caractères 20 à 23 le type de mesure. Il suffit de :
cut -c 1-4,20-23 fichier.log
On obtient alors :
GW12 TEMP
Cette précision par indices devient très utile lorsqu’une équipe récupère des fichiers dont le format n’est pas documenté. Quelques essais successifs avec cut permettent de cartographier les positions intéressantes sans écrire de parser dédié. Une fois cette cartographie faite, il devient simple de bâtir un script shell qui décapsule ces données vers un format moderne.
Tableau récapitulatif des usages cut sur Linux
Pour gagner du temps au quotidien, un tableau synthétique aide souvent à choisir entre les différentes options de cut selon la situation rencontrée.
| Contexte | Commande cut typique | Objectif principal |
|---|---|---|
| CSV simple avec point-virgule | cut -d « ; » -f 1,3 fichier.csv | Extraire 2 colonnes bien identifiées |
| Logs avec colonnes fixes | cut -c 1-4,20-30 app.log | Isoler l’ID appareil et le type d’évènement |
| Fichier TSV (tabulations) | cut -f 2-4 mesures.tsv | Récupérer un bloc de champs contigus |
| Nettoyer une sortie de commande | commande | cut -d » » -f 1 | Ne garder que la première colonne texte |
| Logs avec colonnes inutiles | cut –complement -d « ; » -f 4-6 log.csv | Supprimer un groupe de colonnes superflues |
Dans une architecture plus large, où des données montent vers un serveur de messagerie ou vers un cloud, ce tableau sert souvent de pense-bête aux équipes support. Elles savent vite comment « raboter » une sortie verbeuse avant de l’envoyer à un collègue ou à un prestataire, un peu comme on nettoie des entêtes avant de partager une capture d’écran.
Bonnes pratiques cut dans les scripts shell et pipelines IoT
Dans un script de production, quelques habitudes autour de cut évitent des surprises. D’abord, ne pas supposer que le séparateur sera toujours le même : expliciter systématiquement -d pour les fichiers qui ne sont pas des TSV. Ensuite, documenter dans un commentaire la signification des indices de champs ou des plages de caractères. Trois mois plus tard, ce petit effort fait la différence entre un script maintenu et un script réécrit en urgence.
Une équipe qui administre une flotte de passerelles a par exemple standardisé un petit patron dans ses scripts :
# colonne 1 = timestamp, 2 = id capteur, 3 = type, 4 = valeur
cut -d « ; » -f 1-4 mesures.csv
Ils ont aussi posé une règle simple : dès qu’un nouveau type d’export arrive, quelqu’un passe cinq minutes à tester cut sur un échantillon pour valider le format. Ce temps investi évite ensuite les discussions interminables sur « qui a cassé quoi » quand une intégration vers un outil web plante en silence. Cela rejoint une démarche plus large d’architecture, du capteur au cloud, que l’on retrouve détaillée dans l’analyse sur l’architecture IoT du capteur au cloud.
Checklist pratique pour utiliser cut efficacement sur Linux
Pour rendre l’usage de cut Linux reproductible dans une équipe, une petite liste de contrôle suffit souvent. Elle peut vivre dans un wiki interne ou dans un répertoire « utils » partagé. Voici un exemple de checklist opérationnelle adaptée aux administrateurs et développeurs :
- Vérifier d’abord le séparateur réel du fichier (point-virgule, virgule, tabulation, pipe) avec un simple affichage des premières lignes.
- Utiliser toujours -d avec -f pour éviter les comportements implicites (tabulation par défaut).
- Tracer rapidement la structure en affichant plusieurs combinaisons de -f (par exemple 1-3, puis 4-6) sur un petit échantillon.
- Préférer -c à -b quand l’UTF‑8 et les caractères accentués entrent en jeu.
- Documenter les positions de champs et les plages de caractères dans vos scripts shell pour faciliter la reprise par un tiers.
Une fois cette discipline installée, cut cesse d’être vu comme un petit outil obscur du monde Unix et devient une brique temps réel dans les routines de surveillance. On le retrouve parfois caché derrière un alias shell qui formate joliment des logs pour un opérateur, ou inséré dans une chaîne qui prépare un jeu de données avant import dans un ERP.
Comment choisir entre cut, awk et sed pour traiter un fichier texte sous Linux ?
Cut est adapté quand les champs sont bien délimités ou les positions fixes clairement connues, et que l’objectif se limite à extraire ou supprimer des colonnes. Awk devient plus pertinent dès qu’il faut appliquer des conditions, faire des calculs ou réorganiser les champs. Sed vise plutôt les substitutions et réécritures de lignes. En pratique, on commence souvent par cut pour les cas simples, puis on passe à awk quand la logique dépasse l’extraction pure.
Pourquoi cut ne gère pas correctement certains fichiers CSV complexes ?
La commande cut ne connaît qu’un seul délimiteur simple, défini par -d, et n’interprète pas les guillemets ou les champs contenant le délimiteur lui-même. Les CSV avec des valeurs entre guillemets qui contiennent des virgules, des sauts de ligne ou des séparateurs internes sortent donc du cadre de cut. Dans ces cas-là, un parseur CSV dédié (Python, outils ETL, bibliothèques spécialisées) est plus sûr, surtout pour des imports critiques.
Comment utiliser cut avec un flux en temps réel dans le terminal Linux ?
Pour traiter un flux continu, on place cut à la fin d’un pipeline qui commence souvent par tail -f ou par la sortie d’un démon. Par exemple : tail -f app.log | grep ‘TEMP’ | cut -d ‘;’ -f 1,4. Cut travaille alors ligne par ligne à mesure que les données arrivent. Cette approche convient bien pour filtrer un log verbeux ou surveiller un champ particulier sans stocker l’intégralité du flux.
Cut fonctionne-t-il correctement avec les caractères accentués en UTF‑8 ?
L’option -c de cut travaille sur les caractères logiques, ce qui gère correctement la plupart des cas en UTF‑8, accents compris. En revanche, l’option -b agit au niveau des octets et peut couper un caractère accentué en plein milieu, donnant des résultats illisibles. Pour les textes multilingues ou contenant des symboles spéciaux, il est donc recommandé d’utiliser -c plutôt que -b, ou de valider les découpes sur un échantillon représentatif.
Peut-on s’appuyer sur cut dans des scripts critiques en production ?
Oui, à condition de maîtriser et de figer le format des fichiers en entrée. Cut est stable, rapide et très léger, ce qui en fait un bon candidat pour des scripts système ou des routines de supervision. La vraie fragilité vient des changements de format en amont (colonnes ajoutées, séparateur modifié) qui peuvent casser silencieusement la logique de sélection. D’où l’intérêt de documenter les formats, de prévoir quelques tests de cohérence et de surveiller les modifications d’exports dans le temps.
