Во-первых, можно использовать и startx
Во-вторых надо выполнить "sudo gpasswd -a username audio" чтобы был звук.

Как именно через startx?

startx ~/.config/bin/game.sh -- :1
В скрипте можно попутно отключать компиз:
metacity --replace & $@; compiz --replace
А то автор мельком написал про компиз, но не написал что простой запуск 2-го X-сервера будет так же с компизом, который часто замедляет OpenGL приложения, особенно wine-игры.

Этот скрипт все делает за вас, и в случае закрытия игры так-же закрывает х сервер и.т.д

Я через startx запускал пару игр и при закрытии X также закрывался. Не вижу разницы. Просто привел альтернативный вариант.

Я вас не упрекал :)

А разве не нужно скопировать скрипт в /usr/local/bin? Иначе как заставить его запустится из папки с игрой?
Кроме того, возвращение на робочий сервер через CTRL+ALT+F7, игра -- на CTRL+ALT+F8.
А так у меня все заработало, спасибо!

У меня игра на ctr+alt+f8, а рабочее пространоство на ctr+alt+f1.

интересно, однако. Я думал, иксы всегда на 7 консоли стартуют..

Иксы стартуют там, где ты им укажешь. Просто 7я консоль по дефолту получается.
Если консоль икс-серверу не указана, то он берёт первую свободную. Обычно, в большинстве дистров по дефолту, первые 6 консолей заняты процессами логина (getty или аналогом), а 7-я свободна, на ней никаких процессов не запущено, вот её иксы и берут.

Пользуюсь старичком xgame.

у меня не сработало. Пишет xlaunch: команда не найдена. Делал так:
сохранил скрипт в файле /home/samath/scripts/xlaunch
chmod 755 /home/samath/scripts/xlaunch
chown samath:users /home/scripts/xlaunch
sudo gpasswd -a samath audio

Пробовал xlaunch кидать в /usr/local/bin. При запуске, например кс:
xlaunch wine hl.exe
получаю
Starting /usr/bin/wine on DISPLAY 1
и все, больше никаких признаков жизни.

P.S. Вообще на десктопе игры запускаю в отдельном икс сервере другим способом. Но решил попробовать этот, т.к. мой старый метод хреновенько срабатывает на нетбуке - кс запускается с артефактами и играть не возможно.

Я делал так:
xinit /usr/bin/openarena -- :1

Шикарный скрипт. У меня чуть-чуть попроще, не эффект, похоже, тот же.
В /usr/local/games/bin/ лежат скрипты с таким содержанием:
#!/bin/bash
X :2 -ac -terminate &
sleep 2
sudo -u gamer LC_ALL=ru_RU.UTF-8 LANG=ru_RU.UTF-8 env WINEPREFIX='/home/gamer/heroes' WINESERVER='/usr/bin/wineserver' WINELOADEr/lib32/wine' WINEARCH='win32' DISPLAY=':2' /bin/sh -c " cd '/home/nerewar/heroes/drive_c/Program Files/Heroes of Might and Magic V /usr/bin/wine 'H5_Game.exe' 2>&1 "
Игра запускается в отдельном Х-сервере и из под специального игрового пользователя. Ярлыки на скрипты добавлены в wbar для полного удобства.

Я криворукий идиот, наверно. Скачал, выполнил, даже в /usr/local/bin положил, но:
%xlaunch.sh wine /mnt/D-Games/Games/Two\ Worlds\ II/TwoWorlds2.exe
Error: can't find launch.sh:
- Is it in you PATH?
or
- Do you have enough right to execute it?

И с sudo аналогично.

Удалил расширение и выполнил из папки с игрой: Starting /usr/bin/wine on DISPLAY 1
Но я не один такой, это радует.

echo $PATH - покажет какие пути у тебя в PATH. Только по этим путям программа будет выполнена без указания самого пути до программы (или скрипта). В любом случае, никто не мешает указывать полный путь, например, /usr/local/bin/xlaunch.sh wine /mnt/D-Games/Games/Two\ Worlds\ II/TwoWorlds2.exe

