QProcess does not finish under windows 10 "bash on ubuntu on windows" - c++

I have a simple Qt programm which start's another program with QProcess::execute().
It works under Windows (MSVC 32/64, Mingw-32), Linux (GCC), MAC (CLang).
But if I try to run it in a bash under Windows (Bash on ubuntu on windows) the call to QProcess::execute() never returns.
I've also tried to use QProcess::start() but neither the QProcess::started nor the QProcess::errorOccured signal is issued, and QProcess::start() also never returns.
Is there some incompatibilty with this configuration?
The programm was compiled with GCC 4.8.4 and Qt 5.7 for Linux
The programm looks like this:
#include <QProcess>
#include <QCoreApplication>
int main(int argc, char **argv)
{
QCoreApplication app(argc, argv)
QStringList args = app.arguments().mid(1);
int retcode = QProcess::execute("programm", args);
if (retcode == 0)
{
// do something here
}
return retcode;
}
"programm" is an executable located some where in the search path.

Related

Writing commands on linux terminal using Qt

I'm trying to get Qt creator to print a user input by using a push button on an UI into the terminal. As of now, the code is executable on the terminal via human input. Here is the code:
void MainWindow::on_pushButton_clicked()
{
QProcess::execute("/catkin_ws/devel/lib/submodbus");
system("cd catkin_ws/devel/lib/submodbus");
system("./submodbus_node");
}
Current output when using the code
Output via human input
The versions i'm running on are:
-Ubuntu 16.04
-QT Creator 3.5.1
system can't change the current directory globally. but could use like this:
system("cd /catkin_ws/devel/lib/submodbus && ./submodbus_node");
or using QProcess::setProgram with QProcess::setWorkingDirectory
QProcess p;
p.setProgram("submodbus_node");
//p.setArguments(QStringList()<<args); // if you need
p.setWorkingDirectory("/catkin_ws/devel/lib/submodbus");
p.start();
or QDir::setCurrent
QDir::setCurrent("/catkin_ws/devel/lib/submodbus");
QProcess::startDetached("submodbus_node");
Test demo, create three files in the parent directory:
#include <QApplication>
#include <QProcess>
#include <QDir>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
system("cd ../ && touch test1.txt");
QProcess p;
p.setProgram("touch");
p.setArguments(QStringList()<<"test2.txt");
p.setWorkingDirectory("../");
p.start();
QDir::setCurrent("../");
QProcess::startDetached("touch test3.txt");
return a.exec();
}

Non-expected result of QDir::homePath() for a program run by startproc

I have the following small program:
#include <unistd.h>
#include <pwd.h>
#include <QCoreApplication>
#include <QDir>
const char * homeDir()
{
return getpwuid(geteuid())->pw_dir;
}
int main(int argc, char *argv[])
{
printf("Qt homedir: %s\n", qPrintable(QDir::homePath()));
printf("Native homedir: %s\n", homeDir());
QCoreApplication a(argc, argv);
return a.exec();
}
Now:
when run directly by a "normal" user, ./program, the output is:
Qt homedir: /home/user
Native homedir: /home/usr
which is ok
when run directly by root, ./program, the output is:
Qt homedir: /root
Native homedir: /root
which is ok
when run by root as a different user by the means of sudo, e.g. sudo -u user ./program, the output is:
Qt homedir: /home/user
Native homedir: /home/user
which is ok
when run by root as a different user by the means of startproc, e.g. startproc -u user /full/path/to/program, the output is:
Qt homedir: /root
Native homedir: /home/user
which is NOT ok, or not expected (at least for me)
And my question is: why does the last run give a different result than the others? Is it a bug in Qt (doesn't take into account the fact, that the effective user is different than the real user, or something different), or am I missing some background info (e.g. the mechanism of how startproc works)?
The version of Qt in question is 5.6.1.
Qt's QFileSystemEngine uses the contents of the HOME environment variable on Unix - see its implementation. Yet startproc -u does not set HOME: that's why it fails.
The getpwuid call can be potentially very expensive and can block, i.e. by getting information from an LDAP or AD server, etc., and it's best if you take care of it yourself. Furthermore, it's not thread-safe, and you should use getpwuid_r instead.
An implementation might look as follows:
static QString getHomeDir() {
auto const N = sysconf(_SC_GETPW_R_SIZE_MAX);
auto *buffer = std::make_unique<char[]>(N);
passwd pwd;
passwd *result;
getpwuid_r(geteuid(), &pwd, buffer.get(), N, &result);
if (result) {
auto *dir = result->pw_dir;
auto const decoded = QFile::decodeName(dir);
return QDir::cleanPath(decoded);
}
return {};
}
enum class HomeDir { Default, Init };
QString homeDir(HomeDir option = HomeDir::Default) {
// needs a C++11 compiler for thread-safe initialization
static QFuture<QString> home = QtConcurrent::run(getHomeDir);
return (option == HomeDir::Init) ? QString() : home;
};
int main(int argc, char **argv) {
QCoreApplication app(argc, argv);
homeDir(HomeDir::Init);
// do other time-consuming initializations here
QString () << homeDir();
}

QProcess does not start

For some reason, I am unable to start a process using QProcess on Ubuntu, and I do not understand why...
int main(int argc, char *argv[])
{
//Run the process:
QString procName = "./path/to/executable/Individual";
QProcess *proc = new QProcess();
proc->start(procName);
if(!proc->waitForStarted())
{
std::cout<<"Fail!"<<std::endl;
getchar();
return 0;
}
int exitCode = proc->exitCode();
std::cout<<"Exit code: "<<exitCode<<std::endl;
getchar();
return 0;
}
This always prints 'Fail' to the terminal.
If I type ./path/to/executable/Individual into the terminal, it works just fine, so the path seems to be correct.
Can anyone tell me why the program will not start?
I am using Qt version 5.9.1 on Ubuntu.
Since you're using Linux, you can
sudo ln -s /path/to/executable/Individual /usr/local/bin/individual
then try:
proc->start("individual");
You can try with:
proc->start("cd /usr/local/bin/ && individual");

Executing bash script from C++ and read its output ubuntu sdk

I have a ubuntu application and I'm trying to execute bash scripts from it but it doesn't seem to be working. I tried doing this with system()
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
// tried both
system("./script.sh");
// system ("script.sh")
}
Also, i've tried researching this but did not find a solution; is it possible to also read the output and display in textbox.
Use popen().
FILE *script;
char line[LINESIZE];
script = popen("./script.sh", "r");
while (fgets(line, sizeof(line), script)) {
...
}
pclose(script);
It's not relevant that you're running a script. This will work with any shell command.
For anyone looking to do this in QT, here's what i did:
QProcess proc;
proc.start("gnome-terminal", QIODevice::ReadWrite);
if (proc.waitForStarted() == false) {
qDebug() << "Error starting terminal process";
qDebug() << proc.errorString();
return (-1);
}

