бл..ская винда

#ifdef FLAME
use gcc :-) А не всякие багландские поделки :-))))
#endif // FLAME

todos fromdos

>Какой урод придумал в текстовых файлах в винде/досе переход на новую строку по ДВУМ символам CR+LF???

И действительно, какой урод телетайпы придумал?

>Ненавижу винду!!!!

С логикой не поспорить. Глючит билдер - виновата б..я винда. В огороде бузина - в Киеве Ющенко.

> Какой урод придумал в текстовых файлах в винде/досе переход на новую строку по ДВУМ символам CR+LF???

Не помню уже какой из них кто - но в досе (винде) они оба, в юниксе - один, в маке - совершенно другой. Так что, тут всё намного веселее - прям как с кодировками, которых тоже три :)

походу прокладку между стулом и монитором надо менять...

>прям как с кодировками, которых тоже три

cp866,cp1251, koi8-r, iso8859-5, cp855

Так сколько их у нас?

>>Какой урод придумал в текстовых файлах в винде/досе переход на новую строку по ДВУМ символам CR+LF???

>И действительно, какой урод телетайпы придумал?

+1 Вообще, какой урод придумал АЦПУ?

>Какой урод придумал в текстовых файлах в винде/досе переход на новую строку по ДВУМ символам CR+LF???

Вообщето это "возврат каретки" (того же например принтера) и "перевод строки" -> в принцыпе это даже более корректно, чем просто LF

Венда не нужно. Никогда не мох понять тех, кто пытается чёто делать с ей.

> И действительно, какой урод телетайпы придумал?

При чём тут телетайпы? Это винда, и её текстовые редакторы, они работают по несколько иному принципу. В конце концов, юниксам ничто не мешает обходиться одним LF?

Логики-то НЕТ. Если бы винда действительно КОРРЕКТНО обрабатывала одиночные LF и CR (именно как ТОЛЬКО line feed и ТОЛЬКО carriage return), я бы понял. Но она этого НЕ ДЕЛАЕТ. Значит, херня какая-то получается. Один лишний байт на каждый абзац. Интересно, а во времена, когда Гейц орал, что 640 кб всем хватит, никто не возмущался, что память так бездарно транжирится?

>Если бы

"Винда" отрабатывает в консоли (cmd.exe) всё чудесно. CR - как только перевод каретки, а CR+LF или LF - как перевод каретки и строки.

А вот почему у борланда всё так как выше описано или почему у них два разных парсера паскаля в свежайшей BDS2006 - один для собствнно компилятора, а второй для той херни, которая ошибки подсвечивает а-ля ворд - это совсем другой грустны разговор.

> "Винда" отрабатывает в консоли (cmd.exe) всё чудесно.

Да ладно. Делаем текстовый файл с содержимым:
------------------
Line with CR+LF at the end
Line with CR at the end
Line with LF at the end
The last line
------------------
Во второй строке в любом hex editor'е один LF (0A) забиваем пробелом (20), в третьей строке забиваем пробелом CR (0D). Сохраняем, запускаем cmd.exe, делаем
copy test.txt con
И что видим? Да херню видим, если честно. Так где посмотреть правильную отработку виндой отдельно стоящих CR и LF?

Итак, делаем файл:

-- cut test.txt --
qwerty CRLF
12345 CR
asdf LF
-- end --

Вывод получается следующий:

-- cut cmd.exe console --
C:\>copy test.txt con
qwerty
asdf5
        1 file(s) copied.
-- end --

Что здесь неправильно?

<<<<< Да херню видим >>>>>

Глюки?

p.s. С четвёртой строкой (чтобы точно как в твоём примере) тоже всё кошоладно.

> Что здесь неправильно?

Вставь после LF ещё одну строку и увидь, что неправильно. CR отрабатывается верно, а LF - нет (как CR+LF).

> Вставь после LF ещё одну строку и увидь, что неправильно. CR отрабатывается верно, а LF - нет (как CR+LF).

Отсюда вывод. Если ей пох - что LF, что CR+LF, то самым правильным решением было бы использовать для перехода на следующую строку только LF - как это и делается в юниксах. Но у Гейцов свой, особый, путь, мля.

>а LF - нет (как CR+LF)

Это правильное поведение

>Отсюда вывод. Если ей пох - что LF, что CR+LF, то самым правильным решением было бы использовать для перехода на следующую строку только LF - как это и делается в юниксах. Но у Гейцов свой, особый, путь, мля.

Правильный путь - поддерживать оба варианта в целях совместимости. Что и сделано. И прекрасно.

Но тут так и не сказал, каким боком поведение консоли cmd.exe связано с глючным поведением сипипибилдера?

> Это правильное поведение

Это ты постановил, да? Или Гейц сказал?

Ты матричные принтеры никогда не программировал? Оно и видно. Так вот, там чётко было: есть LF, есть CR и есть CR+LF. LF переводит строку, но каретку НЕ возвращает. Эх, салаги...

> Правильный путь - поддерживать оба варианта в целях совместимости. Что и сделано. И прекрасно.

Есть понятие "поддерживать" и есть понятие "сделать дефолтом". Так вот, в DOS дефолтом был сделан наиболее тупой, прожорливый до памяти и допускающий возможные ошибки вариант.

> Но тут так и не сказал, каким боком поведение консоли cmd.exe связано с глючным поведением сипипибилдера?

Не было бы этого бардака с CR+LF - каждую строку легко было бы определять по LF. И никаких лишних символов. Соответственно, и в билдере такая херня не стала бы возможной. Но M$, как всегда, всех подставила.

Салага здесь пока ты. Зарегистрируйся и признай слив.

> Салага здесь пока ты. Зарегистрируйся и признай слив.

Твой слив - да хоть сейчас.

Итак, имеем в сухом остатке: винда неспособна правильно отрабатывать LF. Она отрабатывает его, как CR+LF. В связи с этим, представляется непонятным, почему для перехода на следующую строку в текстовых файлах было избрано CR+LF, а не LF. Возможно, разработчикам просто было в лом заморачиваться с проблемами, которые тогда возникли бы при

copy textfile.txt prn

Надо было бы заменять LF на CR+LF. Но это их никак не оправдывает. А только доказывает, что DOS с самого начала была лажовой и плохо продуманной системой.

Эх-х... анонимуз ;)

То, как выглядит текст в обычном текстовом редакторе; как выглядит сеанс telnet-а, и т.д. и т.п. - можно объединить одним предожением: "Каждая следующая строка начинается с первого символа".

Т.е. с точки зрения даже здравого смысла - это CRLF.
То, что WinNT в отличие от DOS поддерживает марсианскую юниксовую ошибку, согласно которой вместо CRLF используется LF (вопреки здравому смыслу) - это только добрая воля, не более.

В этой теме более не появляюсь - грешным делом думал, что споры CRLF vs LF закончились много лет назад.