Мучающий меня 10 лет вопрос

[metaclass]

Люди, а скажите мне - через | (пайп) БИНАРНЫЕ данные проходят?
Особо интересует - на линуксе и на винде. Про первое я знаю, что проходят, т.к. arecord | aplay работает, а вот про второе уже 10 лет мучаюсь, но никак руки не дойдут проверить :)

Comments

[devnu11.livejournal.com]

как-то так process.a.stdout>---<process.b.stdin как в мастдае - не знаю )

[abbra]

Глупый вопрос -- глупый ответ: http://msdn.microsoft.com/en-us/library/aa365605.aspx

[metaclass.livejournal.com]

Это совершенно другое.
Я про перенаправление stdout одного процесса в stdin другого.

[gds.livejournal.com]

если пишущий поставил дескриптор/хендл в "писать бинарное", а читающий, соответственно, в "читать бинарное", средствами сишного рантайма, то проходят. В остальных случаях бывают казусы. Если интересно конкретное "заклинание" для mingw, смогу посмотреть.

[abbra]

На самом деле из-за отсутствия единообразия в представлении разных каналов в Windows и возникают такие вопросы. Но ответ там же: http://msdn.microsoft.com/en-us/library/tw4k6df8%28v=vs.80%29.aspx
"_setmode is typically used to modify the default translation mode of stdin and stdout, but you can use it on any file. If you apply _setmode to the file descriptor for a stream, call _setmode before performing any input or output operations on the stream."

[nicka-startcev.livejournal.com]

изобретателю "текстового [по умолчанию] режима ввода-вывода файлов" надо оторвать яйца через горло и вырезать гладны автогеном через жопу, ибо польза от него мизерная и только в очень экзотических случаях.

[trueblacker.livejournal.com]

вообще-то среди польз был ещё символ eof, и он был очень удобен в своё время. Теперь конечно легко пенять.

[nicka-startcev.livejournal.com]

и какая с него была польза? В каких случаях кроме случайного "copy binaryfile con"
и почему падлинуксом я наоборот, крайне рад тому, что по умолчанию всё бинарное, а не ломается в непредсказуемых местах от случайного символа, похожего на EOF в середине файла.

[trueblacker.livejournal.com]

элементарная польза. Как узнать, что данные в потоке закончились? Это весьма нетривиальный вопрос и его решали в соответствии с реалиями того времени.

[nicka-startcev.livejournal.com]

а что значит "в потоке данные закончились"?
Вот, например, есть у нас "компорт", пришел из него байт. Через 1мс еще байт, потом через 2,4,8,16,32...стопицот итд мс еще по байту. В какой момент будем считать, что поток закончился?

По уму, устройство должно явно сказать, что данных больше нет, а не мешать управляющий канал с каналом данных. Ну или придумать отвратный протокол типа построковой буферизации и конца данных по символу доллар.

[trueblacker.livejournal.com]

>По уму, устройство должно явно сказать, что данных больше нет

вот и вы и сформулировали причину, по которой EOF удобен

[nicka-startcev.livejournal.com]

в байтовом потоке выделить как минимум два байта для служебных целей? Как-то некамильфо.

почему два -- а опишите как вы будете передавать тот байт, у которого код совпадает с тем, который мы назначили ЕОФ.

[trueblacker.livejournal.com]

я не собираюсь утверждать, что EOF - это тру и так всем надо делать.
Я протестую против того, что в нём не было логики и смысла изначально. В те времена данные в файлы вводились с клавиатуры, а не снимались говнозеркалками. Поэтому такая экзотика как EOF вполне могла решать задачу сигнализирования о конце передаваемого файла.

[ex0_planet]

Вернуть 0 на очередной read?

[trueblacker.livejournal.com]

а чем 0 круче EOF'а ?

[metaclass.livejournal.com]

Это может быть и ошибка, а не только конец файла :)

[metaclass.livejournal.com]

read возвращает число прочитанных байт.

[trueblacker.livejournal.com]

"возвращает" - растяжимое понятие. Я задал вопрос для уточнения.
Ок. Пусть это будет количество байт. Это не означает, что данные закончились. Потоком может быть и консоль, т.е. чел может просто нажимать кнопки медленнее, чем программа их обрабатывает.

Поэтому, пока он не нажмёт ^Z нужно игнорировать нулевое чтение и читать снова.

