Balancer> Грамотный подход, когда приложение не заботится о поддержки кучи форматов. Для этого конвертеры есть.
Ну, это для пользователя непринципиально. Конечно, конвертеры/фильтры удобнее иметь универсальные/подключаемые, и так все и стараются делать. Но работать это должно прозрачно: если программа считала файл в таком-то формате, она
обязана его записать в том же (предупредив о потерях, если есть), или отказаться записывать в этот файл, если формат не поддерживается.
Balancer> В Unix - всегда 0A Balancer> 0D - это только на Макинтошах.
Не "только". Почему-то именно на большинстве систем, с которыми доводилось работать. Только вот не помню насчет СР/М.
Zeus>> из-за того, что во многих системах есть только один символ для новой строки, сам же принтер можно переключить в режим, когда он будет подставлять недостающую пару.Balancer> Это только от бедности операционки
Не совсем. У "богатых" операционок свои проблемы. А вообще, это не так принципиально. Можно ведь сказать, что проходится писать сложный драйвер из-за "бедности" периферии
>Если бы в DOS в своё время не протормозили ввести команду sed (в десяток килобайт легко бы уложились по тем временам, IMHO), то очень многое могло бы измениться В т.ч. и не пришлось бы усложнять железо и софт принтера.
Ну, железо, допустим, не усложняется, а софт... В данном-то случае не принципиально усложняется, это ж его профиль.
>Ибо печатали бы тогда не как "type file.txt > lpt1:", а как "type file.txt | sed s/\n/\r\n/ > lpt1:"
А вот этого бы не делали. ДОС - все же "массовая" операционка, и лишние закорючки там нежелательны (по крайней мере в качестве обязательного способа). Потому решать такие вещи надо где-то на уровне конфигурирования системы.
Balancer> Самый прикол, что перенаправление потоков вывода в DOS ввели, а вот софта для нормальной работы с теми же пайпами - почти нет sort, more... что там ещё?
Ну, это да, с перенаправлениями там глухо... Но, опять же, ширпотреб...
Zeus>> Не для ускоренияBalancer> Ты уже совсем забыл, что такое настоящие терминалки на 9600 бод Там за счёт перевода позиции курсора точно вниз можно было сэкономить по скорости ввода изображения. Не требовалось забивать пробелами пустые левые колонки Особенно для программ на Фортране актуально
Во-1, насколько? 1 лишний байт на строку из 30-40 символов? Не смешно. Во-2, с Фортраном совсем не так. Ну, подумай сам: напечатали строку, что дальше? предлагаешь сдвинуть курсор вниз и...? Назад-то его как двигать? В следующей строке где угодно символ может быть, в т.ч. и в первой колонке, а оптимизировать перемещения курсора, анализируя следующий текст, никто не будет. Да и много ли там наоптимизируешь, если вопрос в паре табуляций обычно.
Balancer> Ну и для принтеров старых тормозных тоже актуально было, тоже меньше головой гонять.
Даже самые старые и тормозные принтеры не гоняли голову вслед за командами. Буфер на строку всегда был.
Balancer> Фиг там Всю жизнь "\r" использовали для перевода в начало этой же строчки. Когда нужно строку обновлять. Например, процент форматирования выводить [»]
Ну, тогда тем более. Единственный минус пары CR/LF получается - рост размера файла. С другой стороны, при одном символе элементарно подправить функцию вывода текста на самом высоком уровне, чтобы 13 (или 10)
всегда заменялось на пару. Но это потеря гибкости. Так что, может, с парой в файле и лучше в этом смысле. Дешево и сердито