cut fait partie de ces petites commandes Linux qui transforment une ligne de commande un peu brouillonne en un outil chirurgical. En quelques options bien choisies, tu peux extraire une colonne précise d’un CSV, ne garder qu’un morceau d’une ligne de log ou nettoyer un flux texte qui vient d’une autre commande bash. L’idée centrale est simple : tu prends un flux de texte, tu définis comment il est structuré (par caractères, octets ou champs séparés par un séparateur), et tu demandes à cut de ne garder que ce qui t’intéresse. Pas de magie, juste une mécanique solide et prévisible, idéale pour enchaîner les traitements en ligne de commande.
Dans un environnement shell, cette commande est souvent l’un des premiers réflexes dès qu’il faut faire de l’extraction de données légère sans sortir un script Python ou un parseur JSON. Un administrateur système va par exemple cibler les colonnes de dates et d’IP dans un log Apache, un dev web va isoler un identifiant utilisateur dans un export de base, un étudiant pourra découper rapidement un fichier TSV pour un TP. En pratique, cut s’appuie sur quelques options clés comme -d pour le delimiter, -f pour les champs, -c pour les caractères et -b pour les octets. Le reste se joue sur la façon de composer ces options avec les pipes et les autres utilitaires du monde Unix.
En bref
- cut sert à extraire des portions de lignes dans des fichiers texte ou des flux standard sous Linux.
- Tu peux découper par champs avec un delimiter (option -d + -f) ou par position avec -c ou -b.
- La commande est parfaite pour manipuler rapidement CSV, TSV, logs, sorties de scripts et fichiers de configuration en bash.
- Combinée avec grep, sort, uniq ou awk, cut devient une brique efficace pour créer des mini-pipelines de traitement de texte.
- En script shell, bien choisir le séparateur et les positions à extraire apporte un gain de lisibilité et de performances.
cut sous Linux : principe, usages typiques et erreurs à éviter
Pour bien utiliser cut, le plus simple est de le voir comme un outil qui lit un flux ligne par ligne, applique une règle d’extraction sur chaque ligne, puis renvoie uniquement les morceaux demandés. La règle peut reposer sur un séparateur de champ, sur des positions de caractères ou sur des positions d’octets. Tout le reste, c’est de la déclinaison autour de ce principe. Tu peux l’appliquer aussi bien à un fichier local qu’à la sortie d’une autre commande, grâce aux pipes classiques du shell.
Un cas ultra courant : un fichier CSV qui contient par exemple un identifiant, un email, un rôle, un statut. Tu peux récupérer uniquement l’email et le rôle avec quelque chose du genre cut -d’,’ -f2,3 utilisateurs.csv. cut va prendre chaque ligne, repérer les champs séparés par la virgule, et ne garder que le 2e et le 3e champ. Sur des fichiers de dizaines de milliers de lignes, cette approche reste très rapide sans nécessiter de code supplémentaire.
Autre illustration, plus proche du quotidien des devs web : parser un log Nginx pour vérifier rapidement quelles URL renvoient un code 500. On peut d’abord filtrer les lignes avec grep » 500 « , puis utiliser cut pour viser la colonne de l’URL ou du code de réponse, selon la config du log. On obtient directement une liste exploitable pour reproduire les requêtes ou ajuster une règle de cache. Quand tu travailles sur des problématiques de debug PHP, ce genre de pipeline se marie très bien avec les approches montrées dans un tutoriel comme afficher les erreurs PHP proprement.
Il existe aussi des usages moins évidents, par exemple sur les fichiers de configuration où les champs sont séparés par des deux-points ou des espaces multiples. cut permet de cibler précisément tel bloc ou telle partie de ligne sans avoir à écrire d’expression régulière complexe. Par contre, beaucoup de débutants tombent dans un piège simple : oublier que cut se base sur un seul caractère de delimiter. Si ton fichier mélange semicolon, espaces et tabulations, il faudra souvent d’abord normaliser le format avec tr ou sed avant de sortir l’artillerie cut.
Une autre erreur classique consiste à supposer que tous les fichiers utilisent la tabulation comme séparateur de colonnes. Par défaut, cut prend effectivement la tabulation, mais en pratique, les CSV et les exports divers utilisent le plus souvent la virgule, le point-virgule ou même le pipe vertical. Oublier l’option -d dans ce contexte donne un résultat vide ou découpé n’importe comment, ce qui peut faire perdre du temps en debug alors que le problème tient à un simple caractère.
Pour finir sur cette première vue d’ensemble, un point qui mérite d’être gardé en tête : cut n’interprète pas les expressions régulières. Si tu as besoin de reconnaître un motif plus riche qu’un simple caractère de séparation, ce n’est pas l’outil idéal. Dans ce cas, mieux vaut envisager awk, perl ou un langage de script. Mais pour 80 % des scénarios de tri rapide, c’est largement suffisant, surtout quand tu commences à enchaîner avec d’autres commandes de la boîte à outils Unix.
Syntaxe détaillée de cut, options clés et tableau récapitulatif
La syntaxe officielle de la commande est compacte : cut [OPTIONS] [FICHIER…]. Si aucun fichier n’est donné, cut lit l’entrée standard. C’est cette simplicité qui rend la commande si agréable en pipeline. Ce qui change tout, ce sont les options que tu ajoutes derrière. Il faut en choisir au moins une parmi -b, -c ou -f pour définir le mode de découpe.
L’option -b permet de découper par position d’octets. C’est utile pour certains fichiers encodés en ASCII pur ou pour des formats binaires très simples. La plupart du temps, sur des textes en UTF‑8, ce n’est pas ce qui est le plus confortable, car un caractère accentué peut occuper plusieurs octets. Tu risques donc de couper au milieu d’un caractère et de te retrouver avec des sorties bizarres. Sur des logs techniques ou des fichiers systèmes en anglais, ça passe, mais sur des contenus en français c’est en général une mauvaise idée.
En pratique, on conseille plutôt -c pour couper par position de caractères. Là, tu raisonnes en colonnes visuelles : cut -c1-10 garde les 10 premiers caractères de chaque ligne, quelle que soit la valeur de ces caractères. Cette option est pratique pour les fichiers à largeur fixe ou pour tronquer des chaînes trop longues dans un rapport rapide en ligne de commande. Par exemple pour générer un aperçu, tu peux faire cut -c1-80 fichier.log et éviter une sortie qui déborde sur le terminal.
Le vrai terrain de jeu, c’est l’option -f qui travaille sur les champs. Elle attend une liste ou une plage de numéros de champs, avec un delimiter défini par -d. Une commande comme cut -d’;’ -f1,4-6 fichier.csv récupère le premier champ puis les champs 4 à 6. Tu peux mélanger valeurs unitaires et plages, dans l’ordre que tu veux, et cut réorganise la sortie selon cet ordre. Gras intéressant pour reconstruire un sous-CSV avec uniquement les colonnes utiles.
Deux options méritent que tu les ajoutes à ton arsenal. -s d’abord, qui force cut à ne traiter que les lignes contenant le séparateur. Sans ça, une ligne sans delimiter est renvoyée telle quelle, ce qui peut surprendre sur des fichiers mixtes. Ensuite –output-delimiter, très pratique pour changer la séparation dans la sortie. Tu peux lire un TSV et ressortir un CSV en une seule commande, par exemple en combinant -d’t’, -f et –output-delimiter=’,’.
Pour garder sous la main les différences entre les options, un petit tableau aide pas mal, surtout au début :
| Option | Rôle principal | Exemple d’usage cut | Remarque |
|---|---|---|---|
| -b | Découpage par octets | cut -b1-4 fichier.txt | À éviter sur du texte UTF‑8 avec accents |
| -c | Découpage par caractères | cut -c5-20 fichier.log | Adapté aux colonnes à largeur fixe |
| -d | Définit le delimiter de champ | cut -d’,’ -f2-3 fichier.csv | Un seul caractère supporté |
| -f | Choix des champs | cut -f1,4-6 data.tsv | Travaille sur les champs délimités |
| -s | Ignore les lignes sans séparateur | cut -d’:’ -f2- -s fichier.conf | Évite les lignes parasites dans la sortie |
| –output-delimiter | Change le séparateur de sortie | cut -d’;’ -f1-3 –output-delimiter=’,’ data.csv | Très utile pour convertir TSV en CSV |
Il reste une option qui peut surprendre mais qui rend parfois service : –complement. Elle inverse la sélection. Si tu demandes -f1,3 avec l’option complement, tu obtiens tous les champs sauf les 1 et 3. C’est pratique quand un fichier contient une grosse quantité de colonnes dont tu veux juste éliminer une poignée. Tu gagnes en lisibilité plutôt que d’écrire une longue liste de colonnes à garder.
En résumé, comprendre ces quelques options transforme cut en outil fiable. Une fois que tu maîtrises la logique, tu peux passer à des exemples plus réalistes, en particulier dans des scénarios de logs et d’automatisation que rencontrent tous les admins et devops à un moment ou à un autre.
Découper par champs avec delimiter : CSV, TSV, logs et fichiers systèmes
Dès qu’un fichier est « tabulaire » au sens large, le mode « champs » de cut devient la bonne option. Que ce soit un export CSV d’un outil marketing, un TSV généré par une base de données ou un fichier de mots de passe système séparés par des deux-points, le principe reste identique : définir le bon delimiter et choisir les colonnes pertinentes. L’extraction est alors nette, reproductible et très rapide.
Imagine un personnage, Nadia, admin système dans une PME qui gère une flotte de serveurs Linux. Elle reçoit chaque jour un fichier CSV contenant des statistiques d’utilisation d’une application interne. Le fichier contient une dizaine de colonnes, mais pour son reporting, elle ne veut que l’identifiant de l’équipe, le nombre de connexions et la date. Avec une seule commande, elle peut faire quelque chose comme cut -d’,’ -f2,5,7 stats.csv > rapport.csv. Les colonnes inutiles disparaissent, son fichier de sortie est propre et directement exploitable dans un script ou un tableur.
Sur des fichiers plus techniques, le jeu est un peu différent. Prenons par exemple /etc/passwd sur une distribution classique. Chaque ligne est structurée par des deux-points, et tu peux par exemple extraire le login et le répertoire personnel avec cut -d’:’ -f1,6 /etc/passwd. Pour automatiser la création d’utilisateurs, ce genre de commande se combine très bien avec des approches plus globales de gestion de comptes décrites dans un article comme les options avancées de useradd sous Linux.
Autre situation fréquente : les fichiers TSV (tab separated values), souvent utilisés par les scripts ou les bases de données. Là, cut fonctionne sans préciser de delimiter, puisque par défaut il utilise la tabulation. Il suffit donc d’écrire cut -f2,4 data.tsv pour récupérer la 2e et la 4e colonne. C’est l’un des rares cas où tu peux te passer de -d sans risquer de bug de compréhension plus tard.
Quand on passe aux logs applicatifs, il faut parfois un peu bricoler. Certains formats utilisent l’espace comme séparateur, avec des champs qui contiennent eux-mêmes des espaces entre guillemets. Pour des usages rapides, on se contente parfois de cut -d’ ‘ -f1,7 fichier.log pour récupérer par exemple l’adresse IP (champ 1) et l’URL (champ 7). Ce n’est pas parfait, mais pour du diagnostic ponctuel en bash, ça permet déjà de répondre à des questions concrètes comme « quelles routes sont les plus appelées par ce client ? ».
Il faut quand même accepter une limite : cut ne comprend pas la notion de guillemets ou de champ échappé. Si ton CSV contient des virgules à l’intérieur des valeurs, la commande ne fera pas la différence. Dans ces cas-là, pour un travail propre, mieux vaut passer sur un parseur CSV dédié, ou bien sur un langage avec une librairie adaptée. Tout dépend de la rigueur attendue dans ton pipeline.
Pour terminer sur l’aspect « modus operandi », un bon réflexe consiste à tester la commande sur quelques lignes avec head avant de la lancer sur un gros fichier. Tu peux par exemple faire head -n5 fichier.csv | cut -d’;’ -f1-3 pour vérifier que tu obtiens bien les colonnes souhaitées. Ce mini-sas de contrôle t’évitera des surprises, surtout quand tu enchaînes plusieurs traitements avec pipes.
Découper par caractères ou octets : largeurs fixes, tronquage et formats hérités
Le mode « champs » ne couvre pas tout. Certains formats de fichiers utilisent encore des colonnes à largeur fixe. D’autres scripts génèrent des sorties au kilomètre sans séparateur clair, mais avec des motifs répétitifs bien alignés. C’est là que les options -c et -b montrent tout leur intérêt pour faire de l’extraction précise sur la base de positions.
Reprenons Nadia. Elle doit auditer des journaux d’un vieux système de facturation, où chaque ligne débute par une date sur 8 caractères, suivie d’un code client sur 6 caractères, puis d’un montant aligné à droite sur une zone fixe. Pas de virgule, pas de tabulation, juste des espaces pour remplir. Pour isoler le code client, elle peut exécuter cut -c9-14 factures.log. Si elle veut à la fois le code et le montant, elle enchaîne deux plages de caractères et adapte le script qui consomme ces données.
Le mode caractères sert aussi de couteau suisse pour nettoyer des sorties un peu verbeuses. Quand une commande renvoie des lignes avec un timestamp, puis un niveau de log, puis un message, tu peux parfois réduire le bruit avec un simple cut -c25- qui supprime les 24 premiers caractères et garde uniquement le message. Sur un flux en direct via tail -f, ce genre de commande rend la lecture beaucoup plus confortable sur un petit terminal.
La variante par octets, avec -b, joue sensiblement le même rôle, mais en comptant les unités différemment. Elle devient utile lorsque tu analyses des formats où la notion de caractère ne correspond pas à celle affichée à l’écran. Par exemple, certains protocoles anciens ou des fichiers binaires simplifiés peuvent être inspectés rapidement en affichant une version hexdump, puis en ciblant certaines tranches d’octets avec cut. C’est moins fréquent en dev web, mais encore assez commun dans le monde réseau et embarqué.
On peut aussi combiner cut avec des astuces comme la commande rev pour gérer des extractions depuis la fin de la ligne. Pour récupérer les 6 derniers caractères d’une chaîne sans connaître la longueur totale, un enchaînement typique ressemble à rev fichier.txt | cut -c1-6 | rev. Tu inverses la ligne, coupes le début, puis la remets à l’endroit. C’est un peu rustique, mais très efficace dans un script shell qui ne justifie pas d’embarquer un langage complet.
Il y a aussi des usages plus créatifs. Certains développeurs s’en servent pour générer des identifiants courts à partir de hashs longs, par exemple en ne gardant que les 8 premiers caractères d’un SHA1. Dans ce cas, un simple echo « chaine » | sha1sum | cut -c1-8 suffit à obtenir un identifiant lisible. Tu vois tout de suite le parallèle avec des outils comme Git, qui affichent souvent des versions tronquées des identifiants de commit.
Cette logique par position se marie bien avec des outils de surveillance réseau ou d’analyse de trafic, notamment quand tu explores des formats historiques. Si tu as déjà touché à des captures réseau avec Wireshark, tu sais que certains champs sont alignés à l’octet. Même si tu ne vas pas remplacer un analyseur complet par cut, tu peux en complément, après un export texte, extraire certains segments précis du flux. Pour des approches plus complètes, un bon complément reste un guide comme ce tutoriel sur Wireshark et ses filtres, qui va bien au-delà de la simple découpe.
En définitive, si tu raisonnes en colonnes fixes ou en zones mémoire, -c et -b apportent une réponse simple, là où le mode champs ne suffit plus. Il suffit de rester attentif à l’encodage et à l’alignement, mais une fois ces détails réglés, ces options deviennent des alliées très fiables.
Combiner cut avec d’autres commandes bash pour des pipelines puissants
Prendre cut isolément est déjà utile, mais l’endroit où il brille vraiment, c’est en combinaison avec le reste de l’écosystème Linux. Dans un shell, tu peux empiler plusieurs commandes reliées par des pipes pour construire un traitement complexe sans fichier intermédiaire. cut joue alors un rôle de filtre, souvent placé après une commande de sélection ou de transformation.
Une combinaison ultra fréquente reste grep | cut. D’abord tu utilises grep pour garder uniquement les lignes qui t’intéressent, par exemple toutes celles qui contiennent « ERROR ». Ensuite, tu enchaînes avec cut -d’ ‘ -f1,7 pour ne ressortir que la date et l’URL. Sur des logs Nginx ou Apache, ce pattern suffit pour répondre à une bonne partie des questions courantes pendant un debug. Tu peux à la suite ajouter sort et uniq -c pour compter les occurrences, et tu obtiens un mini-outil d’analyse, directement en ligne de commande.
Autre combo très parlant : awk | cut. Dans pas mal de cas, awk seul pourrait suffire, mais certains préfèrent limiter sa complexité. Ils l’utilisent pour réorganiser ou filtrer des champs, puis délèguent à cut l’extraction finale. Par exemple, tu peux laisser awk normaliser les espaces ou remplacer un séparateur exotique par un caractère unique, puis appeler cut -d’|’ -f2-4 derrière. Ce genre de pas-à-pas rend le pipeline lisible même pour quelqu’un qui lit ton script une première fois.
Dans des scripts plus structurés, cut intervient aussi pour manipuler des sorties de commandes systèmes. Une commande comme df -h ou ps aux produit des colonnes qu’il est tentant de découper à la main. Certains outils possèdent déjà des options de formatage, mais quand ce n’est pas suffisant, cut permet de se fabriquer une vue synthétique rapide. Sur un serveur de prod, ça peut faire la différence entre un diagnostic qui traîne et une réaction rapide.
Tu peux aussi utiliser cut pour préparer des données qui seront ensuite consommées par un autre outil graphique ou une interface web. Dans un pipeline d’ETL maison, par exemple, cut extrait des colonnes précises d’un fichier brut, puis un script PHP ou Python charge le résultat dans une base. Cette façon de chaîner des outils simples rappelle le modèle Unix originel, où chaque brique fait une chose et la fait bien, un peu comme les premières générations de systèmes décrits dans les analyses autour des origines de Windows et Linux.
Pour que ces pipelines restent maintenables, quelques bonnes pratiques valent la peine d’être notées :
- Utiliser des variables explicites pour les delimiter (par exemple SEP=’,’ puis cut -d »$SEP » -f…).
- Documenter les positions de champs dans un commentaire quand le fichier d’entrée n’est pas auto‑documenté.
- Tester les transformations étape par étape avec head ou sed -n ‘1,5p’ pour vérifier le comportement.
- Éviter d’empiler trop de cut successifs au profit d’un seul appel bien configuré.
Avec cette démarche, tu construis des chaînes lisibles, qui restent compréhensibles plusieurs mois plus tard. cut cesse alors d’être un hack ponctuel pour devenir une brique stable dans ton outillage de scripts.
Cas pratiques, scripts shell et astuces de productivité autour de cut
Pour finir, rien ne vaut quelques scénarios complets pour voir comment cut s’intègre dans des workflows réels. Prenons par exemple une équipe qui gère un petit cluster de serveurs applicatifs. Elle souhaite générer chaque matin un rapport listant les 20 URL les plus appelées la veille avec leur nombre de hits. La base, c’est un log Nginx. Un script simple peut enchaîner grep pour filtrer sur la date du jour précédent, cut pour isoler l’URL, puis sort et uniq pour compter, le tout en quelques lignes de bash.
Un squelette typique pourrait ressembler à : on commence avec grep « 2026-05-14 » access.log, puis on passe la sortie à cut -d’ ‘ -f7 pour obtenir uniquement la colonne des chemins. Ensuite on trie, on compte, on retrie par nombre décroissant, et on redirige le résultat dans un fichier HTML basique servi par une page interne. Chaque brique reste légère, et cut joue un rôle central dans la sélection du bon champ au bon moment.
Autre cas de figure, très courant en dev web : manipuler des exports issus d’outils tiers. Tu récupères un CSV avec 40 colonnes, mais ton script ne doit en consommer que 5. Plutôt que de charger tout le fichier dans un langage haut niveau pour le réécrire, tu peux insérer une étape cut dans ton pipeline CI. La sortie de cette étape devient l’entrée de ton script applicatif, qui est alors débarrassé du bruit. Tout se passe dans un simple job shell, rapide à exécuter et facile à maintenir.
cut sert aussi beaucoup dans les tâches d’administration de fichiers eux-mêmes. Couplé avec des commandes comme ls ou find, il permet par exemple de cibler seulement certaines parties de chemins ou de noms pour renommer en masse. Même si des commandes plus spécialisées existent pour renommer des fichiers sous Linux, cut reste une corde utile pour extraire un préfixe ou un suffixe lors de petites opérations ponctuelles.
Pour maximiser la productivité, plusieurs astuces reviennent souvent chez les utilisateurs avancés. D’abord, garder dans un fichier de snippets les commandes cut les plus utilisées, par exemple pour analyser des logs ou nettoyer des exports CSV. Ensuite, adopter une convention claire sur les noms de variables et sur les commentaires qui décrivent la structure d’entrée (liste des colonnes, type de séparateur, etc.). Enfin, quand un pipeline commence à devenir long, ne pas hésiter à le basculer dans un script dédié avec des fonctions nommées, plutôt que de le laisser enfoui dans une ligne trop dense.
On peut aussi voir cut comme un bon moyen d’enseigner progressivement la puissance de la ligne de commande. Pour quelqu’un qui découvre Linux, écrire ses premiers cut -d’,’ -f2 sur un petit fichier d’exemple donne un retour immédiat, sans nécessiter de notions poussées de programmation. Cette approche pédagogique prépare ensuite le terrain pour des outils plus complexes comme awk, sed ou même des scripts complets. En gros, cut agit comme une porte d’entrée accessible vers un univers de traitement de texte automatisé.
Une fois qu’on a pris l’habitude de l’intégrer au quotidien, il devient rare de ne pas y penser dès que l’on voit un tableau brut, un export maladroit ou un log un peu fouillis. Et dans un métier où le temps passé à manipuler les données « à la main » finit toujours par exploser, chaque commande maîtrisée comme celle-ci fait une vraie différence dans la durée.
Quelle différence entre cut -b et cut -c sous Linux ?
cut -b découpe par octets, tandis que cut -c découpe par caractères. Sur des fichiers en UTF‑8 avec accents, -b peut couper au milieu d’un caractère et produire une sortie illisible. Pour du texte classique, il vaut mieux privilégier -c, et réserver -b à des cas très techniques où la notion d’octet compte vraiment, comme certains formats binaires ou exports hexadécimaux.
Comment changer le séparateur utilisé par cut pour les champs ?
Par défaut, cut utilise la tabulation comme séparateur de champs. Pour changer ce comportement, il faut utiliser l’option -d suivie du caractère de delimiter, par exemple -d’,’ pour des CSV ou -d’;’ pour des exports point‑virgule. Cette option se combine ensuite avec -f pour choisir les champs à extraire.
Est-ce que cut sait gérer les guillemets des fichiers CSV ?
Non, cut ne comprend pas la logique des guillemets ni l’échappement des virgules au sein des champs. Il se contente de repérer un caractère de séparateur et de découper en conséquence. Si un fichier CSV contient des valeurs avec des virgules intégrées, il faut utiliser un parseur CSV dédié ou un langage avec une bibliothèque spécialisée pour obtenir un résultat fiable.
Peut-on utiliser plusieurs séparateurs en même temps avec cut ?
cut ne supporte qu’un seul caractère de séparateur par exécution. Si un fichier mélange plusieurs séparateurs, il faut d’abord le normaliser, par exemple avec tr ou sed, pour transformer toute la structure vers un seul caractère, puis appeler cut avec ce caractère comme delimiter. Cette étape de nettoyage rend ensuite l’extraction de champs prévisible.
Quand faut-il préférer awk à cut en ligne de commande ?
cut est très adapté pour extraire des colonnes simples ou des plages de caractères sans logique conditionnelle. Dès que tu as besoin de tester des valeurs, de recalculer des champs, de filtrer en fonction de critères complexes ou de gérer des formats plus ambigus, awk offre davantage de contrôle. En pratique, beaucoup de scripts combinent les deux : cut pour l’extraction simple, awk pour les transformations plus avancées.