Мне никто и не помешал. но результат тот же или Starting /usr/bin/wine on DISPLAY 1
Т.е. fail

Понажимай Alt+Ctrl+F<1-8> может просто не происходит переключения на новую запущенную X-сессию.

Проверял.

Вот честно, по шапке бы надавать за такую "инструкцию"

Почему /home/scripts? Этот путь есть у всех?
Зачем chown?
Почему добавив в /home/scripts мы уже вдруг можем вызывать скрипт без указания пути? Это что, стандартный путь для $PATH?

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

Прошу прощения...Когда писал-сильно болела голова(в моем городе заметель, а я уж сильно реагирую на погоду :( )...Только в "нормальном" состоянии понял, что много чего не указал. Естественно, для удобсват нужно создать папку:
sudo mkdir /home/scripts .

А еще после этого нужно открыть файл ~/.bashrc в текстовом редакторе и прописать:

export PATH=$PATH:/home/$USER/scripts

и перезапустить терминал, из которого будете запускать свой скрипт.

После таких манипуляций не надо будет писать полный путь к скрипту.

Зачем создавать эту папку, когда есть /usr/local/bin ?

Зачем туда кидать непонятные скрипты, нужные лишь одному пользователю?

Да, лучше для этого создавать левую папку в /home, добавить её в $PATH... Зачем по-твоему стандартные пути существуют? /usr/local/bin как раз для пользовательских скриптов и программ существует. Не надо изобретать велосипеды. И, если уж на то пошло, и не хочется выносить личные скрипты куда-то там, то и для этого, есть стандартный путь ~/bin - для каждого пользователя свой.

Неправильно, /usr/local не для пользовательских скриптов, он для:

Пользовательские скрипты устанавливаются именно в пользовательской директории. Я обычно устанавливаю их в директории ~/bin
Почему не нужно устанавливать их в /usr/local/bin?
Потому, что не всегда приходится работать на машине, где работает только один пользователь, не всегда даже права root есть на данной машине.
Когда несколько пользователей начнут класть свои скрипты в директорию /usr/local/bin, очень вероятны конфликты имен и вообще непредсказуемые вещи, типа запустили скрипт, не совсем обратив внимание на имя (оказалось похожим или вообще такое же, а Ваш затерт) и он выполнил совсем не то, что Вы хотели.
Опять таки свои скрипты, это часть рабочего окружения, удобно, когда копируешь свою заготовку для домашнего окружения и вот уже все работает.
Часто домашние директории пользователей и самих пользователей используют для размещения разных проектов на одной и той же машине (Очень удобно!) Там скрипты с одним именем могут выполнять одни и те же действия.
У меня на блоге статеечка есть, которая немного касается тих вещей.

Пардон, седует читать: Там скрипты с одним именем могут выполнять разные действия.

Дайте ссылочку на почитать. Можно в личку, а то еще рекламой сочтут.

А что делать если home смонтирован с noexec?

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

Есть мнение, что noexec на скрипты не распространяется. ?

$ ./test.sh
-bash: ./test.sh: Permission denied
Вполне себе распространяется.

k. в следующий раз буду уточнять, что я имею ввиду.

$ sh ./test.sh
Вот так.

/bin/bash /home/blablabla
?

$ /bin/bash ./test.sh
Hello world!
А вот это работает.

Да ну. А у меня чего-то не работает.... Если конечно не добавить ~/bin в $PATH.

Так что это либо наглое 4.2 либо давайте ссылку на стандарт (или какой-то другой документ).

А в арче по-умолчанию не работает /usr/local/bin

в стандарте про скрипты в /home ничего не прописано.

вот цитата про /usr/local


Так что пользовательские скрипты лучше кидать туда. Ибо они и есть то самое "ПО, которого нет в репозитарии"

Не совсем так.
Пользователей может быть много. Каноническая схема:
- иерархия /usr - софт дистрибутива, общий для всех хостов с этим дистрибутивом, ставит администратор
- иерархия /usr/local - софт не входящий в дистрибутив, общий для хоста, ставит администратор
- иерархии /home/$USER - для пользователей, ставят пользователи, каждый себе сам.
Если делать по другому, рано или поздно будут конфликты.

Другими словами - /usr/local - это то место, куда скидывается то, что не из репозиториев. Для домашней машины пользователь и есть администратор, так что /usr/local - как раз для него.
Если хочешь, чтобы твои скрипты были доступны не только тебе, но и другому пользователю, то в /usr/local/bin - им как раз и место. Не хочешь или нет прав на /usr/local/bin - тогда в ~/bin.

Есть и еще нюансы.
На пользовательские скрипты не нужно делать sudo
В общем, если общие для всего хоста, то да, /usr/local/bin
Если индивидуальные для пользователя, то $HOME, я обычно делаю $HOME/bin
чтобы не заморачиваться, это всем ясно.

Так и на скрипты в /usr/local/bin не надо делать sudo. Для тех скриптов/программ, которым обязательно нужны права root - есть */sbin

Это же пользовательские скрипты, иэ нужно редактировать, добавлять.

Для домашней станции проблем с добавлением и редактированием быть не должно - здесь каждый сам себе админ и права рута есть если не у самого пользователя, то у папы/брата/дяди - точно. В остальных случаях добавлять скрипты для всех пользователей и не нужно, хватить и ~/bin

Вот значит диру в /home добавить в $PATH - можно, а ~/bin - это ж так сложно.

Это ведь ваши слова, так ведь? :)

