Quels sont ces ^ M qui continuent à apparaître dans mes fichiers dans emacs?

157

Donc, je pense que cela peut avoir à voir avec textmate, mais nous travaillons dans une petite équipe et avons des problèmes avec des conflits de fichiers complets de fichiers presque identiques dans git parce que chaque ligne d'une branche a un ^ M ajouté.

Qu'est-ce que ce ^Mpersonnage mystérieux est censé faire et d'où pourrait-il venir?

Nos développeurs utilisent emacs sur Windows / Mac, TextMate sur Mac, coda sur Mac et occasionnellement l'éditeur de texte wp-admin.

Quelqu'un a-t-il déjà eu ce problème à cause de l'un de ces problèmes?

git emacs newline

— Neil Sarkar
source

3

Pour ce que ça vaut: recherchez "ctrl" au lieu de ^

— Broam

3

Le plus gros problème est, qu'allez-vous faire à ce sujet? Il y a de fortes chances qu'Emacs ne les présente pas. Votre équipe doit décider si les fichiers doivent être au format DOS (avoir ^ M) ou Unix (pas ^ M), et appliquer cela.

— Trey Jackson

111

Dans git-config , définissez core.autocrlfsur truepour que git convertisse automatiquement les fins de ligne correctement pour votre plate-forme, par exemple, exécutez cette commande pour un paramètre global:

git config --global core.autocrlf true

— Josh Lee
source

6

Je pense que c'est la meilleure réponse car elle répond à la question dans le contexte de l'OP, à savoir git.

— neontapir

J'avais déjà "[core] \ n autocrlf = true" dans mon fichier '~ / .gitconfig', mais cela me laissait toujours 'git clone code.google.com/p/pytomtom ' avec les caractères '^ m' ??? ??

— Big Rich

11

Cette réponse s'applique UNIQUEMENT si votre plate-forme est Windows! Si vous travaillez sous Mac / Linux, "true" devrait devenir "input"! Voir help.github.com/articles/dealing-with-line-endings et ici: stackoverflow.com/questions/9225599/...

— K.-Michael Aye

AVERTISSEMENT: cette réponse corrompt alors beaucoup d'autres fichiers lorsque git "devine" incorrectement que les fins de ligne sont sans importance et doivent être modifiées. C'est mortel pour les projets logiciels où ces personnages existent dans un fichier de données (oui, j'ai été brûlé par ça, douloureux à défaire). C'est une solution terrible à mon humble avis.

— Adam

@Adam Qu'est-ce qui brise exactement le changement de fin de ligne? Où avez-vous rencontré des problèmes lorsque vous travaillez avec des données? Cela ne devrait rien affecter, c'est juste une façon différente de marquer la fin de la ligne. Je me demande seulement.

— MBI

97

Quelqu'un ne convertit pas correctement ses caractères de fin de ligne .

Je suppose que ce sont les gens de Windows qui aiment leur CRLF. Unix aime LF et Mac adorait CR jusqu'à ce qu'il soit montré à la manière Unix.

— Broam
source

12

Pour clarification: Mac utilisait CR jusqu'à la version 10 (OS X), maintenant il utilise LF.

— Mikael S

34

Je pense que la manière Windows est plus logique, puisque les termes CR et LF viennent de l'époque des machines à écrire. Vous deviez faire les deux: un retour chariot pour obtenir le point de saisie au début de la ligne et un saut de ligne pour faire défiler une ligne vers le bas. La méthode classique de Mac OS (CR) sur une machine à écrire continuerait à écraser la même ligne. La méthode Unix (LF) sur une machine à écrire produirait du texte décalé jusqu'à ce que vous atteigniez la pleine largeur de la page. :)

— Otherside

114

@Otherside: plus logique uniquement dans le sens "on veut émuler une machine à écrire". Je ne peux pas commencer à comprendre pourquoi cela est même plus utile à distance.

— Bryan Oakley

29

@Otherside pourquoi représenteriez-vous quelque chose avec deux caractères alors qu'il peut être représenté avec un seul caractère?

