Je pense que j'ai rencontré un bogue dans un fichier de commandes car il a été écrit avec des fins de ligne Unix. Est-ce un problème connu avec cmd.exe exécutant des fichiers batch dans Windows?
Je pense que j'ai rencontré un bogue dans un fichier de commandes car il a été écrit avec des fins de ligne Unix. Est-ce un problème connu avec cmd.exe exécutant des fichiers batch dans Windows?
Réponses:
Ce n'est vraiment pas un "bug" ... car c'est une conception intentionnelle. Les nouvelles lignes Windows sont définies comme "\ r \ n" ... ou une combinaison "Retour chariot" et "Nouvelle ligne" ... tandis que les versions * nix préfèrent omettre le retour chariot. Vous devez toujours utiliser "\ r \ n" dans n'importe quoi dans Windows lorsque cela est possible. Tout le reste peut être interprété incorrectement ... et entraîner de nombreux résultats inattendus.
Pour les fichiers batch, il ne semble pas y avoir de différence entre les fins de ligne Unix et les fins de ligne Windows.
goto
, call
ou même la création de variables de saut de ligne fonctionne avec les deux styles.
Et comme l'analyseur par lots supprime les retours chariot directement après la phase d'expansion en pourcentage, ils ne joueront jamais un grand rôle.