Покажите 1) где и 2) как устанавливается PATH в нужное значение до того, как портится.

Если правильно путаю, разумно сделать так:
/etc/profile.d/kde3.sh

#!/bin/sh
PATH="/opt/kde3/bin:$PATH"
export PATH

# chmod a+x /etc/profile.d/kde3.sh

добрый день

да «как угодно» можно устанавливать PATH, хоть в ручную принудительно установить, типа

export PATH="blah-blah-blah"

отладочное старт-стоп эхо - показывает правильное формирование PATH (в самом скрипте), но как только стартуют кеды, значение PATH возвращается на «стандартное значение» (при том, что, все остальные сформированные переменные принимают «правильное» значение)

неправильно путаете

так делать НЕРАЗУМНО - по причине доводки СОВМЕСТИМОСТИ С ДРУГИМИ KDE-ПОДОБНЫМИ столами, типа TDE,KDE4 etc...

p.s. шо же вы меня за идиота держите... :о) обидно жешь, ешкин кот... эх хе хеее...

p.s.2 VboxImage - только что загрузинился, если есть желание помочь, велкам :о)

И незачем так орать. (q)
Вы не можете из своего скрипта изменить родительское окружение (environment), поэтому что там у вас в скрипте — до лампочки.
Единственное исключение — выполнение скрипта в контексте текущего окружения при помощи команды "." (точка), она же source (но это башизм). Именно так исполняются сценарии из /etc/profile.d/, см. /etc/profile.

это я не матерюсь, я так разговариваю и думаю ...

да в курсе, поэтому и воспрашаю тут :о)))

но ведь ИНЫЕ переменные устанавливаются СЕБЕ так как надо, чем PATH хуже?

к стати, они, эти переменные, так же извне уже существуют и имеют «начальные значения», которые прекрасно «модифицируются» в startkde

так делать НЕРАЗУМНО

Можете создать отдельную группу, скажем kde3, в /etc/profile.d/kde3.sh проверить, принадлежит ли ей пользователь.

Пожалуй, до получения ответов на вопросы (1) и (2), а также, где именно это мешает, что именно пытаетесь чинить, воздержусь от советов, ибо пока непонятно :-)

создать группу

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

добавим пользователья в группу kde3, проверим и что далее? (пока не доразумил, пендель нужОн, видимо)

но ведь ИНЫЕ переменные устанавливаются СЕБЕ так как надо, чем PATH хуже?

Посмотрите дерево процессов (мысленно включите в него уже завершившиеся процессы).
Если вы пытаетесь поменять значение PATH ниже по иерархии, то процессы выше по иерархии вашего изменения не видят, а видят только тот, где меняете, и его потомки.

Поэтому повторюсь:

Покажите 1) где и 2) как устанавливается PATH в нужное значение до того, как портится.

А также, портится при 3) startx и/или 4) старте из дисплейного менеджера.

