Razón histórica detrás de diferentes líneas que terminan en diferentes plataformas.

Question

¿Por qué DOS / Windows y Mac decidieron usar \ r \ ny \ r para el final de 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 (como), ¿Apple cambió a \ n desde \ r?

Answer 1

El DOS heredó los finales de línea CR-LF (lo que está llamando \ r \ n, simplemente haciendo explícitos los caracteres ASCII) de CP / M. CP / M lo heredó de los diversos sistemas operativos DEC que influyeron en el diseñador de CP / M Gary Kildall.

Se utilizó CR-LF para que las máquinas de teletipo regresen el cabezal de impresión al margen izquierdo (CR = retorno de carro) y luego se muevan 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.

Answer 2

Realmente agregando a @Mark Harrison ...

La gente que te dice que Unix está " simplemente está generando el texto que el programador especificó " mientras que DOS está roto son simplemente un error. 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 única convención verdadera para los finales de línea de archivo de texto, solo las convenciones específicas de la plataforma. Después de todo, incluso CR-LF, CR y LF no son las únicas convenciones de fin de línea que se hayan utilizado nunca, y ASCII nunca fue el único conjunto de caracteres. El problema es la biblioteca estándar de C y el tiempo de ejecución, que no abstrae este detalle dependiente de la plataforma. Otros lenguajes de tercera generación (como Pascal e incluso Basic) lo lograron, 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 la compatibilidad con el código fuente y los libros existentes.

De hecho, es Unix y Multics que originalmente necesitaban la traducción de cadenas para la E / S de la consola, ya que los usuarios usualmente se sentaban en un terminal ASCII que requería el fin de la línea CR LF. Sin embargo, esta traducción se realizó en un controlador de dispositivo: el objetivo era abstraer las características específicas del dispositivo, asumiendo que era mejor adoptar una convención y atenerse a ella para los archivos de texto almacenados.

El hackeo de E / S de texto en C es similar en principio a lo que CygWin hace ahora, 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, pero también está Wine, que convierte Linux en Windows. Por extraño que parezca, puedes leer algunas críticas equivocadas de final de línea de Windows en Preguntas frecuentes de CygWin (enlace del archivo de Internet agregado 2013 - la página ya no existe). Tal vez sea solo su sentido del humor, ya que básicamente están haciendo lo que están criticando, pero en una escala mucho mayor ;-)

La biblioteca estándar de C ++ (independientemente de la plataforma en la que se implemente) evita este problema utilizando iostreams, cuya línea de resumen finaliza. Para salida, me parece bien. Para la entrada, necesito más control, así que interpreto carácter por carácter o bien uso un generador de escáner.

[ EDIT Resulta que la afirmación tachada arriba no es cierta y nunca lo fue. El std :: endl se traduce literalmente a un \ n y un color. El \ n es exactamente el mismo \ n que obtienes en C: tiende a llamarse "nueva línea", pero en realidad es un carácter de salto de línea ASCII, que luego se traduce por el tiempo de ejecución si es necesario. Es curioso cómo las suposiciones falsas pueden estar tan arraigadas que nunca las cuestionas; básicamente, C ++ no tuvo otra opción para hacer lo que C hizo (aparte de agregar más capas en la parte superior) por razones de compatibilidad, y eso siempre debería haber sido obvio.]

El mayor culpable de mi POV es con C, pero C no es el único proyecto en el que no puede anticipar su traslado a otras plataformas. Culpar a Bill Gates es una locura, todo lo que hizo fue comprar y pulir una variante del popular CP / M. En realidad, solo es historia, la misma razón por la que no sabemos a qué códigos de caracteres del 128 al 255 se refieren en la mayoría de los archivos de texto. Dada la facilidad de 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 forma correcta, y la forzaré a que te guste o no" actitud.

También: ¿el punto de código U + 2028 del separador de línea Unicode reemplazará todas estas convenciones en futuros archivos de texto? ;-)

Answer 3

Hay un artículo bastante extenso sobre los finales de línea en wikipedia. La " Historia " La sección responde al menos a una parte de su pregunta: http://en.wikipedia.org/wiki/Newline# Historia

Answer 4

Es interesante notar que el CRLF es prácticamente el estándar de Internet. Es decir, casi todos los protocolos de Internet estándar que están orientados a la línea utilizan CRLF. SMTP, POP, IMAP, NNTP, etc. El cuerpo del correo electrónico consiste en líneas terminadas por CRLF.