Vim: \n vs \r

Je n'ai pas utilisé vim dans un système Unix dans un tout, mais comme je l'ai rappeler qu'il n'y a pas de \r, il est toujours \n.

Je suis en utilisant gVim sous windows et quand j' recherche pour les caractères de nouvelle ligne j'utilise \n. Recherche pour \r renvoie rien. Mais quand j'ai remplacer les personnages que j'ai à utiliser \r la. \n donnez moi ^@

Quelqu'un peut-il expliquer ce qu'il se passe ici?

  • Vous devriez changer la accepté de répondre; Jonathan Leffer réponse est bonne mais n'a rien à voir avec la question.
InformationsquelleAutor Whaledawg | 2008-12-08
  1. 22

    De recherche jusqu':

    :set fileformat=unix
:set fileformat=dos

    Ceci peut être utilisé sur les deux plate-forme pour passer à l'autre encodage.

    • Je ne vois pas ce que le fichier de l'EOL format a à voir avec la façon dont vim recherche/remplace les sauts de ligne/retours chariot.
    • Normalement, vous définissez le format de fichier de manière appropriée et que vous n'avez pas à vous soucier de savoir si les retours chariot sont nécessaires, et donc ne pas avoir à les chercher.
    • Je dirais que cette solution est la plus simple! Je fonctionne parfaitement pour mon cas.
    InformationsquelleAutor Jonathan Leffler
  2. 26

    Dirait que vous êtes de demander deux choses. Une question est de \r vs \n que d'autres ont couvert.

    L'autre problème est \n sur le côté droit de substitution. Si vous regardez :h s/\n, il est dit que \n dans la pièce de remplacement d'une substitution insère un <NUL> /<NL>, PAS un saut de ligne.

    Si vous faites un :%s/\n/\n/ et ouvrir et enregistrer le fichier dans un éditeur hexadécimal, tous les ^@ personnages sont ASCII 0 (NUL caractères). Pourquoi le Vim devs utilisation \n sur la gauche pour fin-de-ligne et \n sur la droite pour les NUL est au delà de moi. Mais ce comportement n'a rien à voir avec Windows et Unix.

    • Ce on obtient toujours de moi - je ne me souviens jamais si c'est \r ou \n ce qui signifie des choses différentes dans la recherche et le remplacer. Récemment (après j'ai lu les docs et trouvé quelle est la différence) je trouve qu'il est utile de se rappeler que NUL commence par 'n'.
    • Pas de doute, il y a une logique dans le choix des concepteurs fait mais il a des voyages m'a trop à chaque fois. Pour moi, il aurait fait beaucoup plus de sens d'utiliser \r (ou \n, vous choisissez choix) à la fois de recherche et de remplacement. À l'aide de s/\r/\r/ndoit retourner 1 au lieu de Modèle n'est pas trouvé et à l'aide de s/\n/\n ne devrait pas changer quoi que ce soit.
    InformationsquelleAutor Brian Carper
  3. 7

    Derrière les coulisses, Vim utilise \r (retour chariot) pour enregistrer de Fin De Lignes (quel que soit le fileformat, qui n'a d'importance que le fichier est en cours de lecture ou d'écriture). Vim utilise \n pour représenter NULs. Cependant, la recherche pour EOL, comme le \n, mais dans le remplacement, l' \n représente NUL. C'est expliqué dans :h sous-remplacer-sepcial. Recherche pour \r trouverez des retours chariot qui ne faisaient pas partie de la fileformat de l'EOL. Il y a une longue explication :h de fichiers-formats.

    InformationsquelleAutor graywh
  4. 3

    vim fait un peu de déconner avec des retours chariot (\r) et des retours à la ligne (\n). Par exemple, si vous êtes sous Unix et vi vous montre les lignes se terminant par '^M' parce qu'ils sont Windows fichiers texte, un moyen facile de se débarrasser d'eux est d'entrer la commande

    :%s/^V^M/^V^M/g

    Il ne regarde pas comme il faut faire n'importe quoi, mais il le fait.

    InformationsquelleAutor Paul Tomblin
  5. 3
    :%s/^V^M/^V^M/g

    De même, le suivant fait la même chose (je pense), et est plus facile à taper.

    :%s/\r/\r/g
    InformationsquelleAutor
  6. 2

    Sous unix, à l'intérieur de vim, ^V + <enter> me donne un ^M qui est le \r caractère.

    Aussi, vous ne pouvez pas trouver \r à l'intérieur de vim sauf si vous lui dites d'éditer le fichier en mode binaire, qui est, ne pas utiliser le mode automatique par défaut lorsqu'il détecte automatiquement les caractères de fin de ligne. (il doit imprimer [dos] en l'état.)

    • FWIW, si votre fichier est un mélange de plusieurs lignes se terminant par \n, mais d'autres lignes se terminant par \r\n, vous allez voir le ^M caractères. Vous pouvez obtenir un mélange si quelqu'un a effectué une modification sur le fichier texte à l'aide de Windows.
    • Oui, bien sûr, vim va choisir les caractères de fin de ligne qui a du sens.
    InformationsquelleAutor mat
  7. 2

    Je pense que le problème pourrait résider dans la façon dont Windows et Unix faire des retours à la ligne. Le format Unix est \n (saut de ligne) mais pour Windows, il est \r\n (retour chariot, saut de ligne).

    • Vous avez qu'à reculons, UNIX n' \n (qui est la ligne d'alimentation), Windows ne \r\n (carraige retour, saut de ligne),
    • Merci pour la correction de moi. C'était une erreur de ma part.
    InformationsquelleAutor Sean
  8. 0

    Dans Windows, si vous ouvrez un fichier en mode texte, \n est interprété à la fois comme le retour à la ligne et les caractères de saut de ligne. Normalement, cette situation n'est pas le cas, les systèmes *nix.

    InformationsquelleAutor Joel Coehoorn