Вот именно. ~/bin - это стандарт, во многих дистрах оно отключено по-умолчанию, но от этого оно не перестаёт быть стандартным местом для пользовательских скриптов. А всякие /home/scripts - это изврат.

Пруфлинк то будет или нет? Или номер стандарта. Это HFS или POSIX какой?

То, что есть надо ртом, а не задницей - стандарт, хотя и не записано ни в каких ГОСТах...

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

Спокойнее надо быть. И подтверждать свои слова фактами.

Ну вот и подтверди мне, что есть ртом - врождённый инстинкт, ок?

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

Автор, поправь шапку
sudo mkdir /home/scripts
Во-первых в шапке уоманда md, которой не существует
Во-вторых, более трушно сделать mkdir ~/.scripts

echo PATH=\"\$PATH:/home/scripts\" >> ~/.bashrc
Лучше заменить на
echo 'export PATH=$PATH:/home/$USER/.scripts' >> ~/.bashrc
Т к я лично не понял смысла экранировать кавычки, да и слово export вроде нужно.
#к сожалению, у самого .bashrc давно удален случайно. Как-то живу без него ;)

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

Там же новая сессия, придётся вручную/через скрипт запустить stexkbmap/gconf-daemon/kde-config-daemn/whatever.

Всетаки не понял. У меня гном. Можите привести пример скрипта?

Скрипт старый и в нём многабукаф, лень разбирться. ? Нужно добавить вызов gnome-settings-daemon перед загрузкой игры на соответствующем дисплее.

Запускаю в отдельном икс-сервере openbox, а из его меню нужную игру. Так же в меню добавил пункт "Logout", который убивает игровые иксы. Удобнее ничего не видел.

Я использую awesome, запускую игру в оконном режиме, с размером окна в размер экрана, на отдельном теге. Делаю его на весь экран и управляю им средствами вм. Никаких лишних сущностей. Удобнее ничего не видел. ?

В большинстве случаев поступаю так же, но некоторые игры плохо уживаются с WM, особенно таким необычным, как awesome. Вот для них и приходится запускать отдельно голые иксы с игрой в качестве главного клиента.