:-)))

> и /me так и не понял чем плохо держать скрипты, которые нах не нужны ни другим пользователям, ни системе в юсербине, и более того, как сферический пользователь в вакууме их туда засунет не зная рутовый пароль(а пароль он не знает, т.к. юзер сферический)?
> а если скрипт с пользователем никак не взаимодействует?:)
Прочитай таки весь трэд %)

При поиске по словосочетанию "слака сосёт" гугл находит 1100 страниц, посвящённых этому вопросу, в то время как при поиске "слака сосет" находится 1300+ страниц на ту же тему. А Яндекс находит по 3555 страниц для любого из двух вариантов.

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

ой-вей, как будто у тебя в хомяке помойки нет))) и /me так и не понял чем плохо держать скрипты, которые нах не нужны ни другим пользователям, ни системе в юсербине, и более того, как сферический пользователь в вакууме их туда засунет не зная рутовый пароль(а пароль он не знает, т.к. юзер сферический)?

>Алсо, про взаимодействие скрипта и пользователя выше уже обсудили.

а если скрипт с пользователем никак не взаимодействует?:)

вот не надо этого: я честно следовал инструкции и у меня ничего никуда не срало)

неужели кто-то отменил пермишены и овнеров?:)

с чего бы? у меня некоторые самописные скрипты лежат в ~/bin почему бы их из иксов и не запустить? тем более что в нормальных системах они никуда не гадят.)))

Я, видимо, сегодня очень туманно излагаю мысли. Смысл всех моих опусов сводится вот к чему: Сабжевая проблема была вызвана тем. что пользователь ткнул мышью в не графическую программу и та загадила ему .xsession-errors. Так вот, эта проблема для линукса не актуальна т.к. у сферического пользователя в вакууме не валяются где-попало бинарники и вызов программ осуществляется через .desktop-файлы, а не графические программы лежат на своих местах подальше от шаловливых ручонок пользователя. Вот такое вот разделение.

Утверждение, что "пользователь не должен запускать бинарники напрямую" стоит понимать как "у пользователя не должно возникнуть такой необходимости". Больше не знаю, как разжевать свою мысль :)

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

>> Мое мнение такое: не должно происходить вызова не графических прог из графики _пользователем_
> Как минимум для этого должен сначала воскреснуть ОН и разделить проги на графические и неграфические, а проги которые подобно мэплееру могут работать так и так - ниспослать в адЪ.
Никому воскресать для этого не надо, и так вызова пользователем не графических прог из граф. оболочки не происходит. Многие не графические проги уже распиханы по менюхам и запускаются сразу в терминале(htop, octave, etc). И на виду у пользователя бинарники не валяются, чтобы тыкать в них ненароком.

> Мне кажется, там все таки должны храниться ошибки. А для тестирования работы не графической проги(вот только может ли это понадобиться?) stderr и stdout можно направить вместе куда захочется тестеру.
Ошибки встречаются не только при тестировании системы, а по единственному выхлопу stderr понять что делала прога когда данная ошибка произошла не всегда возможно.

> Вкратце: не кошерное поведение пользователя влечет не кошерный отклик системы %)
Да, это плохо. В идеале система должна как-то обозначить, что она команду поняла и приступила к исполнению, а при возникновении ошибок - как-то привлечь внимание пользователя к ним. Мне кажется, что голосовая озвучка событий тут идеально подошла бы. Ну что стоит сказать в динамики "бэкап запущен", "бэкап успешно завершён", "тоарищ пользователь, разрешите доложить, что при выполнении бэкапа произошла непредвиденная ошибка" и т.п.

> И чтобы знать о ходе работы скрипта, ты бы все равно его запустил в терминале, чем постоянно заглядывать в .xsession-errors :)
А зачем за ним следить? Ну он работает там себе и работает. А оператор должен заниматься своим делом.

> Мое мнение такое: не должно происходить вызова не графических прог из графики _пользователем_
Как минимум для этого должен сначала воскреснуть ОН и разделить проги на графические и неграфические, а проги которые подобно мэплееру могут работать так и так - ниспослать в адЪ.

