LINUX.ORG.RU

QProcess, непонятное поведение дочернего процесса.

 


0

2

Пишу krunner-плагин для быстрого запуска freerdp-подключений. Столкнулся со странным. При:

QStringList arguments;
...
//формируем arguments
...
QProcess * m_Process=new QProcess(this);
m_Process->execute("xfreerdp", arguments);
xfreerdp падает с
transport_connect: getaddrinfo (Имя или служба не известны)
Кладем в /usr/local/bin/catch следующее:
#!/bin/sh
echo $@ > /tmp/opts
xfreerdp $@
И, соответственно, делаем
m_Process->execute("catch", arguments);

Все работает. Как обойтись без bash-обертки? Замена имени хоста на ip ничего не меняет. startDetached приводит к ошибке разбора параметров, хотя если опять же пропустить их через обертку, то работает, так же как и

$xfreerdp `cat /tmp/opts`

Содержимое arguments тоже роли не играет. У кого-нибудь есть идеи? :)


Может быть есть возможность выложить небольшую функцию, которую можно было бы поковырять на предмет неверного запуска?

trex6 ★★★★★
()

Нашел причину. Оказывается

arguments << "--plugin" << "cliprdr";
и
arguments.append("--plugin cliprdr");
для xfreerdp две большие разницы. Правильный вариант - первый. Я, правда, так и не понял, почему. В случае запуска через bash-обертку эта разница нивелируется.

Код выложу весь когда отлажу и будет не стыдно показать. Сейчас реализована работа с настройками хостов посредством KConfig/KConfigGroup, явки-пароли в KWallet, запуск xfreerdp с набором параметров и фильтрация настроенных хостов в krunner. Из серьезных замыслов осталось взаимодействие с процессом xfreerdp по stdin\stdout для передачи явок (сейчас передаются в параметрах), подтверждения сертификата и т.п.

ZigBee
() автор топика
Ответ на: комментарий от quiet_readonly

Можете подсказать по поводу сравнение переменных окружения? Я первый раз пишу что-то под linux на c++. Использую kdevelop.

ZigBee
() автор топика
Ответ на: комментарий от ZigBee

Правильный вариант - первый. Я, правда, так и не понял, почему.

Потому что когда образ нового процесса запускается через execve, в неправильном варианте --plugin и cliprdr передаются как один элемент массива argv[], а в правильном - в отдельных

Harald ★★★★★
()
Ответ на: комментарий от ZigBee

для xfreerdp две большие разницы

в данном случае второй вариант неправильный, это один аргумент "--plugin cliprdr", а не два.

alex_custov ★★★★★
()
Ответ на: комментарий от ZigBee

для xfreerdp две большие разницы

Для любого приложения. Мне казалось очевидным почему аргументы QStrinList, а не строка...

erfea ★★★★★
()
Ответ на: комментарий от alex_custov

Именно потому что "--plugin cliprdr" или "-g 800x600" - это один аргумент я и пытался сначала добавлять его как одну строку в QStringList.

А в xfreerdp 1.1.x синтаксис поменяли. Теперь, например, для геометрии окна будет так: /size:800x600. Соответственно, надо либо

arguments.append("/size:800x600")
либо
arguments << "/size:800x600";
а
arguments << "/size:" << "800x600";
не работает.

Кстати, кто-нибудь знает, как получить всё, что дочерний процесс гадит в STDOUT, не дожидаясь его кончины? Сигналы readyReadStandartOutput/Error прилетают только после убиения процесса.

ZigBee
() автор топика
Ответ на: комментарий от alex_custov

Пробовал в первую очередь. Сигнал прилетает после «отпускания» waitForFinished(). То есть уже поздно.

ZigBee
() автор топика
Ответ на: комментарий от MikeDM

Офф документация написана для сферических процессов в вакууме. Читать её я начал еще до того, как приступил кодить, дабы точно представлять себе то, что хочу получить.

Как выяснилось, проблема с сигналом readyReadStandartOutput() проявляется только в случае, когда xfreerdp спрашивает в STDOUT подтверждения принять плохой сертификат. Запросы же логина и пароля обрабатываются вовремя. Надо посмотреть код xfreerdp, видимо после запроса подтверждения сертификата не выполняется fflush(stdout);

ZigBee
() автор топика
Ответ на: комментарий от ZigBee

Именно потому что "--plugin cliprdr" или "-g 800x600" - это один аргумент

В argv это 2 аргумента

annulen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.