Internal field separator en Bash : comprendre IFS et l’utiliser sans erreur
Sommaire
L’Internal Field Separator en Bash, ou IFS, est une variable spéciale qui définit comment Bash découpe une chaîne en plusieurs champs. Par défaut, il s’appuie sur l’espace, la tabulation et le saut de ligne. C’est une notion simple en apparence, mais essentielle dès que vous manipulez du texte, des lignes de fichiers, des listes de valeurs ou des scripts d’automatisation.
Bien utilisé, l’IFS vous aide à lire proprement un CSV simple, un fichier système, une ligne de log ou une variable contenant plusieurs valeurs. Mal utilisé, il peut au contraire provoquer des découpages inattendus, supprimer des espaces utiles ou casser un script sans message d’erreur évident. Voici donc l’essentiel pour comprendre l’internal field separator en Bash, l’adapter correctement et éviter les pièges les plus fréquents.
Internal field separator : définition simple de l’IFS en Bash
L’IFS indique à Bash où séparer une chaîne en plusieurs morceaux, appelés champs. C’est une variable de découpage, utilisée dans plusieurs situations :
- avec
readpour répartir une ligne dans plusieurs variables ; - dans certaines expansions de variables ;
- dans les boucles qui parcourent des listes de valeurs ;
- lors de la lecture de fichiers structurés simplement.
Autrement dit, si une chaîne contient plusieurs éléments séparés par un caractère connu, l’internal field separator permet à Bash de les isoler automatiquement.
À quoi sert l’Internal Field Separator ?
L’intérêt principal de l’IFS est de transformer une ligne brute en données exploitables. Par exemple :
ligne="Sophie Martin sophie@example.com"
IFS=' ' read -r prenom nom email <<< "$ligne"
Dans cet exemple, Bash découpe la ligne selon le séparateur défini, puis remplit les variables une par une. C’est très utile pour parser des données simples, à condition de bien maîtriser le format d’entrée.
Quelle est la valeur par défaut de l’IFS en Bash ?
Par défaut, l’IFS contient :
- l’espace ;
- la tabulation ;
- le saut de ligne.
Cela signifie que Bash considère ces caractères comme des séparateurs “naturels”. Dans la plupart des cas, c’est pratique. Mais cette logique peut devenir problématique si vos données contiennent des espaces significatifs, comme dans un nom de fichier, une phrase ou une colonne texte.
Pourquoi l’IFS peut changer le résultat d’un script Bash ?
Parce qu’il influence le découpage automatique. Si vous modifiez l’IFS sans précaution, Bash peut :
- couper une valeur au mauvais endroit ;
- supprimer des espaces en début ou fin de ligne ;
- regrouper ou disperser des champs différemment ;
- affecter les variables de travers.
Un script peut alors sembler fonctionner, mais produire des résultats incohérents. C’est ce qui rend l’internal field separator à la fois utile et sensible.
Comment fonctionne l’Internal Field Separator avec read et les variables
Le cas d’usage le plus courant de l’IFS, c’est read. C’est aussi le plus important à comprendre si vous voulez écrire des scripts Bash fiables.
Utiliser IFS avec read pour découper une ligne
Exemple simple avec une virgule :
ligne="Paul,Dupont,paul@example.com"
IFS=',' read -r prenom nom email <<< "$ligne"
Ici :
IFS=','dit à Bash de découper sur la virgule ;readrépartit les champs dans les variables ;-révite que les backslashes soient interprétés.
Résultat :
prenom=Paulnom=Dupontemail=paul@example.com
C’est une syntaxe compacte et très fréquente dans les scripts de traitement de données.
Que se passe-t-il s’il y a plus de champs que de variables ?
Si la ligne contient plus de champs que de variables, Bash met généralement le surplus dans la dernière variable. Par exemple :
ligne="a,b,c,d"
IFS=',' read -r x y z <<< "$ligne"
On obtient :
x=ay=bz=c,d
Ce comportement est important à connaître, car il peut être utile pour récupérer “le reste de la ligne”, mais il peut aussi surprendre si vous attendiez un découpage strict.
Pourquoi utiliser read -r avec l’IFS ?
read -r est fortement recommandé, car il empêche Bash de traiter les backslashes comme des caractères d’échappement. C’est plus sûr pour lire des données brutes, notamment :
- des chemins ;
- des logs ;
- des fichiers de configuration ;
- des lignes exportées par un autre outil.
Sans -r, une barre oblique inverse peut être interprétée à tort et altérer la valeur lue.