[metaclass.livejournal.com]

В консоли обычно ждет Enter а потом возвращает.
Можно этот режим выключить и читать побайтно, с таймаутами, использовать select/epoll и тому подобное.

[trueblacker.livejournal.com]

какая разница, какой кнопки ждать? Ну enter... Что это меняет? "Не нажата ни одна клавиша" и "не нажата клавиша enter" всё равно не "данные закончились".

[ex0_planet]

тем что не в потоке, а out-of-band

[ex0_planet]

это исключительная ситуация, а уж что там за - пусть разбирается отдельная функция

[ex0_planet]

консоль тупо блокируется, пока не будет достаточно данных. достаточно - понятие растяжимое.

[ex0_planet]

вы путаете уровни
по уму это делается передачей по физическому уровню запрещенного символа, который не конвертируется в канальные символы.
ну или можно in-band в канале, специальной комбинацией, но тогда эскейпинг должен быть предусмотрен.

[trueblacker.livejournal.com]

это вы, а не я путаете уровни. Вы рассуждаете о современной проблематике, а я вам говорю о решении, которое было выработано в гораздо более тепличных условиях и которое опиралось на то, что "кому потребуется передавать такие странные значения?".

Да, если ставить задачу разработки протокола, позволяющего передавать ЛЮБЫЕ байты, нужно изобретать ухищрения вроде "канал данных/канал контроля", "канальный/транспортный/физический уровень", "протокол с ескейпингом" и пр.

Если же говорить о передаче "обычного текста" (т.е. весьма ограниченного подмножества ASCII), которая в своё время составляла, подозреваю, более 83% всех передач, задача решается на порядок проще - введением управляющих символов.

[ex0_planet]

В общем, телефонисты (точнее телеграфисты) как всегда во всем виноваты. У них цеховая традиция - делать решения феерической кривожопости, с которыми остальным сорок лет приходится как-то мириться.

"Такие странные значения" не берутся все же из ниоткуда, а вытекают из устройства кодовой таблицы. Просто кем-то когда-то было принято решение о том, что ничего кроме латинских букв и цифр никому никогда передавать не потребуется - и вот это и есть настоящая кривость, под которую и придумали кодовую таблицу.

Эскейпинг в данном случае делается проще некуда: один, условно говоря, "компаратор" и один триггер, который даже механически реализовать не проблема. Зато потом не нужно было бы изобретать ANSI-эскейпинг, кодировки, line discipline и прочую хрень...

[trueblacker.livejournal.com]

>Просто кем-то когда-то было принято решение о том, что ничего кроме латинских букв и цифр никому никогда передавать не потребуется

это было сделано человечеством, которое сформировало язык естественного общения таким, какой он есть - 26 букв плюс пунктуационные мелочи.

То, что информационная эра вносит в традиции свои правки было осознанно позже.

[ex0_planet]

Как бе о том, что текст - это не просто последовательность буков было известно сильно заранее. Просто в то, чем можно было пользоваться исключительно для телеграфа, попытались запихнуть элементы верстки, управления линком и черт знает что еще, вместо того чтобы сесть и сделать по нормальному.

Подозреваю, кстати, что там тоже участвовали адепты мифической "обратной совместимости на бинарном уровне".

[theiced.livejournal.com]

ты тупое говно. в юниксах как то обходились прекрасно.

[trueblacker.livejournal.com]

браузер на руби написал уже, говножорка?

[theiced.livejournal.com]

яркий пример змагарской недологики.

[trueblacker.livejournal.com]

не хватало ещё, чтобы ты мне тут про логику задвигал. Нахуй дорогу найдёшь?

[theiced.livejournal.com]

действительно, ты слишком туп что бы осознать что такое причнно следственные связи. сосни хуйца.

[trueblacker.livejournal.com]

жена уже не удовлетворяет и ты решил предлагать своего мальнкого айседа блогерам?
логика ок

[freiksenet.livejournal.com]

А какие еще данные бывают кроме бинарных %)

[metaclass.livejournal.com]

32..127

[freiksenet.livejournal.com]

зачем...

[fraks-nsk.livejournal.com]

Я в курсе что gbak.exe умеет получать и принимать данные через stdin/stdout заместо указания файлов. Значица и на винде бинарные данные проходят.