![¿Puedo cambiar el EOL de mi sistema Linux para usar \r\n en lugar de \n mediante archivos de configuración?](https://rvso.com/image/1482494/%C2%BFPuedo%20cambiar%20el%20EOL%20de%20mi%20sistema%20Linux%20para%20usar%20%5Cr%5Cn%20en%20lugar%20de%20%5Cn%20mediante%20archivos%20de%20configuraci%C3%B3n%3F.png)
Quiero cambiar el EOL predeterminado de mi sistema Linux de \n a \r\n sin volver a compilarlo. ¿Alguna configuración hace esto posible (tal vez local)?
Motivo: debo asegurarme de que para cada usuario que cree un archivo, el archivo tenga el formato correcto (sin obligarlo a usar Unix2dos u otra cosa)
Respuesta1
Estoy editando mi respuesta para proporcionar este resumen en la parte superior. Creo que la respuesta directa a su pregunta básica es "No, esta no es una opción comúnmente admitida en muchos sistemas Linux". A continuación se muestra mi explicación más detallada.
Dudo que esto se pueda hacer fácilmente. En teoría, varios sistemas operativos utilizan diferentes caracteres de nueva línea, como lo señalaWikipedia: Representaciones. En teoría, los programadores no deberían hacer referencia a \n o \r\n cuando quieran representar un “carácter de nueva línea” (que podría ser un carácter, como el carácter separador de registros de los antiguos sistemas QNX, o \r\n, como MS -DOS). De esa manera, si alguien (pronto o en el futuro) desea reutilizar el código, simplemente podría cambiar una variable.
En la práctica, se sabe que muchos programadores “codifican” valores. Puede utilizar "Linux desde cero" y personalizar el sistema como desee. Supongo que si modificaste el código fuente, podrías hacer que todos los archivos de configuración de tu sistema usaran la secuencia de nueva línea que prefieras.
Sin embargo, ¿qué sucede después cuando un usuario desea utilizar un editor de texto específico o un navegador web específico? ¿Estás preparado para “arreglar” tu propia variación del código fuente del navegador web Google Chromium, solo para adaptarte a este cambio?
Como puedes ver desdeEl comentario de ChrisEdmonton, implementar este cambio sería realmente inusual. Esto significa que es probable que descubra que muchas cosas no funcionan bien con el objetivo de una sola persona de implementar dicha flexibilidad. Por lo tanto, es probable que encuentre bastantes problemas. Supongo que es probable que encuentres bastantes problemas en el futuro, mucho después de que las cosas parezcan estar bien inicialmente.
Personalmente, los datos de mi computadora tienen algún valor para mí. Incluso los datos que son tan inútiles que no me molesto en respaldarlos, tienen suficiente valor para mí como para no querer hacer intencionalmente algo que pueda causar problemas. (Sólo porque estoy dispuesto a permitir que los datos se pierdan en el improbable caso de una catástrofe, no significa que quiera tirar metafóricamente gasolina por todo el piso en un lado de la casa, provocando inútilmente e intencionalmente una situación que Es probable que cause una catástrofe.)
Entonces, a menos que esté dispuesto a analizar todo tipo de cosas, incluidos los controladores del sistema de archivos y el código del kernel que maneja la memoria, y todos los demás aspectos del sistema, entonces probablemente no valga la pena seguir con esto. Sugiero utilizar otra forma de implementar el cambio.
Sí, conozco el argumento de que se supone que Linux es de código abierto, por lo que debería ser personalizable. Pero la realidad es que Linux ha crecido tanto que hacer un cambio puede tener consecuencias importantes. Hay que tener en cuenta que existen diferentes versiones de Linux (Debian, Ubuntu, Mint, Red Hat, SUSE, etc.), por no hablar de otros sistemas operativos tipo Unix (BSD, Solaris, Mac OS X) y otros sistemas operativos (Windows , DOS, CPM, VMS). En teoría, hacer un cambio como este debería ser más fácil que intentar convencer a Microsoft para que realice un cambio en su sistema operativo de código cerrado. En la práctica, es posible que deba convencer a muchas personas para realizar un cambio en algunos de los programas más populares que existen. Hacer cambios puede estropear cosas, por lo que se deben realizar cambios cuando exista un beneficio significativo y sustancial. Es poco probable que cambios más frívolos sean dignos de las dificultades que pueden implementar.
A algunas personas les gustaría que estos cambios sean una opción fácilmente modificable. Un problema con muchas opciones es que tener demasiadas opciones puede saturar las interfaces de usuario, saturar la documentación y complicar el código fuente (incluso si la complejidad añadida es bastante pequeña), por lo que hay personas que promueven la idea de crear estándares y opciones reductoras, en aras de la simplicidad. Por lo tanto, un cambio como "personalizar el carácter de nueva línea para el software que admite esta opción" puede generar más problemas que el beneficio esperado para dicha opción.
El motivo proporcionado es no querer que el usuario utilice "unix2dos" al crear un archivo. ¿Cómo crea el usuario un archivo? ¿El usuario ejecuta "nano"? Potencialmente, podría reemplazar "nano" con un script que ejecute el nano normal y luego ejecute Unix2dos automáticamente. Puede modificar el proceso mediante el cual los usuarios crean/editan archivos, o puede modificar el proceso que afecta cómo se transfiere el archivo a otras máquinas que podrían esperar \r\n (y luego no importar si el archivo se usa solo \n mientras el El archivo todavía está en la máquina Linux). Es mucho más probable que estos enfoques específicos funcionen, sin consecuencias no deseadas, en lugar de intentar realizar un cambio en todo el sistema que afecte el funcionamiento de todo el sistema.