|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 16 Apr 2007 19:54:38
To : Artem Chuprina
Subject : Re: XFree -> XOrg
--------------------------------------------------------------------------------
Apr 16 17:05 07, Artem Chuprina wrote:
AC>>> У тебя есть длинный пайп. Тебе надо отследить код
AC>>> завершения команды в его середине. Твои действия?
ZK>> Если именно _мои_, то обернуть в скрипт ту команду, которая может
ZK>> вернуть "не тот" код и там его анализировать. Костыль конечно, но
ZK>> помогает чтобы в следующие по порядку команды не попали "ошметки"
ZK>> например строки, если половина ее пропала из-за ошибки.
AC> Так, с этого места поподробнее...
А что тут еще сказать подробнее? Hа уровне рядового юзера, владеющего средствами
шелла на уровне институтского курса, типа меня, кроме скриптовой обертки вокруг
наиболее критичных команд - ничего предложить не могу. Конечно, скриптовая
обертка может быть существенно разной по сложности,
а в особо критичных случаях типа упомянутого тобой бэкапа - вообще не надо
ставить такие команды в конвейер. Вот просто не ставить и все. Воизбежание
многочисленных возможных и трудноуловимых глюков. Это если надо чтобы просто
работало, а не "выглядело изящно". Если надо еще и изящно - то надо обращаться к
профессионалам или самому читать горы документации чтобы стать таковым в
вопросах скриптописательства.
AC> Мы тут недавно ошибочку поймали... Вероятность проявления - между 2
AC> в минус семнадцатой и 2 в минус восемнадцатой. В реальной работе с
AC> большим потоком данных всплывала раз в три месяца, и при повторении
AC> процедуры пропадала...
А я в свое время примерно такой глюк так и не поймал.
Два линукса, связанные телефонными модемами и ppp. При обрыве ppp перезванивает,
достаточно быстро, tcp-соединения не успевают оборваться. Через этот линк
работает telnet в режиме "трубы, качающей данные" (текстовые строки). Иногда,
раз в пару недель, после очередного пересоединения, возникала ситуация когда
связь есть, пинг есть, с обоих концов соединение телнета есть, а данные через
него течь перестали. И в таком состоянии конструкция могла пребывать хоть двое
суток - никакие таймауты не истекают, но и ничего не работает. Ядро было 2.0.27,
1997 если не ошибаюсь год.
AC> Я это к тому, что с тем же grep -r вижу сходу, допустим, следующую
AC> проблему. Что ты будешь делать, если у тебя нету -r?
Вот кстати в те времена grep как раз и не умел -r. С тех пор привык обходиться.
AC> "Серьезные сертифицированные специалисты" совершенно не испытывают
AC> удовольствия от поддержки N+K различных наколенных вариантов. Даже
AC> если они, пока работают, работают хорошо и на "морально устаревшем"
AC> железе.
AC> Ты кстати, уверен, что физически оно еще не устарело, и у него не
AC> начались аппаратные глюки, которые пока отдиагностируют, успеют
AC> заколебать техподдержку софта?
Hу у меня-то работает. И у меня ровно один такой комп. Соответственно -
предложения купить "программный комплекс" уже пятый год отправляются в мусорную
корзину.
AC> А еще вспоминается анекдот времен твоей институтской юности.
AC> Правда, не знаю, рассказывали ли его в твоем институте...
AC> - Hо ваша программа работает в 10 раз медленнее моей!
AC> - Да, но зато она работает _правильно_.
Рассказывали. И анекдот совершенно правильный. Он и не анекдот вовсе.
--- Msged/LNX 6.1.1
* Origin: mobile point - Compaq Armada 1750 + Siemens ME45 (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