— Matthew G

13

@Matthew G: Tout peut être représenté dans un seul personnage, à condition que nous soyons nombreux à être d'accord. Cela veut-il dire que nous devrions? Nous pouvons taper tous nos messages sans ponctuation, majuscules et juste chaque phrase sur une nouvelle ligne, et tout le monde le comprendrait. Cela veut-il dire que nous devrions? Il ne s'agit pas de «faire quelque chose parce que nous le pouvons». Cela dit, je préfère aussi le LF.

— jaffog

33

^Mis 0x0d, c'est-à-dire le caractère de retour chariot. Si votre écran ressemble à

ligne 1 ^ M
ligne 2 ^ M

alors le fichier doit provenir de Windows car la séquence de saut de ligne standard sous Windows est CR LF( 0x0d 0x0a) alors que la séquence de nouvelle ligne standard consiste uniquement LFen Unices.

Si le fichier provenait d'un système Mac OS 9 ou antérieur, vous le verriez comme

ligne 1 ^ Mline 2 ^ M

car il n'y aurait aucun saut de ligne après les retours chariot.

— Sinan Ünür
source

28

Pour faire disparaître ^ M dans git, tapez:

git config --global core.whitespace cr-at-eol

Crédits: https://lostechies.com/keithdahlby/2011/04/06/windows-git-tip-hide-carriage-return-in-diff/

— bonif
source

1

ne change rien.

— Vivex

3

cela fait seulement disparaître le ^ M de l'affichage lorsque vous utilisez git diff mais il est toujours là

— FernandoZ

1

En effet, il n'affiche le ^ M que sous forme d'espace, mais git diffprend toujours en compte le ^ M lors de la comparaison de fichiers. Supprimez ce paramètre avec git config --global --unset core.whitespace(de ce fil ).

— miguelmorin

1

Vous pouvez également omettre le --globalpour configurer simplement le dépôt actuel.

— Derek Veit

8

Ils ont à voir avec la différence entre les fins de ligne de style DOS et le style Unix. Consultez l'article Wikipédia . Vous pourrez peut-être trouver un outil dos2unix pour vous aider, ou simplement écrire un petit script pour les corriger vous-même.

Edit : J'ai trouvé l'exemple de code Python suivant ici :

string.replace( str, '\r', '' )

— Parappa
source

3

Dans Emacs, ce serait <code> M-: (replace-string "\ r" "") </code>.

— huaiyuan

7

J'utilise Android Studio (JetBrains IntelliJ IDEA ) sur Mac OS et mon problème était que ^ M a commencé à apparaître dans certains fichiers de ma demande d'extraction sur GitHub . Ce qui a fonctionné pour moi était de changer le séparateur de ligne pour un fichier.

Ouvrez le fichier souhaité dans l'éditeur, allez dans Fichier, allez dans Séparateurs de lignes puis choisissez la meilleure option pour vous (pour moi, c'était LF - Unix et OS X (\ n) )

Selon l'article suivant, ce problème est le résultat de fins de ligne confuses entre les systèmes d'exploitation: http://jonathonstaff.com/blog/issues-with-line-endings/

Et plus d'informations vous pouvez trouver ici: https://www.jetbrains.com/help/idea/configuring-line-separators.html#d84378e48

— CookieMonster
source

6

au lieu de query-replace, vous pouvez également utiliser Mx delete-trailing-whitespace

— kaineer
source

cela n'a pas fonctionné pour moi ... J'ai sélectionné tout le texte et exécuté la commande.

— 的 devrimbaris

cela a fonctionné pour moi. Merci. @devrimbaris, vous n'avez rien à sélectionner, vous exécutez simplement la commande. «M» est la touche méta ou la touche d'échappement. Donc Mx est échapper alors x. Ensuite, vous tapez dans delete-trailing-whitespace, et appuyez sur retour.

— astromax

5

Mettez ce qui suit dans votre ~/.emacs(ou votre eqiuvalent)

