How to make use of latest QProcess::startDetached function with argument when starting external apps?
-
Hi coders,
when using QProcess::startDetached() on a RasPi using Qt5.15.2 in root mode, which i have to, because if wiringPi:
QProcess::startDetached("dbus-launch gnome-terminal -- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i"");
or
QProcess::startDetached("sudo chmod -R 777 "+dir_pizung_sensors.absolutePath());
i get the warning:
warning: ‘static bool QProcess::startDetached(const QString&)’ is deprecated: Use
QProcess::startDetached(const QString &program, const QStringList &arguments) instead [-Wdeprecated-declarations]Problem:
When using the latest function, like beneath, the external apps won't start silenty with no error at all:QProcess::startDetached("dbus-launch gnome-terminal";{"-- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i""});
or
QProcess::startDetached("sudo chmod";{"-R 777 "+dir_pizung_sensors.absolutePath()"});
don't work.
I use the workaround:
#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" qWarning() << "Using deprecated-declaration QProcess::startDetached(), because no other way!"; QProcess::startDetached("dbus-launch gnome-terminal -- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i""); #pragma GCC diagnostic pop
I know that:
QProcess::startDetached(const QString &program, const QStringList &arguments)
works for apps with easier argument with no problem on my RasPi4 under Qt.Can someone please give me a hint ?
/Ralf
-
Hi coders,
when using QProcess::startDetached() on a RasPi using Qt5.15.2 in root mode, which i have to, because if wiringPi:
QProcess::startDetached("dbus-launch gnome-terminal -- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i"");
or
QProcess::startDetached("sudo chmod -R 777 "+dir_pizung_sensors.absolutePath());
i get the warning:
warning: ‘static bool QProcess::startDetached(const QString&)’ is deprecated: Use
QProcess::startDetached(const QString &program, const QStringList &arguments) instead [-Wdeprecated-declarations]Problem:
When using the latest function, like beneath, the external apps won't start silenty with no error at all:QProcess::startDetached("dbus-launch gnome-terminal";{"-- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i""});
or
QProcess::startDetached("sudo chmod";{"-R 777 "+dir_pizung_sensors.absolutePath()"});
don't work.
I use the workaround:
#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" qWarning() << "Using deprecated-declaration QProcess::startDetached(), because no other way!"; QProcess::startDetached("dbus-launch gnome-terminal -- bash -c "sleep 2s;cat "+LogFile+"; exec bash -i""); #pragma GCC diagnostic pop
I know that:
QProcess::startDetached(const QString &program, const QStringList &arguments)
works for apps with easier argument with no problem on my RasPi4 under Qt.Can someone please give me a hint ?
/Ralf
@SalemSabrehagen said in How to make use of latest QProcess::startDetached function with argument when starting external apps?:
When using the latest function, like beneath, the external apps won't start silenty with no error at all:
Ignoring the fact that your code is syntactically incorrect (
...";{"...
) and will not compile (so don't know what you really have)....But both your attempts are incorrect. (To get errors you must connect to
errorOccurred
signal.) The first argument tostartDetached()
(orstart()
) is a command. And the second argument is a list of parameters, each parameter must be a separate element.QProcess::startDetached("sudo", { "chmod", "-R", "777", dir_pizung_sensors.absolutePath() } ); QProcess::startDetached("dbus-launch", { "gnome-terminal", "--", "bash", "-c", "sleep 2s;cat "+LogFile+"; exec bash -i" } );
-
@SalemSabrehagen said in How to make use of latest QProcess::startDetached function with argument when starting external apps?:
When using the latest function, like beneath, the external apps won't start silenty with no error at all:
Ignoring the fact that your code is syntactically incorrect (
...";{"...
) and will not compile (so don't know what you really have)....But both your attempts are incorrect. (To get errors you must connect to
errorOccurred
signal.) The first argument tostartDetached()
(orstart()
) is a command. And the second argument is a list of parameters, each parameter must be a separate element.QProcess::startDetached("sudo", { "chmod", "-R", "777", dir_pizung_sensors.absolutePath() } ); QProcess::startDetached("dbus-launch", { "gnome-terminal", "--", "bash", "-c", "sleep 2s;cat "+LogFile+"; exec bash -i" } );
Hi @JonB,
sorry for my bad typing (...";{"...); my code on the Pi was correct.Your suggestion works !
Typing the new command makes it more complicated the ever, but there must be a reason for change.
Thanks,
/Ralf -
Hi @JonB,
sorry for my bad typing (...";{"...); my code on the Pi was correct.Your suggestion works !
Typing the new command makes it more complicated the ever, but there must be a reason for change.
Thanks,
/Ralf@SalemSabrehagen
The old waystartDetached()
(andstart()
) really did two things: they had to parse-split the command-line string command before getting OS to execute with separate arguments. Now they separated the parsing out into its own method, QStringList QProcess::splitCommand(QStringView command), so you could call that on a command-line string and it should (hopefully!) deliver the same separate arguments as you now need to passstart...()
. But it is cleaner this way. -
Hi @JonB,
sorry for my bad typing (...";{"...); my code on the Pi was correct.Your suggestion works !
Typing the new command makes it more complicated the ever, but there must be a reason for change.
Thanks,
/Ralf@SalemSabrehagen said in How to make use of latest QProcess::startDetached function with argument when starting external apps?:
but there must be a reason for change.
I can only guess. But, I would say the new way is much better. Having all arguments as separate entries in a list does away with having to quote some arguments and escaping quotes where necessary. Sure, this only applies to arguments which have spaces inside them (which is rarely the case), but in general it is much better. In your case with calling
bash
with arguments it is certainly a much better way. There are countless posts on this forum (both Windows- and Linux-related) where people got this wrong (using the old way).