No he usado vim en un sistema Unix por un tiempo, pero como recuerdo no hubo \ r, siempre fue \ n.Vim: n vs. r
Estoy usando gVim en windows y cuando busco para nuevos caracteres de línea utilizo \ n. La búsqueda de \ no devuelve nada. Pero cuando yo reemplace los caracteres que tengo que usar \ r's. \ n dame^@
¿Alguien puede explicar lo que está pasando aquí?
búsqueda por:
:set fileformat=unix
:set fileformat=dos
Esto se puede utilizar en cualquiera de las plataformas para cambiar a la otra codificación.
No veo qué tiene que ver el formato EOL del archivo con la forma en que vim busca/reemplaza las líneas nuevas/retornos de carro. – graywh
Normalmente, establece el formato de archivo de forma adecuada y, a continuación, no tiene que preocuparse de si se necesitan retornos de carro y, por lo tanto, no tiene que buscarlos. –
bajo Unix, dentro de vim, ^V + <enter> me da una ^M que es el carácter \r.
Además, no puede encontrar \r dentro de vim a menos que le indique que edite el archivo en modo binario, es decir, que no utilice el modo automático predeterminado, donde detecta automáticamente el final de línea. (debe imprimir [dos] en el estado.)
FWIW, si su archivo tiene una combinación de algunas líneas que terminan en \ n pero otras líneas que terminan en \ r \ n, verá los^^ caracteres. Puede obtener una mezcla si alguien realizó una edición en el archivo de texto con Windows. –
Sí, por supuesto, vim elegirá el final de línea que tenga sentido. – mat
Creo que el problema podría residir en la forma en que Windows y Unix realizan nuevas líneas. El formato para Unix es \ n (avance de línea) pero para Windows es \ r \ n (retorno de carro, avance de línea).
En Windows, si abre un archivo en modo texto, \ n se interpreta como los caracteres de nueva línea y salto de línea. Este normalmente no es el caso de los sistemas * nix.
vim hace algún lío con retornos de carro (\ r) y saltos de línea (\ n). Por ejemplo, si estás en Unix y vi que muestra las líneas que terminan en '^ M' porque son archivos de texto de Windows, una forma fácil de deshacerse de ellos es entrar en el comando
:%s/^V^M/^V^M/g
Doesn Parece que no debería hacer nada, pero lo hace.
Parece que estás preguntando dos cosas. Un problema es \r frente a \n que otros han cubierto.
El otro problema es \n en el lado derecho de una sustitución. Si mira :h s/\n, dice que \n en la parte de reemplazo de una sustitución inserta un <NUL>/<NL>, NO una línea nueva.
Si hace un :%s/\n/\n/ y guarda y abre el archivo en un editor hexadecimal, todos los ^@ caracteres son ASCII 0 (caracteres NUL). El porqué los desarrolladores Vim usan \n a la izquierda para el final de línea y \n a la derecha para NUL me sobrepasa. Pero este comportamiento particular no tiene nada que ver con Windows vs. Unix.
Este siempre me atrapa, nunca puedo recordar si es \ r \ o \ n lo que significa cosas diferentes en la búsqueda y el reemplazo. Recientemente (después de que realmente leí los documentos y encontré la diferencia) me parece útil recordar que NUL comienza con 'n'. –
Sin duda hay lógica en las elecciones que hicieron los diseñadores, pero también me hace tropezar cada vez. Para mí, hubiera tenido mucho más sentido usar '\ r' * (o \ n, escoger su elección) * tanto en búsqueda como en reemplazo. El uso de 's/\ r/\ r/n'debería devolver 1 en lugar de Pattern not found y usar' s/\ n/\ n' no debería cambiar nada. –
:%s/^V^M/^V^M/g
Del mismo modo, el siguiente hace lo mismo (creo), y es más fácil que escribir.
:%s/\r/\r/g
Detrás de las escenas, Vim utiliza \ r (retorno de carro) para salvar End-Of-Líneas (independientemente del formato de archivo, que sólo es interesante cuando el archivo está siendo leído o escrito). Vim usa \ n para representar NULs. Sin embargo, busca EOL como \ n, pero en el reemplazo, \ n significa NUL. Se explica en: h sub-replace-sepcial. La búsqueda de \ r encontrará los retornos de carro que no fueron parte de la EOL del formato de archivo. Hay una explicación larga en: h formatos de archivo.
Debe cambiar la respuesta aceptada; La respuesta de Jonathan Leffer es correcta, pero no tiene nada que ver con la pregunta. – sjy