Si un script copié depuis Windows semble normal mais que macOS signale un « bad interpreter » ou se comporte comme si les commandes contenaient un caractère supplémentaire, vérifiez la présence de fins de ligne CRLF Windows. Les outils de ligne de commande macOS attendent LF. Vous pouvez confirmer le type de fichier, convertir une copie à l'aide d'outils déjà présents sur macOS, puis réexécuter le script réparé.

Pourquoi les fins de ligne bloquent un script sur macOS

Une fin de ligne est un caractère (ou une paire de caractères) marquant la fin d'une ligne de texte. Les outils de ligne de commande macOS utilisent LF (\n) ; Windows utilise couramment CRLF (\r\n). Avec CRLF, le retour chariot peut rester attaché à une ligne lorsqu'une commande Unix la lit. Apple indique que ce caractère supplémentaire peut entraîner un comportement inattendu dans les outils en ligne de commande et les scripts. Guide de script shell d'Apple

Parmi les indices courants, on trouve /bin/bash^M: bad interpreter, un message « command not found » qui semble inclure un \r final, ou une analyse syntaxique qui échoue alors même que le script visible semble correct. Ces symptômes peuvent avoir d'autres causes ; vérifier le fichier est une première étape utile, pas une preuve en soi.

Vérifier le format de fin de ligne du script

Ouvrez Terminal, accédez au dossier contenant le script et inspectez-le avec file. Mettez le nom de fichier entre guillemets afin que les espaces et les métacaractères du shell soient traités littéralement :

cd "$HOME/Downloads"
file "my script.sh"

Si la sortie indique que le fichier possède des terminateurs de ligne CRLF, cela confirme le diagnostic. Si elle signale LF, les fins de ligne ne sont peut-être pas en cause. La description de la commande file de macOS peut varier, et les fins de ligne mixtes peuvent ne pas être résumées clairement ; appuyez-vous donc également sur le message d'erreur et le contexte source du script. Pour inspecter les octets d'une ligne spécifique, macOS inclut également od ; par exemple :

od -An -tx1 -c "my script.sh" | head

Une séquence 0d 0a représente CRLF ; 0a seul correspond à LF. Ne traitez pas un retour chariot situé ailleurs dans le fichier comme une fin de ligne sans vérifier sa position.

Convertir CRLF en LF sans écraser l'original

La documentation macOS d'Apple note que dos2unix n'est pas inclus avec macOS et recommande d'utiliser plutôt tr ou sed. Pour un script CRLF, supprimez les caractères de retour chariot vers un fichier distinct, en conservant l'original comme sauvegarde :

cp -p "my script.sh" "my script.sh.bak"
tr -d '\r' < "my script.sh" > "my script.lf.sh"
file "my script.lf.sh"

Cela convient lorsque les retours chariot indésirables sont des caractères de fin de ligne Windows. Cela supprime chaque octet CR du fichier ; évitez donc cette méthode si le fichier utilise intentionnellement des retours chariot en tant que données. La redirection vers un fichier de sortie distinct évite également de tronquer l'entrée : rediriger directement vers le même fichier peut l'effacer avant que la conversion ne se termine.

Vérifiez le nouveau fichier avant de remplacer quoi que ce soit. Si le contenu semble correct et que file signale des fins de ligne LF, essayez de l'exécuter avec l'interpréteur prévu. Pour un script Bash, par exemple :

bash "my script.lf.sh"

L'exécuter via bash ne nécessite pas le bit d'autorisation d'exécution ni un shebang fonctionnel. Si vous devez l'exécuter directement avec ./my script.lf.sh, rendez-le exécutable et assurez-vous que sa première ligne mentionne un interpréteur disponible, tel que #!/bin/bash :

chmod +x "my script.lf.sh"
"./my script.lf.sh"

Une fois le fichier réparé vérifié, vous pouvez remplacer l'original dans le Finder ou le Terminal. Conservez la copie .bak jusqu'à ce que le script fonctionne comme prévu. Si le script fait partie d'un projet partagé, appliquez la même correction de fin de ligne dans son éditeur source ou dans le flux de travail du dépôt afin que le problème ne réapparaisse pas lors du prochain enregistrement du fichier.

Si l'erreur persiste

Si file indiquait déjà LF, ou si la conversion n'a pas résolu le problème, lisez attentivement l'erreur exacte et vérifiez l'interpréteur nommé sur la première ligne. Un interpréteur manquant, un chemin non valide, une erreur de syntaxe ou l'absence d'autorisation d'exécution peuvent produire des erreurs similaires. Le script peut également dépendre de commandes ou de fonctionnalités shell indisponibles dans l'interpréteur qu'il spécifie.

TextEdit peut ouvrir et enregistrer des documents en texte brut, mais le guide de TextEdit documenté par Apple ne mentionne aucun sélecteur de fin de ligne. Pour cette réparation, utilisez la méthode de conversion du Terminal ci-dessus ou un éditeur de code qui affiche explicitement et permet de modifier les fins de ligne ; vérifiez le fichier enregistré par la suite. Guide TextEdit d'Apple

La démarche appropriée est la suivante : identifier le format du fichier, conserver une sauvegarde, convertir uniquement lorsque CRLF est présent, et réexécuter en utilisant l'interpréteur prévu. Cela permet d'appliquer la correction uniquement au fichier concerné sans modifier de scripts non liés.

Sources