Исходное сообщение
"Атака через подстановку аргументов при использовании..." Отправлено Crazy Alex, 01-Июл-14 10:10
А теперь расскажи, как мне сделать, чтобы можно было из любого процесса, как-либо оплучившего fd, узнать, в каком формате  через него данные ждать. Ну, то есть можно в /tmp пытаться что-то вроде базы держать, но маразм же. А иначе - смысла не имеет, выдумывать способ детектирования - это нарываться на проблемы. Что до консоли - я вообще не уверен, что она должна оставаться в нынешнем виде. Зачем нужна текстовая консоль, если везде графические терминалы? А вот иметь не тупой поток байт, а структуру - команды, коды возврата и история их stdin/stdout/stderr по отдельности (и не забываем - этот вывод тоже структурирован, что позволяет, например, сделать разумный фолдинг), те самые шелл-паттерны a-la списки файлов, выбираемые в каком-то своём интерфейсе и отображаемые соответственно, и так далее - было бы куда как интереснее. Например, в половине случаев те же severity levels консольного лога было бы удобнее в консоли обрабатывать, а не в приложении, когда нагрузку лог создаёт малую, а просто вывод флудит. А так - надо - открыл топ-левел, глянул, что нужно, закрыл и дальше смотришь одним глазом на консоль.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> А теперь расскажи, как мне сделать, чтобы можно было из любого процесса, > как-либо оплучившего fd, узнать, в каком формате через него данные > ждать. Ну, то есть можно в /tmp пытаться что-то вроде базы > держать, но маразм же. А иначе - смысла не имеет, выдумывать > способ детектирования - это нарываться на проблемы. > Что до консоли - я вообще не уверен, что она должна оставаться > в нынешнем виде. Зачем нужна текстовая консоль, если везде графические терминалы? > А вот иметь не тупой поток байт, а структуру - команды, > коды возврата и история их stdin/stdout/stderr по отдельности (и не забываем > - этот вывод тоже структурирован, что позволяет, например, сделать разумный фолдинг), > те самые шелл-паттерны a-la списки файлов, выбираемые в каком-то своём интерфейсе > и отображаемые соответственно, и так далее - было бы куда как > интереснее. Например, в половине случаев те же severity levels консольного лога > было бы удобнее в консоли обрабатывать, а не в приложении, когда > нагрузку лог создаёт малую, а просто вывод флудит. А так - > надо - открыл топ-левел, глянул, что нужно, закрыл и дальше смотришь > одним глазом на консоль.
	Введите код, изображенный на картинке: