В первую очередь, менеджер по оформлению (или DM, например, xdm, gdm, kdm) не является тем же как Настольной средой (или DE, например, GNOME, KDE, XFCE).
Менеджер по оформлению заботится о графическом входе в систему и решает (или позволяет Вам выбрать), что сессия работать. Или что session*s* в случае, если Вы выбираете пункт меню "switch user".
Настольная среда является в основном набором программ (менеджер по оформлению, менеджер окон, менеджер сеансов, панели, инструменты конфигурирования, и т.д.) и библиотеки (например, Gtk), которые намереваются дать последовательную и интегрированную среду для работы в.
Менеджер окон управляет окнами: куда разместить их, переместите их, измените размер их, минимизируйте/максимизируйте их, разместите их рядом, и т.д.). Это также обрабатывает ярлыки, чтобы сделать те вещи. В некоторых случаях менеджер окон также красит границы окон, в других случаях эта задача является бесцеремонной "декоратору окна".
"Запущенное Приложение" диалоговое окно в GNOME является частью gnome-panel
, но в другом DE это могла быть другая часть среды.
Кто отвечает за рисование окон, и т.д. зависит; в случае, если существует используемый "наборщик" (часто часть менеджера окон, например, в Compiz) затем, наборщик красит окна на экране, иначе (как было обычно в прошлом), это - X-сервер, делающий это.
Главное меню помещается на экран частью панели гнома, но используемые данные прибывают из набора файлов в /usr/share/applications/
(возможно объединенный с эквивалентным каталогом в Вашем доме для персональных изменений). Тем файлам определил структуру FreeDesktop.org (платформа для другого DES для сотрудничества на общей инфраструктуре), так, чтобы GNOME и KDE знали о тех же программах (но все еще может показать им по-другому и в некоторых случаях расположить по приоритетам "собственные" программы по "внешним").
И да, различные пользователи могут использовать другую конфигурацию сессии (и может даже определить их собственные). В GDM попробуйте Сессию, выпадающую за доступный выбор.
Кроме того, возможно смешать и соответствовать нескольким компонентам, но это будет иногда приводить к меньшему сотрудничеству и потере "гладкости" в том, как работают вещи. Одним очень хорошо известным примером, где вещи получают обмены, является, конечно, Compiz, который заменяет Метагород, если Вы хотите необычные настольные эффекты. Но существует много других возможных изменений.
Существуют некоторые просто проблемы Unixoid-оболочки здесь, я надеюсь, что MSYS не добавляет дополнительные проблемы, также.
Выполнение нескольких уровней заключения в кавычки может быть хитрым. Я обычно предпочитаю избегать их, если это возможно.
Модификация ниже использует $@
параметр, чтобы сохранить и получить аргументы, которые встроят пробел. Если Вам нужны несколько таких списков споров со встроенным пробелом, и Ваша оболочка имеет параметры массива, Вы могли они (так как существует только один из $@
).
# assume BUILD_CORES is simple enough that it will not need extra quoting later...
BUILD_CFLAGS='-mtune=core2 -flto -fomit-frame-pointer -momit-leaf-frame-pointer'
BUILD_LFLAGS="-flto -fwhopr=$BUILD_CORES"
set -- --prefix="$PREFIX" --host="$HOST" --build="$BUILD" CFLAGS="$BUILD_CFLAGS" LFLAGS="$BUILD_LFLAGS"
makeopts="-s -j$BUILD_CORES"
# libiconv
cd libiconv
echo "configuring libiconv: $@"
../../src/libiconv/configure "$@" > configure.log || exit 1
Для Ваших установленных требований можно сойти с рук просто этот единственный уровень защиты, но если Вам были нужны несколько уровней заключения в кавычки (например, если BUILD_CORES
содержавший пробел Вы имели бы дело с несколькими уровнями заключения в кавычки: один уровень заключения в кавычки в makeopts
/BUILD_LFLAGS
, и два уровня заключения в кавычки в CONFIG_OPTS
). В этом случае я мог бы обратиться к использованию printf
с %q
и eval
. %q
спецификатор формата доступен в большинстве, но не всех, оболочки (ksh, удар, zsh). Это заключает свое значение в кавычки так, чтобы это могло позже быть оценено правильно.
BUILD_CFLAGS='-mtune=core2 -flto -fomit-frame-pointer -momit-leaf-frame-pointer'
BUILD_LFLAGS=$(printf '%s-flto -fwhopr=%q' '' "$BUILD_CORES")
CONFIG_OPTS=$(printf \
'%s--prefix=%q --host=%q --build=%q CFLAGS=%q LFLAGS=%q' '' \
"$PREFIX" "$HOST" "$BUILD" "$BUILD_CFLAGS" "$BUILD_LFLAGS")
makeopts=$(printf '%s-s -j%q' '' "$BUILD_CORES")
# libiconv
cd libiconv
echo "configuring libiconv:" "$CONFIG_OPTS"
eval ../../src/libiconv/configure "$CONFIG_OPTS"
echo "building libiconv"
eval make "$MAKEOPTS" > build.log || exit 1
В данном случае необходимо было бы также заботиться, что что-либо, что добирается LFLAGS
от настраивают, будет знать, как “считать” заключенное в кавычки значение, которое произвела оболочка. Это могло быть проблемой, если сценарий записан на языке оболочки где %q
производит конструкцию что оболочка по умолчанию в системе (т.е. /bin/sh
) не понимает (например, ksh будет иногда производить $'blah'
конструкции, но некоторые оболочки не знают, как проанализировать их).
Обратите внимание, что Вы не определяете ПРЕФИКС в своем сценарии, таким образом, он должен быть определен в другом месте для этого для работы, но я думаю, что Вы хотите (Предупреждение: Я не сделал никакого тестирования на этом.):
BUILD_CFLAGS="\"-mtune=core2 -flto -fomit-frame-pointer -momit-leaf-frame-pointer\""
BUILD_LFLAGS="\"-flto -fwhopr=${BUILD_CORES}\""
CONFIG_OPTS="--prefix=${PREFIX} --host=${HOST} --build=${BUILD} CFLAGS=${BUILD_CFLAGS}
LFLAGS=${BUILD_LFLAGS}"
MAKEOPTS="-s -j${BUILD_CORES}"
Заметьте что при использовании двойных кавычек, что переменная будет расширена в строке (часто названный интерполяцией переменной). Кроме того, я полагаю, что Вы не соответствовали кавычкам в своем исходном сценарии, которые также, вероятно, вызывали Вас проблемы.
eval
точно, что было необходимо. Я просто использовалBUILD_CFLAGS="\"...\"" ... CONFIG_OPTS="..$BUILD_CFLAGS" ... eval ../../src/libiconv/configure "$CONFIG_OPTS$"...
версия и это работают, как это должно теперь.Спасибо! – rubenvb 17.09.2010, 20:07"..."$CONFIG_OPTS"
без последнего$
– rubenvb 17.09.2010, 20:37