Re: Трубопровод в Linux
On Tue, 10 Jan 2006 11:06:02 +0200
Konstantin Korikov <lostcl***@i*****.ua> wrote:
> Раз уж вы упомянули стандарт кодирования GNU,
А где собственно можно почитать про эти стандарты?
Подписаться
Бесплатный дискуссионный лист
Подписчиков 540
| ← Январь 2006 → | ||||||
|
1
|
||||||
|---|---|---|---|---|---|---|
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
9
|
15
|
|||||
|
18
|
19
|
20
|
21
|
22
|
||
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
|
30
|
31
|
|||||
За последние 60 дней ни разу не выходила
Сайт листа:
http://www.linuxrsp.ru
Открыт:
22-10-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.linux.debate-list@subscribe.ru
Адрес
модератора: comp.soft.linux.debate-owner@subscribe.ru
Модератор
Статистика
540 подписчиков
0 за неделю
0 за неделю
За 2006-01-10
3D акселерация на Redeon-e
ЗаRPMил Catalist, запустил fglrxconfig, получил xorg.conf . X-ы
стартуют, рисуются отлично, но галочка в контрол центре на свойствах
видео "3D acceleration" неактивна, тот же TuxRacer ругается и тормозит.
Может какуюто опцию в xorg.conf прописать? кто знает?
-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 2799; Возраст листа: 811; Участников: 878
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/499773
Re: Трубопровод в Linux
On Tue, 10 Jan 2006 11:06:02 +0200
Konstantin Korikov <lostcl***@i*****.ua> wrote:
> Я прошу прощения за мою опечатку, или даже неграмотность, у всех
> присутствующих людей, которые считают себя глупыми программами.
Программы принимают извинения, ибо ошибка допущена в языке человеческом, который
допускает ошибки, в отличии от языка программ.
(Константин, не принимайте на свой счет, просто Ваша фраза настолько интересно
построена, что захотелось ответить в том же духе).
> Это мне известно не первый день с компьютером, и с Linux'ом в частности.
А это мне известно, за что Вас очень уважаю.
> > то в этом случае имеет смысл проигнорировать неправильно введенные
> > принимая во внимание только правильные и параметры по умолчанию.
> Не вижу никакого смысла. Раз уж вы упомянули стандарт кодирования GNU,
Есть и такое:
В проверках на ошибки, которые обнаруживают невозможные условия, следует
просто прерывать исполнение. Обычно здесь не надо печатать никаких
сообщений. Эти проверки показывают наличие ошибок. Если кто-то захочет
исправить ошибку, пусть он прочитает исходный текст и запустит отладчик.
Объясните лучше проблему в комментариях к исходному тексту.
Но, ИМХО, это совет программиста для программистов, пишущих программы для других
программистов. И я, считая это ошибкой, "прочитал исходный текст и запустил
отладчик". Ибо в "коментариях" сказано, что я имею право вносить изменения
в исходный код (конечное же сохраняя право других на внесение изменений).
> Что значит дополнительная обработка? Что они у вас обрабатываются
> больше одного раза?
Изменил алгоритм обработки ключей: часть ключей обрабатывается только для
коммандной строки, остальные и для трубопровода и для коммандной строки.
> > > наличии соответсвующих опций.
> > Добавление большого количество параметров ведь тоже раздует программу,
> Если кушать, то можно и растолстеть.
> Тут никто не платит деньги за каждую строку кода.
Если ни кто не платит, то это не значит, что не надо делать (как это сказать)
"юзабельных" программ. Конечно, совершенных программ не существует, глюки есть
всегда. Но я _хочу_ стремиться к совершенству.
> > приближении можно сказать примерно так: "Одна задача - одна программа".
> Именно так.
А если еще задачу разбить на подзадачи ;)
Re: Трубопровод в Linux
В сообщении от 1136837114 секунд после начала Эпохи Владимир Ковалев написал(а):
> Первая цитата:
> > Мы вить программы пишем не для идиотов, а для нормальных людей. Почему
> ^^^^
> ведь
> Здесь ни чего личного. В данном случае все поняли, что подразумевалось.
> Но глупые программы, воспринимающие входные данные буквально (внимание:
> неологизм - "байтально" ;) ), этого не поймут.
Я прошу прощения за мою опечатку, или даже неграмотность, у всех
присутствующих людей, которые считают себя глупыми программами.
> А с учетом стандарта кодирования
> GNU, применение для разбора параметров коммандной строки функции getopt_long
> подразумевает некоторую реакцию на неправильно введенные параметры.
Это мне известно пе первый день с компьютером, и с Linux'ом в частности.
> А если программа запущена так:
> $ other_prog | my_prog --(что-то неправильное) --(что-то правильное)
> или (еще веселее) так:
> $ other_prog1 | my_prog --(что-то неправильное) --(что-то правильное) |
> other_prog2
> то в этом случае имеет смысл проигнорировать неправильно введенные параметры,
> принимая во внимание только правильные и параметры по умолчанию.
Не вижу никакого смысла. Раз уж вы упомянули стандарт кодирования GNU,
то там ничего подобного нет. Зато есть такое:
Точно так же, не надо делать поведение программы зависящим от типа
используемого выходного устройства. Независимость от устройств является
важным принципом разработки систем; не следует пренебрегать им только
для того, чтобы уберечь кого-либо от необходимости задать лишнюю опцию.
Если Вы считаете, что один вариант работы программы более полезен при
выводе на терминал, а другой - при выводе в файл или конвейер, то
обычно лучше сделать, чтобы умолчанию подразумевался вывод на терминал,
и ввести опции для запроса других вариантов поведения программы.
> Вторая цитата:
> > Так я и имел введу игнорирование опций `--help' и `--version'. Если
> > быть более точным: я считаю излишним игнорирование опций `--help' и
> > `--version' когда на стандартном вводе программный канал (pipe). Какой
> > идиот будет использовать вызов:
> > $ other_prog |my_prog --version
> Здесь я согласен полностью. Для указанных ключей можно и отказаться от их
> игнорирования, но их дополнительная обработка у меня лично добавила менее 10
> строк в код программы.
Что значит дополнительная обработка? Что они у вас обрабатываются
больше одного раза?
> > из-за каких-то идиотов программы должны раздуваться? Прежде всего
> > программы (особенно консольные) пишутся не для удобства их
> > использования, а для выполнения определенных функций. Пусть лучше автор
> > больше уделит времени, гибкости программы, позаботится о том, чтобы
> > пользователь мог менять достаточное число параметров, позаботившись о
> > наличии соответсвующих опций.
> Добавление большого количество параметров ведь тоже раздует программу,
Если кушать, то можно и растолстеть. А если не кушать, то можно и
умереть. Не будем впадать в крайности. Просто я хочу сказать что лишний
код в программе, никому не идет на пользу, особенно когда речь идет о
свободном ПО. Тут никто не платит деньги за каждую строку кода.
> скорее всего, гораздо значительнее, чем обработка некоторых (специфических)
> парметров. Кроме того, насколько я понимаю, утилиты в *nix системах тем и
> отличаются, что, по возможности, делают что-то одно, но качественно. При грубом
> приближении можно сказать примерно так: "Одна задача - одна программа".
Именно так.
