Always returns 0

Pothos

I'm trying this simple program for learning and protoing purposes.

In this example result is always 0 regardless of what I type into the input field. What am I doing wrong here?

JonB

@Pothos
You are mixing two possibilities for running your command.

If you want to use wattForStarted/Finished() you must run your command via start().

Here for simplicity you could use QProcess::execute(), in which case its return result is the exit code you are looking for.

Please go look at the doc page for QProcess::execute() and read what it says. That is where your problem is.

SGaist

Hi and welcome to devnet,

What is mountpoint ?
Does it return any error code ?

JonB

@Pothos
Please paste code I can copy, not a picture.

QProcess::execute() is static. You're not getting the exit code you think you are into your code.

BTW, conceptually you don't want a QProcess::waitForStarted()before you have given it a process to start.

@SGaist
It's https://www.man7.org/linux/man-pages/man1/mountpoint.1.html. Its exit code should vary according to what path is passed to it, that's what the OP is getting at.

JoeCFD

testProcess->readAllStandardOutput() to match the output of command line run

SGaist

@JonB Good catch !

I was checking for mountpoint because of the unusual path it's located in. It might be a typo from @Pothos though.

Pothos

@JonB
Here is the code copied:

void MainWindow::on_testButton_clicked()
{
    QString path = ui->testPlainTextEdit->toPlainText();
    QProcess *testProcess = new QProcess(this);

    testProcess->waitForStarted();

    testProcess->execute("/usr/bin/mountpoint", {"-q", path});
    testProcess->waitForFinished();
    int result = testProcess->exitCode();

    qDebug()<< result;
    if (result == 0) {
        ui->testLabel->setText("Mounted.");
    } else {
        ui->testLabel->setText("Not mounted.");
    }

    ui->testPlainTextEdit->clear();
    ui->testPlainTextEdit->setFocus();

    // Close process and delete pointer variable
    testProcess->close();
    delete testProcess;
}

@JoeCFD how to use?

@SGaist yes it was a typo. Still doesn't work though.

JonB

@Pothos
You are mixing two possibilities for running your command.

If you want to use wattForStarted/Finished() you must run your command via start().

Here for simplicity you could use QProcess::execute(), in which case its return result is the exit code you are looking for.

Please go look at the doc page for QProcess::execute() and read what it says. That is where your problem is.

JoeCFD

QByteArray QProcess::readAllStandardOutput(). You convert QByteArray to what you expect.

Pothos

@JonB
Okay so QProcess::execute() is a static method. I managed to get my program work simply with int result = QProcess::execute("/usr/bin/mountpoint", {"-q", path}). Thank you for the help.

I'm still wondering: Can one say that either execute() or start() is better in this particular case or is it just a matter of preference?

Kent-Dorfman

Do you want concurrency or do you want to block until the process is completed?

JonB

@Pothos
execute() "worked" here because it was the quickest way to show you the return result you thought was wrong.

Because this command is so quick to execute you "get away" without noticing that the UI is blocked while that slot runs.

That is what @Kent-Dorfman is drawing to your attention.

If you really want to it right: use start(), but do not use those waitFor...() methods. Use the QProcess signals like finished() to get the result back. Then do whatever you want to do with the result in your slot for finished(). Connect the other signals too, like errorOccurred. If you do all this you'll understand a lot about how Qt programming with signals & slots works!

Pothos

@Kent-Dorfman in this particular case I think blocking the event loop is acceptable because, as JonB said, the command was so quick to execute, which means the user won't notice any freeze-up.

@JonB I'm going to try the start()-version next as I will be trying to run an rsync-command next using this Qt-app.

JonB

@Pothos said in Always returns 0:

@JonB I'm going to try the start()-version next as I will be trying to run an rsync-command next using this Qt-app.

Yes, that will be an example of a "long-running" command. You will presumably not want your UI to be frozen/blocked while it executes, which it would be if you were to use execute(). You will indeed want to use start(), and the various signals, so that it runs asynchronously.