Wine. Рабочий стол и консоль.

> пересобрать Xserver не получилось в виду отсутствия libutils

Зайди на http://build.opensuse.org/ и склонируй в свой репозиторий этот пакет. И наложи патчи. Я так с Wine сделал.

> в чём разница запуска одного и того же скрипта из консоли и из папки?

В KDE когда тыкаешь по файлу программы мышкой, её «рабочий каталог» /, а в GNOME когда тыкаешь по файлу программы мышкой «рабочий каталог» - каталог, в котором лежит программа. Поэтому для KDE нужно создавать скрипт запуска, в котором должно быть:

`readlink -f "$(dirname "$0")"`

Вариант «Вставить в скрипт запуск консоли, чтобы она запустила приложение» не прокатывает. Пробовал. Запуск такой же неработающий как из запуск не из консоли.

Хорошо, попробую. Вопрос в том, почему под другим пользователем прокатывает простой клик по скрипту из Krusadera? KDE и там и там...

Поищи в поисковике как такие скрипты делать, или посмотри скрипт любой игры.

#!/bin/sh

# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"

Xserver не получилось в виду отсутствия libutils, для сборки чего нужен libutils;

Так поставь libutils-dev тогда. А может это libutil из glibc?

Вот нет в стандартных репозиториях ни dev, ни просто. На том же http://build.opensuse.org/ поиск тоже ничего такого не находит. Glibc стоит, и bev, и utils.

Не думаю, что дело в путях. Оба способа запуска работают нормально и на первом пользователе и под рутом. Место, где запускается скрипт определяется нормально, ибо файл лога создаётся там, где запускается приложение и он создаётся именно там, откуда запускается скрипт. Создаётся в обоих случаях. Но в случае запуска руками из консоли - всё запускается, логинится и работает. А скрипт выдаёт TNS:could not resolve the connect identifier specified. Что это за ошибка понятно, сделано всё, чтобы от неё избавится. В одном случае запуска её нет, в другом есть.

#!/bin/bash
cd «$(dirname `readlink -f »$0"`)"

https://build.opensuse.org/package/show?project=openSUSE:13.1&package=xor... Регистрируешься, нажимаешь Branch, редактируешь SPEC-файл (добавляешь PATCHn в список файлов для распаковки, и затем %patchn), ждёшь когда скомпилируется, ставишь Public Flag чтобы открыть общий доступ к своему собственному OBS-репозиторию, добавляешь репозиторий через менеджер пакетов.

Скриншот. Выше я дал ссылку на неправильный пакет, нужный пакет этот: https://build.opensuse.org/package/show?project=openSUSE:13.1:Update&pack...

Вот нет в стандартных репозиториях ни dev, ни просто.

Ты бы написал точное сообщение, что не найдено, окончание вывода configure или где у тебя ошибка, начиная с последней беспроблемной строчки (ну или весь в крайнем случае).

Плюс почитай скрипт configure и поищи в нём строчку где упоминается, там будет видно, какая команда проверяет наличие libutils или что там.

У меня такого пакета нет, есть файл libutil.so принадлежащий пакету glibc но не в opensuse, http://rpm.pbone.net/index.php3/stat/4/idpl/23828893/dir/opensuse_12.x/com/fr...

Есть такое, но очень вряд ли что оно необходимо для сборки иксов.

Насчёт того, почему из одного запускается а из другого нет — возможно дело в переменных окружения.

Проверить можно если запишешь в скрипт команду типа env > somefile.txt а потом попробуешь запустить скрипт так и так и увидишь разницу, открыв этот файл.

Ещё вариант: env | kwrite --stdin &

Тогда сразу окно откроется. Далее сравниваешь содержимое переменных, и в случае наличия разницы прописываешь в скрипт команды типа export SOMEVAR=someval OTHERVAR=otherval ...

Таким образом методом исключения сможешь разобраться из-за какой переменной окружения не стартует.

Методом проб и ошибок я тоже дошёл до того, что что-то не так с энвайроментами. Вариантов как выяснить разницу ещё не искал. Спасибо за наводку как посмотреть разницу. Завтра буду смотреть. Даже уже посмотрел. При запуске из консоли TNS_ADMIN нормальный, по этому и логинится нормально, а при запуске «с рабочего стола» TNS_ADMIN смотрит совсем в другое место. Спасибо. Буду выяснять почему он вдруг смотрит не везде в одно место.