Modifier l’IFS en Bash : exemples utiles et bonnes pratiques
Modifier l’IFS est souvent nécessaire, mais il faut le faire de manière ciblée. L’idée n’est pas de changer le comportement de tout votre script, seulement d’adapter le découpage à un cas précis.
Changer l’IFS pour lire un fichier CSV
Pour un CSV simple, l’approche classique est :
while IFS=',' read -r col1 col2 col3; do
echo "$col1 | $col2 | $col3"
done < fichier.csv
C’est propre, lisible et limité à la commande read.
Attention toutefois : cette méthode fonctionne bien pour des CSV simples, mais pas pour les CSV complexes contenant :
- des virgules dans les champs ;
- des guillemets imbriqués ;
- des retours Ă la ligne dans une cellule.
Dans ces cas, mieux vaut utiliser un outil dédié ou une vraie bibliothèque de parsing.
Utiliser IFS avec deux-points, point-virgule ou slash
L’internal field separator est aussi utile pour d’autres formats très courants :
- deux-points
:: fichiers système comme/etc/passwd, variablePATH; - point-virgule
;: exports européens ou fichiers séparés par;; - slash
/: parfois utile pour découper un chemin ou une structure d’URL.
Exemple avec un fichier type /etc/passwd :
IFS=':' read -r utilisateur motdepasse uid gid infos home shell <<< "$ligne"
Exemple avec PATH :
IFS=':' read -r dossier1 dossier2 dossier3 <<< "$PATH"
Dans ces cas, l’IFS permet de travailler rapidement sur des données structurées, sans écrire de logique de découpage lourde.
Sauvegarder et restaurer l’IFS pour éviter les bugs
Si vous devez modifier l’IFS de façon globale, pensez toujours à le restaurer :
oldIFS=$IFS
IFS=','
# traitement
IFS=$oldIFS
Encore mieux : limitez sa portée à une seule commande quand c’est possible.
IFS=',' read -r a b c <<< "$ligne"
Cette approche réduit fortement les effets de bord. C’est une bonne pratique essentielle dès que votre script devient long, partagé ou maintenu par plusieurs personnes.
Pièges fréquents avec l’Internal Field Separator en Bash
C’est souvent ici que les erreurs apparaissent. L’IFS est simple à utiliser, mais certains comportements de Bash peuvent surprendre.
IFS par défaut vs IFS personnalisé : attention aux champs vides
Avec l’IFS par défaut, les espaces et tabulations successifs sont généralement regroupés. En revanche, avec un séparateur personnalisé comme , ou ;, deux séparateurs consécutifs peuvent créer un champ vide.
Exemple :
ligne="a,,c"
IFS=',' read -r x y z <<< "$ligne"
Résultat :
x=ay=z=c
Ce détail est important, notamment pour les fichiers de données où un champ vide a du sens. C’est une différence clé entre l’internal field separator par défaut et un IFS personnalisé.
Ne pas modifier l’IFS globalement sans raison
Modifier l’IFS dans tout le script peut casser des traitements plus loin dans le code. La bonne pratique est donc de privilégier :
- une affectation locale ;
- une commande inline ;
- un scope court.
Exemple recommandé :
IFS=';' read -r champ1 champ2 champ3 <<< "$ligne"
Exemple plus risqué :
IFS=';'
# beaucoup d'autres commandes après
Dans le second cas, vous augmentez le risque d’effets inattendus.
Préserver une ligne entière avec IFS vide
Si vous voulez lire une ligne sans altérer ses espaces de début ou de fin, utilisez :
IFS= read -r ligne
C’est très utile pour :
- les logs ;
- les fichiers de configuration ;
- les lignes Ă conserver telles quelles.
Ici, l’IFS vide empêche Bash de découper ou de nettoyer la ligne. C’est un réflexe simple, mais très efficace.

Checklist IFS Bash : choisir le bon séparateur selon le cas d’usage
Pour aller vite, voici un tableau de décision simple à réutiliser.
| Cas d’usage | IFS recommandé | Exemple | Point d’attention |
|---|---|---|---|
| CSV simple | , |
IFS=',' read -r a b c |
Pas adapté aux CSV complexes |
Fichier système /etc/passwd |
: |
IFS=':' read -r ... |
Bien vérifier le nombre de champs |
Variable PATH |
: |
IFS=':' read -r ... |
Ne pas modifier l’IFS globalement |
| Export européen | ; |
IFS=';' read -r ... |
Champs vides possibles |
| Ligne brute, logs, config | vide | IFS= read -r ligne |
Préserve les espaces |
Les règles à retenir avant de modifier l’IFS
Avant d’utiliser l’internal field separator, gardez ces réflexes :
- utilisez
read -rpar défaut ; - limitez l’IFS à une commande quand c’est possible ;
- testez les champs vides ;
- restaurez l’ancienne valeur si vous modifiez l’IFS globalement ;
- évitez d’utiliser l’IFS comme solution unique pour des CSV complexes.
En pratique, l’objectif n’est pas de “jouer” avec IFS, mais de contrôler le découpage avec précision.
FAQ
Qu’est-ce que l’Internal Field Separator en Bash ?
L’Internal Field Separator, ou IFS, est une variable spéciale de Bash qui définit les caractères utilisés pour découper une chaîne en plusieurs champs. Par défaut, elle contient l’espace, la tabulation et le saut de ligne.
Quelle est la valeur par défaut de l’IFS ?
Par défaut, IFS contient trois séparateurs : l’espace, la tabulation et le saut de ligne. Ils permettent à Bash de séparer automatiquement les mots, lignes ou colonnes dans de nombreuses commandes.
Comment modifier l’IFS pour lire un fichier CSV ?
Pour un CSV simple, vous pouvez utiliser IFS=',' read -r champ1 champ2 champ3. Cette syntaxe limite la modification de l’IFS à la commande read et évite les effets de bord dans le reste du script.
Pourquoi faut-il sauvegarder l’IFS avant de le modifier ?
Sauvegarder l’IFS permet de restaurer son comportement normal après un traitement spécifique. Sans restauration, les commandes suivantes du script peuvent découper les chaînes de manière inattendue.
Ă€ quoi sert la commande IFS= read -r ligne ?
Cette syntaxe permet de lire une ligne entière sans supprimer les espaces en début ou en fin de ligne, tout en empêchant l’interprétation des backslashes grâce à -r.
En bref, l’internal field separator en Bash est une petite variable avec un impact majeur sur la fiabilité de vos scripts. Retenez trois réflexes simples : limiter sa portée, utiliser read -r, et restaurer l’IFS si vous le modifiez globalement. Si vous travaillez sur des CSV, des logs ou des fichiers système, testez toujours le comportement réel sur vos données avant de l’intégrer en production.