operating system - salto - Razón histórica detrás de diferentes terminaciones de línea en diferentes plataformas
salto de linea tooltip (4)
¿Por qué DOS / Windows y Mac decidieron usar / r / n y / r para terminar la línea en lugar de / n? ¿Fue solo el resultado de tratar de ser "diferente" de Unix?
Y ahora que Mac OS X es Unix (-like), ¿cambió Apple a / n desde / r?
Hay un artículo bastante extenso sobre los finales de línea en wikipedia. La sección "Historia" responde al menos parte de su pregunta: http://en.wikipedia.org/wiki/Newline#History
Es interesante notar que el CRLF es prácticamente el estándar de Internet. Es decir, prácticamente todos los protocolos de Internet estándar orientados a líneas usan CRLF. SMTP, POP, IMAP, NNTP, etc. El cuerpo del correo electrónico consiste en líneas terminadas por CRLF.
DOS heredan terminaciones de línea CR-LF (lo que está llamando / r / n, simplemente haciendo que los caracteres ascii sean explícitos) desde CP / M. CP / M lo heredó de los diversos sistemas operativos DEC que influyeron en el diseñador CP / M Gary Kildall.
CR-LF se usó para que las máquinas de teletipo devolvieran el cabezal de impresión al margen izquierdo (CR = retorno de carro), y luego pasaran a la siguiente línea (LF = avance de línea).
Los chicos de Unix manejaron eso en el controlador del dispositivo, y cuando fue necesario tradujeron LF a CR-LF en la salida a los dispositivos que lo necesitaban.
Y como habrás adivinado, Mac OS X ahora usa LF.
Realmente añadiendo a @Mark Harrison ...
Las personas que le dicen que Unix está "simplemente sacando el texto que el programador especificó", mientras que DOS está roto son completamente erróneas. También hay afirmaciones de que es estúpido que DOS marque EOF cuando ve un carácter EOF, lo que plantea la pregunta de para qué es exactamente ese carácter EOF.
No existe una sola convención verdadera para las terminaciones de línea de archivo de texto, solo las convenciones específicas de plataforma. Después de todo, incluso CR-LF, CR y LF no son las únicas convenciones de final de línea que se usarán nunca, y ASCII nunca fue el único juego de caracteres. El problema es la biblioteca estándar de C y el tiempo de ejecución, que no resumió este detalle dependiente de la plataforma. Otros lenguajes de tercera generación (como Pascal e incluso Basic) lo administraron, al menos hasta cierto punto. Debido a esto, cuando los compiladores de C se escribieron para otras plataformas, se necesitaron hacks de biblioteca en tiempo de ejecución para lograr compatibilidad con el código fuente y los libros existentes.
De hecho, son Unix y Multics los que originalmente necesitaban la traducción de cadenas para E / S de consola, ya que los usuarios generalmente se sentaban en un terminal ASCII que requería extremos de línea CR LF. Sin embargo, esta traducción se realizó en un controlador de dispositivo: el objetivo era abstraer los detalles del dispositivo, suponiendo que era mejor adoptar una convención y atenerse a ella para los archivos de texto almacenados.
El hack de E / S de texto de C es similar, en principio, a lo que CygWin hace ahora, pirateando los tiempos de ejecución de Linux para que funcionen tan bien como se puede esperar en Windows. Hay una historia real de piratear cosas para convertirlas en Unix-alikes, pero también está Wine, convirtiendo a Linux en Windows. Por extraño que parezca, puedes leer algunas críticas de final de línea mal ubicadas de Windows en las Preguntas Frecuentes de CygWin (el enlace del Archivo de Internet se agregó en 2013 - la página ya no existe). Tal vez es solo su sentido del humor, ya que básicamente están haciendo lo que están criticando, pero en una escala mucho más grande ;-)
La biblioteca estándar de C ++ (independientemente de la plataforma en la que esté implementado) evita este problema al usar iostreams, que abstrae la línea que termina. Para la salida, me sienta bien. Para la entrada, necesito más control, así que interpreto carácter por carácter o bien uso un generador de escáner.
[ EDITAR Resulta que el reclamo tachado arriba no es verdadero, y nunca lo fue. std::endl se traduce literalmente en /n y en color. El /n es exactamente el mismo /n que obtiene en C - tiende a llamarse "nueva línea", pero en realidad es un carácter de avance de línea ASCII, que luego es traducido por el tiempo de ejecución si es necesario. Es curioso cómo las suposiciones falsas pueden ser tan arraigadas que nunca las cuestionas; básicamente, C ++ no tenía otra opción para hacer lo que C (aparte de agregar más capas en la parte superior) por razones de compatibilidad, y eso siempre debería haber sido obvio.]
La mayor culpa de mi punto de vista es con C, pero C no es el único proyecto que no puede anticipar su traslado a otras plataformas. Culpar a Bill Gates es simplemente una locura: todo lo que hizo fue comprar y pulir una variante del entonces popular CP / M. En realidad, es solo historia, la misma razón por la que no sabemos a qué códigos de caracteres se refieren 128 a 255 en la mayoría de los archivos de texto. Dada la facilidad para hacer frente a las tres convenciones de final de línea, es extraño que algunos desarrolladores sigan insistiendo en que "la convención de mi plataforma es la única manera verdadera, y la forzaré si te gusta o no".
Además, ¿el punto de código separador de línea Unicode U + 2028 reemplazará todas estas convenciones en futuros archivos de texto? ;-)