XDG_CONFIG_DIRS и XDG_DATA_DIRS - определяется (начальные значения) в /etc/profile.d/* - а это изначально повыше процесс (имхо), а уже «фысе» потом стартует ...

ну вот примерно так (имхо, могу ошибаться)

/etc/profile.d/*.sh - начальная установка переменных окружения
/etc/rc.d/rc.4 -> call KDM3
KDM3 -> call $KDE3/share/apps/sessions/kde3.desktop --> startkde

так, что все переменные созданные в profile.d - являются «вышестоящими»

ну типа, могу ошибаться :о)

1) где и 2) как устанавливается PATH в нужное значение до того, как портится.

писал же уже, да хоть принудительно установи в startkde, типа

export PATH=/opt/kde3/bin:<blah-blah-bla>

если в blah-blah-bla - не будет стандартных путей, то startx, естественно не запустит KDE

ну а так, «что да как» - в startx - большой кусок, с функциями, которые «проверяют наличие строк в переменных, в.ч. и в PATH, выдерают, устанавливают так как надо»... но это все ЕРУНДА, т.к. во первых уже проверено, что функции отрабатывают нормально, а второе - это ПРОСТО ПРИНУДИТЕЛЬНАЯ установка PATH - не помогает, ПРИНУДИТЕЛЬНАЯ МАНУАЛЬНАЯ... повторюсь, я, возможно что то не понимаю и туплю... спасибо :о)

дополнительно

PATH - определяется, втч и в /etc/profile.d/

есть такой доп. скрипт, корректирующий PATH

if [ ! "$(echo $PATH | grep $HOME/bin)" -a -d $HOME/bin       ]; then PATH=$HOME/bin:${PATH}; fi
if [ ! "$(echo $PATH | grep :.)"        -a ! "$(id -u)" = "0" ]; then PATH="${PATH}:."      ; fi

export PATH

надеюсь, тут все понятно... ну и еще PATH доводится в профиле пользователя в ~/.bashrc / ~/.bash_profile:

if [ ! "$(echo $PATH | grep /sbin)"                     ]; then PATH=$PATH:/sbin            ; fi
if [ ! "$(echo $PATH | grep /usr/sbin)"                 ]; then PATH=$PATH:/usr/sbin        ; fi
if [ ! "$(echo $PATH | grep /usr/local/sbin)"           ]; then PATH=$PATH:/usr/local/sbin  ; fi
if [ ! "$(echo $PATH | grep $HOME/bin)" -a -d $HOME/bin ]; then PATH=$HOME/bin:$PATH        ; fi
export PATH

как видно, PATH ни где не «обнуляется» И только ДОПОЛНЯЕТСЯ

add

А также, портится при 3) startx и/или 4) старте из дисплейного менеджера

startx - это же немного другая история:

/etc/x11/xinit/xinitrc-->xinitrc.kde3

для отладки напихал в xinitrc.kde3 - «всяких доп. определений»

export        KDE3=${KDE3:-/opt/kde3}
export         KDE=$KDE3
export     KDEDIRS=$KDE3
export    KDE3DIRS=$KDE3
export     KDEHOME=$HOME/.kde3
export KDEROOTHOME=$KDEHOME
export     XINITRC=xinitrc.kde3

userresources=$HOME/.Xresources
   usermodmap=$HOME/.Xmodmap
 sysresources=/etc/X11/xinit/.Xresources
    sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources  ]; then xrdb -merge $sysresources  ; fi
if [ -f $sysmodmap     ]; then xmodmap     $sysmodmap     ; fi
if [ -f $userresources ]; then xrdb -merge $userresources ; fi
if [ -f $usermodmap    ]; then xmodmap     $usermodmap    ; fi

if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then ck-launch-session $KDE/bin/startkde
else                                                                                  $KDE/bin/startkde ; fi

все переменные нормально доживают до рабочего стола...

PATH я не трогаю, т.к. формировать его надо в любом случае в startkde (ну и ко всему прочему в TDE-14.x это нормально реализовано, не могу понять в чем трабла)

мы же стартует уровни/KDE стандартно init 4 а не startx - т.е. запуском

kdm3 --> startkde

add

для эксперимента добавил в

/etc/x11/xinit/xinitrc-->xinitrc.kde3

export XDG_DATA_DIRS=$XDG_DATA_DIRS:/xinitrc.kde3 

переменная нормально дожила до рабочего стола и БЫЛА дополнена (функциями из startkde), как и предполагалось, префиксом KDE (и «/usr/local/share» - был ВСТАВЛЕН перед «/usr/share», теми же функциями в startkde)

XDG_DATA_DIRS=/xinitrc.kde3:/opt/kde3/share:/usr/local/share:/usr/share

То есть у тебя Slackware и ты запускаешь KDE через установку четвёртого уровня запуска, так? Тогда проследи что в каком порядке запускается, может и будет понятно. Возможно, PATH тоже устанавливается в твоём скрипте но потом каким-то другим скриптом меняется обратно. Можешь попробовать погрепать по текущему значению PATH, может и найдёшь.

Говоришь, при пустом профиле, PATH всё равно неправильный? Тогда погрепай где он упоминается в etc: grep -r -C 3 PATH /etc

спасибо

перерыл весь /etc/* не предмет PATH - ни чего интересного, т.е. не помогло, если PATH где и «манипулируется» - то это либо «добавление», либо «чтение»...

да и собственно, /usr - тоже перерыл...

п.с. упс...

ну а так, все вроде прозрачно и понятно, что и когда стартует

/etc/profile.d/*.sh - начальная установка переменных окружения
/etc/rc.d/rc.4 -> call KDM3
KDM3 -> call $KDE3/share/apps/sessions/kde3.desktop --> startkde

ну а далее сами кеды стартуют...

так, видимо, будет более полно

/etc/profile - тут начальные установки PATH (жестко прописаны)
/etc/profile.d/*.sh - начальная установка переменных окружения (PATH - только дополняется)
/etc/rc.d/rc.4 -> call KDM3
KDM3 -> call $KDE3/share/apps/sessions/kde3.desktop --> startkde - тут мы модифицируем PATH

ну а далее сами кеды стартуют...

тов. БОРМАНТУ

Вы не можете из своего скрипта изменить родительское окружение (environment), поэтому что там у вас в скрипте — до лампочки.

дело в том, что мы не выходим из скрипта startkde в котором формируем переменные, а из него же и стартуем кеды, т.е. кеды по отношеню к скрипту startkde являются дочерним процессом...

т.е. startkde получил «родительское рабочее окружение», подредактировали его, и запустили другой процесс - САМИ КЕДЫ, передав ему «текущее рабочее окружение»... а сам startkde так и продолжает болтаться в процессах, до окончания работы «кедоф», а потом, когда кеды сваливают, занимается еще и «зачисткой» за ними и только потом управление возвращается к kdm3, и все повторяется ...

я так думаю (мимино)

### UPDATE ###

наверное, мне надо было «дотошно» все обьяснить сразу же... не все же занимаются такой-же фигней как и я :о)

короче, обьясняю: при «обычном раскладе», все - естественно, как обычно и всех устраивает :о)

можно PATH просписать где угодно и как угодно и он во время работы под любыми десктопапи (XFCE, KDE, LXDE...) будет устраивать всех... не будет никаких косяков...

но, если надобно «встроить в систему» родственные десктопы, у которых имена практически совпадают на 100%, как то KDE3/KDE4/TDE3/TDE14 - то тут, упс, один путь на все уже не катит, ведь странно же будет, если из под третьих кед запустить konsole - и получить консоль от 4х кед ... или которые там попадутся первыми в PATH ... это вкратце, надеюсь далее обьяснять не надо, сами допедрите :о)

ну дак вот, что бы избежать всей этой путаницы нужна "ДИНАМИЧЕСКАЯ НАСТРОЙКА ОКРУЖЕНИЯ", в зов-ти от запускаемого рабочего стола, причем эта самая настройка должна происходить во время запуска DE...

изначальная задача была - интеграция KDE3 в совместное проживание c KDE4 (само собой что PREFIX установки у них должен быть разный)

теперь возвращаясь к нашим баранам

startkde - как раз и занимается формированием окружения (PATH, XDG_DATA_DIRS, XDG_CONFIG_DIRS, DESKTOP_SESSION) и далее запуском самих кед...

ну вот... проблема в том, что все переменные формируются внутри startkde - правильно, но вот при запуске кед, переменная PATH - возвращается к «стандартной»... (т.е. проверяем значение PATH уже при запущенных кедах)

правильность формирования всех переменных внутри startkde- проверено эхо-отладкой (надеюсь подробно описывать не надо очевидные вещи)

ну вот, спасибо...

/etc/profile.d/*.sh - начальная установка переменных окружения

А вот тут ты немного ошибаешься. Этот скрипт выполняется только при логине в систему в шелл. Ну и может быть при открытии терминала и запуске им шелла. Кстати, а может быть именно там-то он и переписывается?

Вот попробуй konsole запустить кстати, или ещё что-нибудь из PATH, наверняка откроется как раз от третьих кед. Решение — создай пустой ~/.profile и проверь Если всё действительно так, то скопируй туда /etc/profile но только убери задание PATH.

а то же... :о)

ну я вот тоже последнее время задумался об «нечто подобном», из-за разницы в поведении приложений запущенных из «терминала» и «*.desktop»... сделаю «заплыв», отпишусь :о)

спасибо

доп.

Решение — создай пустой ~/.profile и проверь Если всё действительно так, то скопируй туда /etc/profile но только убери задание PATH.

намного на понял - «решение» чего? :о) и ... копирование системного /etc/profile - в домашний профиль... это решение (каких либо задач) но только для одного конкретного «сам-себе режиссера», я бы сказал костыль, но это не решение для многопользовательского использования на большой куче машин :о) нужно именно такое решение :о)

и это... не понимаю... прописью/заточкой PATH в «профиле» - мы добиваемся только «постоянных неизменных» значений, пусть даже и тех, кот. нужны на данный момент... весь «цимус»- в том, что бы динамически менять «окружение», в зов-ти от загружаемого DE (вот в частности, при загрузке KDE3...)

т.е. понятно, что «нечто» можно добиться этим костылем, но задача решаться будет только в контексте «универсальности», и рихтовке startkde или еще чего из пакета KDE3 (т.е. взяли поставили KDE3, более ни чего не меняем, максимум «навести ревизию» в /etc/rc.d/rc.4 - и все должно работать без волшебных танцев, не мешая уже тому что есть на машине и ни чего не убивая) ... ну вот , как то так...

спасибо

### UPDATE ### - EUREKA-A-A...

добрый день

проблема оказалось в моей невнимательности (а чего мы ожжидали? :о)))

дело в том, что PATH имеет разные значения для шелл/ком.строки/konsole и для рабочего окружения KDE3 (т.е. то окружение, которое мы как раз и теребонькаем и подстраиваем под себя)

убедиться в этом можно запустив простой тест-эхо:

- из под ком. строки/шелл/консоли - баш скрипт

- кликом по *.desktop ярлыку, запускающему тот-же тестовый скрипт

...и ...получим разные результаты (разные, естественно, в том случае, если startkde до этого запустил свои шаловливые ручки в определние этих самых пересменных, в данном случае это PATH)

ну вот и все! всем удачи, надеюсь обществу пригодиться (мне же пригодилось :о)))

show_PATH.sh

#!/bin/sh
clear
echo "PATH = $PATH"; read

show PATH.desktop

[Desktop Entry]
Comment=
Comment[en_US]=
Exec[$e]='/home/sun/Desktop/show_PATH.sh'
GenericName=
GenericName[en_US]=
Icon=exec
MimeType=
Name=show PATH
Name[en_US]=show PATH
Path[$e]=
StartupNotify=true
Terminal=true
TerminalOptions=\s--noclose
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

- show_PATH.sh - start on bash/konsole shell  # PATH, значение стандартное
- show PATH.desktop - click on start          # PATH, значение модернизированное startkde/kde3

...и ...получим разные результаты (разные, естественно, в том случае, если startkde до этого запустил свои шаловливые ручки в

То есть, как я и говорил.

но только для одного конкретного «сам-себе режиссера», я бы сказал костыль, но это не решение для многопользовательского использования на большой куче машин :о) нужно именно такое решение :о)

Тогда просто отредактируй /etc/profile. Хотя просто убирать задание PATH нежелательно, лучше сделать его условным, с помощью какой-то проверки, задан он или нет. Это чтобы если ты залогинишься в чистой консоли, то PATH тоже не пустой был.

и это... не понимаю... прописью/заточкой PATH в «профиле» - мы добиваемся только «постоянных неизменных» значений

В шелле есть такая команда как if ... then ... fi.

Кроме того проверь файл ~/.bashrc если там есть команда запуска /etc/profile то убери её и перенеси из /etc/profile только тот код который тебе нужен.

Просто по идее Konsole может запускать не login shell, а обычный шелл, тогда /etc/profile не будет исполняться и не будет портить PATH и его можно не редактировать будет.

спасибо за помощь, но мы, как то по разному смотрим на «задачу»...что-ли... или не совсем понимаем др.др

задача решаться будет только в контексте «универсальности», и рихтовке startkde или еще чего из пакета KDE3 (т.е. взяли поставили KDE3, более ни чего не меняем, максимум «навести ревизию» в /etc/rc.d/rc.4 - и все должно работать без волшебных танцев, не мешая уже тому что есть на машине и ни чего не убивая)

как еще обьяснить? ну не знаю :о)))

берем стоковую слаку, НИ ЧЕГО с ней не делаем, ставим третьи кеды - и все работает :о)

НИ ЧЕГО НЕ ДЕЛАЕМ с исходным вариантом системы, ни /etc/profiles ни какие еще компоненты + ни чего не делается в окружении пользователя (те. же профили или еще какие пользовательские настройки)...

изначально не для себя кеды собираю и соотв. задача специфичная :о)

как то так, в двух словах... (без уточнения ВСЕХ. тонкостей), лучше будет - ПРИНЯТЬ КАК ЕСТЬ, ффсееее....:о)

спасибо

берем стоковую слаку, НИ ЧЕГО с ней не делаем, ставим третьи кеды - и все работает.

Кстати, а ведь в KDE4 в Konsole по умолчанию не login shell. А вот в KDE3 как раз login. Посмотри эту настройку в KDE3. Я так понимаю по условию пакеты KDE3 менять можно?

Кстати, а ведь в KDE4 в Konsole по умолчанию не login shell. А вот в KDE3 как раз login. Посмотри эту настройку в KDE3

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

Я так понимаю по условию пакеты KDE3 менять можно?

туплю, вопроса не понял :о) менять на что? на водку... или по условию менять? подробнее, в чем вопрос?

спасибо

буду благодарен за более подробное обьяснение

Интерактивный сеанс может загружаться в двух конфигурациях — login shell и обычный. Разница между ними в том, какие конфигурационные файлы запускаются, а какие нет. Подробнее прочитать можно в мануале по bash.

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

Один из файлов, которые запускаются в режиме login shell, но не запускаются в обычном — это как раз /etc/profile. Так как именно этот файл и портит заданный в startkde PATH, то тебе желательно чтобы новые вкладки в konsole открывались именно в обычном режиме, а не как login shell.

Правда так как вход происходит через kdm, а не через, например startx после того как залогинишься в чистой консоли, получается что настройки из /etc/profile вообще никогда не применяются, а это нежелательно, поэтому некоторые настройки, например PS1 (приглашение) должны быть перенесены в файл bashrc, который запускается в обычном режиме, но не все.

менять на что

Зайти в Konsole — настройки и снять галочку с «запускать как login shell» или убрать ключ -l в командной строке запуска шелла.

да не....

Так как именно этот файл и портит заданный в startkde PATH

да не... :о) он не портит, он просто, делает свое дело, и как мы заметили, делает это исправно! :о)

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

с шеллами и логинами, примерно так и где-то глубоко в голове зарыты воспоминания об былых набегах на маны :о) просто, особенно не приходлось «хардкорить» на эту тему... и «по умолчанию» обычно всех устраивало, втч и меня :о)

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

спасибо

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

Ну значит нужно найти где там в конфиг-файлах настройка Konsole 3.x и изменить это умолчание в самом же пакете.

упаси нас боже от революций...

конечно же нет :о)