How to force QLocale::system to change

I need to test my application translation to non-English language very often, and this is very uncomfortable to change the whole operating system language just to do this simple check.
How can i change Qt-detected system language using environment variables for example?
or with command-line parameter.
I try to change LANG, LANGUAGE environment variables, but it has no effect.
However, under GNOME it has!
UPD: code i'm using such code to determine the system locale and load appropriate translation:
QTranslator app_translator;
if (!app_translator.load ("app_" + QLocale::system ().name (), app_tr_dir))
qWarning ("Can't load app translator file for locale %s from %s", qPrintable (QLocale::system ().name ()), app_tr_dir.toLocal8Bit().data());
else
app.installTranslator (&app_translator);
P.S. My OS is Kubuntu 13.10, Qt version is 4.8.
You can always change the locale by QLocale::setDefault() method. here's an example from one project:
void Language::setCurrentLanguage(Language::Languages language)
{
if (language == Language::Arabic) {
QLocale l(QLocale::Arabic, QLocale::SaudiArabia);
QLocale::setDefault(l);
dynamic_cast<MangoApp*>(qApp)->setLayoutDirection(Qt::RightToLeft);
dynamic_cast<MangoApp*>(qApp)->removeAllTranslator();
dynamic_cast<MangoApp*>(qApp)->loadQtTranslator();
dynamic_cast<MangoApp*>(qApp)->loadMangoTranslator();
} else {
QLocale l(QLocale::English, QLocale::UnitedStates);
QLocale::setDefault(l);
dynamic_cast<MangoApp*>(qApp)->setLayoutDirection(Qt::LeftToRight);
dynamic_cast<MangoApp*>(qApp)->removeAllTranslator();
}
}
For testing you can use something like that (just correct main function):
int main(int argc, char **argv) {
QApplication app(argc, argv);
QLocale localeUsedToDeterminateTranslators = QLocale::system();
Q_FOREACH(QString a, app.arguments()) {
const static localeParam = "-locale:";
if (a.startsWith(localeParam)) {
localeUsedToDeterminateTranslators = QLocale(a.mid(sizeof(localeParam)-1));
break;
}
}
... // your normal code
Then when you run you app you can just run it with extra parameter: ./yourAppName -locale:nl. See documentation of QLocale for possible values.
Edit: I've found even better approach, there is a method QLocale::setDefault, so this should work even better:
int main(int argc, char **argv) {
QApplication app(argc, argv);
Q_FOREACH(QString a, app.arguments()) {
const static localeParam = "-locale:";
if (a.startsWith(localeParam)) {
QLocale::setDefault(QLocale(a.mid(sizeof(localeParam)-1)));
break;
}
}
...
QTranslator app_translator;
if (!app_translator.load ("app_" + QLocale().name (), app_tr_dir))
qWarning ("Can't load app translator file for locale %s from %s", qPrintable (QLocale().name()), app_tr_dir.toLocal8Bit().data());
else
app.installTranslator (&app_translator);
Using the LANGUAGE (not LANG) environment variable should definitely change the value returned by QLocale::system().name(), because this environment variable has precedence over all other ways to define the application message locale (details).
I tested it this with Qt 5.12 under Lubuntu 19.10 (means, using the LXQt desktop), and it works. The command was:
LANGUAGE=de ./application
If this really does not work under Kubuntu, it should be reported as a bug, because then Kubuntu is interfering with the way how an application is told its locale.