![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Мучающий меня 10 лет вопрос
Люди, а скажите мне - через | (пайп) БИНАРНЫЕ данные проходят?
Особо интересует - на линуксе и на винде. Про первое я знаю, что проходят, т.к. arecord | aplay работает, а вот про второе уже 10 лет мучаюсь, но никак руки не дойдут проверить :)
Особо интересует - на линуксе и на винде. Про первое я знаю, что проходят, т.к. arecord | aplay работает, а вот про второе уже 10 лет мучаюсь, но никак руки не дойдут проверить :)
no subject
no subject
no subject
и почему падлинуксом я наоборот, крайне рад тому, что по умолчанию всё бинарное, а не ломается в непредсказуемых местах от случайного символа, похожего на EOF в середине файла.
no subject
no subject
Вот, например, есть у нас "компорт", пришел из него байт. Через 1мс еще байт, потом через 2,4,8,16,32...стопицот итд мс еще по байту. В какой момент будем считать, что поток закончился?
По уму, устройство должно явно сказать, что данных больше нет, а не мешать управляющий канал с каналом данных. Ну или придумать отвратный протокол типа построковой буферизации и конца данных по символу доллар.
no subject
вот и вы и сформулировали причину, по которой EOF удобен
no subject
почему два -- а опишите как вы будете передавать тот байт, у которого код совпадает с тем, который мы назначили ЕОФ.
no subject
Я протестую против того, что в нём не было логики и смысла изначально. В те времена данные в файлы вводились с клавиатуры, а не снимались говнозеркалками. Поэтому такая экзотика как EOF вполне могла решать задачу сигнализирования о конце передаваемого файла.
no subject
по уму это делается передачей по физическому уровню запрещенного символа, который не конвертируется в канальные символы.
ну или можно in-band в канале, специальной комбинацией, но тогда эскейпинг должен быть предусмотрен.
no subject
Да, если ставить задачу разработки протокола, позволяющего передавать ЛЮБЫЕ байты, нужно изобретать ухищрения вроде "канал данных/канал контроля", "канальный/транспортный/физический уровень", "протокол с ескейпингом" и пр.
Если же говорить о передаче "обычного текста" (т.е. весьма ограниченного подмножества ASCII), которая в своё время составляла, подозреваю, более 83% всех передач, задача решается на порядок проще - введением управляющих символов.
no subject
"Такие странные значения" не берутся все же из ниоткуда, а вытекают из устройства кодовой таблицы. Просто кем-то когда-то было принято решение о том, что ничего кроме латинских букв и цифр никому никогда передавать не потребуется - и вот это и есть настоящая кривость, под которую и придумали кодовую таблицу.
Эскейпинг в данном случае делается проще некуда: один, условно говоря, "компаратор" и один триггер, который даже механически реализовать не проблема. Зато потом не нужно было бы изобретать ANSI-эскейпинг, кодировки, line discipline и прочую хрень...
no subject
это было сделано человечеством, которое сформировало язык естественного общения таким, какой он есть - 26 букв плюс пунктуационные мелочи.
То, что информационная эра вносит в традиции свои правки было осознанно позже.
no subject
Подозреваю, кстати, что там тоже участвовали адепты мифической "обратной совместимости на бинарном уровне".
no subject
no subject
no subject
no subject
Ок. Пусть это будет количество байт. Это не означает, что данные закончились. Потоком может быть и консоль, т.е. чел может просто нажимать кнопки медленнее, чем программа их обрабатывает.
Поэтому, пока он не нажмёт ^Z нужно игнорировать нулевое чтение и читать снова.
no subject
Можно этот режим выключить и читать побайтно, с таймаутами, использовать select/epoll и тому подобное.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
логика ок