Мое мнение такое: не должно происходить вызова не графических прог из графики _пользователем_

> Лог ошибок для того и служит что бы определить что что-то пошло не так
> и стандартный вывод тоже должен куда-то протоколироваться, при этом лучше что бы туда же, куда и stderr
Мне кажется, там все таки должны храниться ошибки. А для тестирования работы не графической проги(вот только может ли это понадобиться?) stderr и stdout можно направить вместе куда захочется тестеру.

Вкратце: не кошерное поведение пользователя влечет не кошерный отклик системы %)

У проги есть выбор когда завершиться - по скончанию конка/долфина или по какому-то другому событию если ей насрать на EOF. Лог ошибок для того и служит что бы определить что что-то пошло не так (хотя при этом не совсем логично делать файл скрытым, т.е. с именем, начинающимся с точки..) и стандартный вывод тоже должен куда-то протоколироваться, при этом лучше что бы туда же, куда и stderr - а то потом замучаешься определять в какой последовательности у тебя происходил нормальный вывод и вывод ошибок (хотя буферизация, как мы видели выше, тут тоже подкладывает своё западло в моём случае). И надо учитывать, что дочерняя консольная прога может быть небесполезной при запуске таким способом. Консолльная программа может что-то там делать в фоне как например какой-нибудь бэкапный скрипт - тебе с ним не о чем разговаривать, всё что от него нужно - это успешно завершиться. Если этого не произошло - как узнать почему? Смотришь в тот самый файл. И чем больше информации будет в логе - тем легче изолировать проблему. В общем, я бы оставил всё как есть...

А вот пихать под нос пользователю бинарники - это windows-way какой-то.

И пробуй на упрощённых тесткейсах, типа такого:

И увидишь, что у тебя выход из scanf осуществляется при получении EOF, что правильно. А переменная c будет содержать то, что в ней до этого было или мусор - не важно, это по смыслу всё равно мусор раз вместо ввода получен EOF.

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

ну, думаю проблема разрешилась окончательно.

ну а коли мы все так дружно к этому приложили усилия, теперь думаю имеет смысл подумать что с этим делать - забить, решить (написать патч) или написать кому-нибудь челобитную. как считаете?

и все же как по мне, так это бага кед. на мой взгляд на stdin проги, должен вешаться /dev/null, что собственно и происходит в dolphin (с предком исследуемой программы). но по какому то разумению, dolphin вешает pipe на вход запускаемой программы. почему??? с какой целью??? вряд ли он мог что то туда послать или нет?

Но сперва про пайп. Я программку ту тестовую которую приводил выше, назвал "test_output_program_nah" - ну, по привычке что бы ни с чем не перепутать. Запустил из конка:

Смотрим какие файлы у неё открыты:

Нулевой дескриптор подключен к пайпу. Это единственный пайп, который она юзает. Смотрим кто юзает FIFO на ус-ве 0,6 которому соответствует inode 5004901:

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

Смотрим кто теперь владеет пайпом:

А пайп другим концом ни к чему не подключен. Конк умер, а больше никому и не надо.

Но вот чего непонятно - так это то, что согласно выхлопу lsof выше - у тестовой проги оба дескриптора 1 и 2 подключены к .xsession-errors - т.е. вывод должен идти от обоих fprintf'ов, но я у себя вижу только строчки с <STDERR>. Куда деваются <STDOUT> - видимо буферизуются. Добавил вызов "fflush(stdout);" в тестовый код и теперь вывод обоих fprintf'ов пошёл в .xsession-errors.

Делаю man stdout и читаю там: "The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed." Ничего не понимаю - newline же вроде как printed, а не печатало без флуша. Так что твоя система правильнее работает :)

id 2021 соответствует kdeinit4: kdeinit4 Running...

насчет pipe это канал связи родительского и дочернего процесса, т.е. у нашей испытуемой программы на вход подается нечто от предка, на мой взгляд так это косяк кедов, почему на stdin не идет /dev/null, а поступает какая то кака от предка, после завершения этого предка, потомок ясен пень будет ловить EOF.

кто согласен что кеды ведут себя в этом плане несколько не адекватно?

В любом случае lsof может тебе помочь.