XaeroX, у тебя файл с названием xdg-open ищется в текущей директории. Файла нет - access возвращает ошибку.
Надо сначала найти полный путь xdg-open в PATH и проверять уже его.
По поводу окуляра: я так понимаю, thambs сидит на KDE, а там Qt пытается быть чересчур умным, загружает всякие KDE плагины и запускает окуляр через них (что JACK/libQtCore.so.4 делает в крэш-логе окуляра?) Из-за несоответствия версий джековского и системного Qt происходит какой-то сбой. Тут уже когда-то писали о проблеме с файловым диалогом в KDE.
Загрузился сейчас в KDE - тут у меня вообще JACK не запускается.
code:
Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)"
Cannot mix incompatible Qt library (version 0x40806) with this library (version 0x40807)
FreeSlave писал: Надо сначала найти полный путь xdg-open в PATH и проверять уже его.
Фигасе. А попроще нельзя как-нибудь? Я избалованный виндой программист.
Цитата:
FreeSlave писал: Загрузился сейчас в KDE - тут у меня вообще JACK не запускается.
Обнови Qt в кедах до 4.8.7
Ты из-под стима запускаешь?
Добавлено 24-01-2017 в 20:26:
Цитата:
FreeSlave писал: Из-за несоответствия версий джековского и системного Qt происходит какой-то сбой.
Там в LD_LIBRARY_PATH при загрузке джека принудительно прописывается точка (текущая директория). Может, нужно ещё какие-то сошки из QT 4.8.7 приложить? Вопрос - какие?
XaeroX писал: Фигасе. А попроще нельзя как-нибудь? Я избалованный виндой программист.
Я не понимаю, чего попроще ты ожидаешь. access просто проверяет твои права на файл и, разумеется, не может догадаться, что ты хочешь проверить файл из PATH.
Но вот то, что findExecutable появилась лишь в Qt5 - это конечно провал.
Запускал и из-под стима и просто через Jack.sh. Чуть позже ещё поэкспериментирую.
thambs, если открываешь pdf через xdg-open (ибо именно в него по дефолту вырождается QDesktopServices::openUrl) тоже загружается окуляр?
XaeroX, насчет несовместимости qt либ нашёл решение. В Jack.sh добавить
code:
export QT_PLUGIN_PATH=""
или
code:
export QT_PLUGIN_PATH="$DirName"
Qt перестанет пытаться загружать системные плагины. Почему попытка загрузки несовместимого плагина приводит к остановке приложения - тоже, впрочем, большой вопрос к создателям Qt.
XaeroX
Почему system("xdg-open "+EXE_PATH+"VDKManual.pdf"), если EXE_PATH получить тем же readlink не прокатит? Или ты хочешь что бы один и тот же кусок кода работал универсально подо все системы?
FreeSlave писал: насчет несовместимости qt либ нашёл решение
Спасибо! Сделаю. thambs
Не понял вопрос. VDKManual.pdf открывается через Desktop Services, а xdg-open запускается через самописный Sys_Exec (там куча всякой мутотени с переменными окружения и LD_J_STEAM_PATH, чтобы запускать стимовские проги с правильным окружением).
XaeroX писал: xdg-open запускается через самописный Sys_Exec (там куча всякой мутотени с переменными окружения и LD_J_STEAM_PATH, чтобы запускать стимовские проги с правильным окружением).
Зачем запускать xdg-open в окружении стима? Это не только не имеет смысла, а более того даже вредно как раз таки из-за наследования окружения при форке процессов.
Впрочем, форкнутые из джека процессы и так наследуют окружение стима, если джек запущен из стима. Вопрос в том, что это за окружение. Я не знаю, на что влияет LD_J_STEAM_PATH. Но если стим выставляет ещё и LD_LIBRARY_PATH, то это в данном случае очень плохо. И хорошо бы его убирать при запуске системных утилит.
FreeSlave писал: форкнутые из джека процессы и так наследуют окружение стима, если джек запущен из стима
Нет, не наследуют. Посмотри внимательно sh-файл. Джеку передаётся свой LD_LIBRARY_PATH, а стимовский запоминается и передайтся в другом параметре, LD_J_STEAM_PATH. А джек уже скармливает его (с модификациями) своим форкам.
Цитата:
FreeSlave писал: Зачем запускать xdg-open в окружении стима?
Ну написана же уже функция, зачем паровоз изобретать.
| IP: 
24-01-2017 08:56