Что касается не сборки: При ./configure получаем сообщение: C compiler cannot create executables В логах ./configure пишет, что ошибка выполнения комманды что-то там ld - command not found. Попробовал собрать простейший сишный код из одной только комманды ld - тоже самое. И стоит она в самом начале configure. Некоторые изыскания в области того, почему не может быть у компилятора такой комманды привели к тому, что нет библиотеки и эта комманда предоставляется какой-то библиотекой из libutils. .rpm пакета не нашлось, а для того, чтобы собрать пакет из исходников нужно тот же самый ld.

Вообще пересборкой хочется добиться того, чтобы xserver не ругался на то, что Maximum number of clients reached. Во всех статьях говорится, что нужно поменять часть misc.h, добавить битов и поправить MAXCLIENTS с 128 на нужное. 512 хватило бы по заглаза. Но правка уже собранного и установленного xserver'a ничего не дала. 128 и всё. По этому единственный вариант, что приходит на ум это пересобрать его с изначальной поддержкой 512 клиентов.

что ошибка выполнения комманды что-то там ld - command not found.

Мог бы и погуглить. Это binutils а не libutils, один из наборов утилит GNU, должен быть в зависимостях build-essentials как и make, gcc и прочее.

Буду выяснять почему он вдруг смотрит не везде в одно место.

Смотри в файлы типа .bashrc .profile и тд в хоме. Можно вот такими командами узнать, где задаётся:

grep TNS_ADMIN ~/.[!.]*
grep -r TNS_ADMIN /etc

А точно, binutils, спутал... Нет его в стандартных, на build.opensuse.org нашёл, поставил, буду играться.

Смотри в файлы типа .bashrc .profile и тд в хоме. Можно вот такими командами узнать, где задаётся:

Я поступил проще - закинул файлы, на которые смотрит TNS_ADMIN туда, куда смотрят все. Остался вопрос в том, почему NLS_LANG не меняется у всех, хотя export его запускается самопальной службой. В прочем как и изменение TNS_ADMIN. В .bashrc уже давно прописал эти 2 экспорта. Так что, в принципе, они должны быть корректными для всего пользователя. Прописал в .profile. Посмотрим.

Это интересно, сделал тестовый файлик на «рабочем столе». В него вписал следующее:

env | grep TNS_ > 321
env | grep NLS_ > 4321

export NLS_LANG=....
export TNS_ADMIN=....

env | grep TNS_ > 3211
env | grep NLS_ > 43211

Прямо перед этим, в консоли, и под пользователем и под рутом, делал экспорт обоих параметров.

После прописания экспортов в .profile и перезапуске сеанса энвайроменты стали работать корректными везде.

Прямо перед этим, в консоли, и под пользователем и под рутом, делал экспорт обоих параметров.

Если прямо перед этим в той же консоли, то должно было бы работать.

Нет его в стандартных, на build.opensuse.org нашёл, поставил, буду играться.

Да не может его не быть, что-то ты не так делаешь, вот же он: http://rpmfind.net//linux/RPM/opensuse/12.3/i586/binutils-2.23.1-2.2.1.i586.html

хотя export его запускается самопальной службой

Команда export в шелле работает только для потомков этого шелла (скажем если запустишь из того же шелла startx то будет в иксах везде), но не для соседних шеллов.

Да не может его не быть, что-то ты не так делаешь, вот же он: http://rpmfind.net//linux/RPM/opensuse/12.3/i586/binutils-2.23.1-2.2.1.i586.html

12.3. А в стандартном репозитории 13.1 его нет. Странно, но факт. С build.opensuse.org yum добавил репозиторий и с него стянул binutils.

Если прямо перед этим в той же консоли, то должно было бы работать.

В этой же консоли и работало, вне её - уже нет.

Команда export в шелле работает только для потомков этого шелла (скажем если запустишь из того же шелла startx то будет в иксах везде), но не для соседних шеллов.

В общем понятно. Спасибо. Если что - теперь понятно куда копать. Перезапустил систему и профили - нормально работает без шаманства.