(defun dos2unix ()
  "Replace DOS eolns CR LF with Unix eolns CR"
  (interactive)
    (goto-char (point-min))
      (while (search-forward "\r" nil t) (replace-match "")))

et alors vous seriez en mesure d'utiliser simplement M-x dos2unix.

— Jakub Narębski
source

4

^Mà la fin de la ligne dans Emacs indique un retour chariot (\ r) suivi d'un saut de ligne (\ n). Vous verrez souvent cela si une personne édite des fichiers sous Windows (où la fin de ligne est la combinaison de caractères de retour chariot et de nouvelle ligne) et que vous éditez sous Unix ou Linux (où la fin de ligne n'est qu'un caractère de nouvelle ligne).

La combinaison de caractères n'est généralement pas nuisible. Si vous utilisez le contrôle de source, vous pourrez peut-être configurer le format d'archivage du fichier texte afin que les lignes soient ajustées comme par magie pour vous. Vous pouvez également utiliser des déclencheurs d'archivage et d'extraction qui «corrigent» automatiquement les fichiers pour vous. Ou, vous pouvez simplement utiliser un outil comme dos2unix pour ajuster manuellement les choses.

— atk
source

2

Comme tout le monde l'a mentionné. C'est un style de fin de ligne différent. MacOSX utilise les fins de ligne Unix - c'est-à-dire LF (saut de ligne).

Windows utilise à la fois CR (retour chariot) et LF (saut de ligne) comme fin de ligne. Puisque vous utilisez à la fois Windows et Mac, c'est de là que vient le problème.

Si vous créez un fichier dans Windows et que vous le placez ensuite sur le mac, vous verrez peut-être ces caractères ^ M à la fin des lignes.

Si vous souhaitez les supprimer, vous pouvez le faire très facilement dans emacs. Mettez simplement en surbrillance et copiez le caractère ^ M et faites une requête-remplacez ^ M par et vous avez terminé.

EDIT: Quelques autres liens qui peuvent être utiles. http://xahlee.org/emacs/emacs_adv_tips.html

Celui-ci vous aide à configurer emacs pour utiliser un type particulier de style de fin de ligne. http://www.emacswiki.org/emacs/EndOfLineTips

— Mat
source

2

J'ai rencontré ce problème il y a quelque temps. Le ^ M représente un retour chariot, et la recherche sur Ctrl-Q Ctrl-M(Cela crée un ^ M littéral) vous permettra d'obtenir une poignée sur ce caractère dans Emacs. J'ai fait quelque chose de ce genre:

M-x replace-string [ENTER] C-q C-m [ENTER] \n [ENTER]

— Nedblorf
source

2

Si l'utilitaire dos2unix n'est pas installé sur votre système, vous pouvez créer le vôtre pour vous débarrasser des caractères de fin de ligne de Windows:

vi ~/dos2unix.bash:

avec le contenu suivant

#!/bin/bash
tr -d '\r' < $1 > repl.tmp
mv -f repl.tmp $1

Dans votre ~ / .bashrc, ajoutez la ligne:

alias 'dos2unix=~/dos2unix.bash'

Postuler

dos2unix file_from_PC.txt

supprimera ^ M caractères aux lignes se terminant par file_from_PC.txt. Vous pouvez vérifier si vous en avez ou non en utilisant cat:

cat -v file_from_PC.txt

— grapesh
source

1

Voir également:

Masquer ^ M dans emacs

Soyez prudent si vous choisissez de supprimer les caractères ^ M et de les renvoyer à votre équipe. Ils peuvent voir un fichier sans retour chariot par la suite.

— Démosthénex
source

0

La solution pour moi était d'utiliser la fonction elisp suivante trouvée dans cet article Wiki d'Emacs .

 (defun dos2unix ()
      "Not exactly but it's easier to remember"
      (interactive)
      (set-buffer-file-coding-system 'unix 't) )

Exécutez la fonction M-x dos2unixsur le tampon et enregistrez le fichier, tout ^Mdisparaîtra.

— Carlo Rodríguez
source