how to set current working directory so that QFile gets relative paths right

[Joachim W]

@mranger90, you are certainly correct about qApp->applicationDirPath().

I meant to ask what to do instead. I definitely need to get command line arguments interpreted in the standard way.

[mranger90]

If you need to know where you are calling the executable from then you might try:

qDir::absolutePath()

instead of

QApplication::applicationDirPath()

[VRonin]

QDir::setCurrent(qApp->applicationDirPath()); requires you to call A/app ../B/data as the argument is a path relative to A/app

if you want the path to be ralative to the current directory (A/app B/data) just don't change it and delete QDir::setCurrent(qApp->applicationDirPath());

[Pablo J. Rogina]

@Joachim-W I guess you don't need to use QDir:setCurrent at all, since per documentation:

The current directory is the last directory set with QDir::setCurrent() or, if that was never called, the directory at which this application was started at by the parent process

so in your example

 A/app B/data

your current directory is just the directory at which this application was started by the parent process i.e. /home and using just QFile file(name) (without calling setCurrent() previously) should get the desired file

[JonB]

@Joachim-W said in how to set current working directory so that QFile gets relative paths right:

How to set the current working directory (CWD) to where the application was started from

As others have said, the current working directory is where the application was started from!

[Joachim W]

sorry, @VRonin, @Pablo-J-Rogina, @JonB: your advice to simply delete the instruction

QDir::setCurrent(qApp->applicationDirPath());

may be consistent with docs, and it is certainly consistent with what I originally had expected from Qt ... but empirically it does not work. If I delete said instruction, then relative paths are interpreted relative to my home directory. Which may coincide with neither the directory where the app resides in, nor the directory where it was started from.

Last hope for a simple answer: maybe my app is misconfigured by some insane CMake instruction? Are there environment variables that would overwrite the default interpretation of relative paths?

[JonB]

@Joachim-W
Well it doesn't for me....
How are you starting/running your application? For example, are you invoking it from a desktop icon?
Print out what the current directory is on application start-up?

[Joachim W]

@JonB: I'm starting the application from the Linux command line.

[JonB]

@Joachim-W
And, presumably, you're saying that "command line" is in a terminal, with a non-home current directory?
What does QDir::current() or QDir::currentPath() return?

[Pablo J. Rogina]

@Joachim-W with due respect, this is working for me (consistently with documentation) (Lubuntu, Qt 5.9, console application):

#include <QCoreApplication>
#include <QDebug>
#include <QDir>
#include <QFile>

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    qDebug() << QDir::currentPath();
    QString name = argv[1];
    QFile file(name);
    qDebug() << file.open(QIODevice::ReadOnly | QIODevice::Text);

    return a.exec();
}

with the following output:

pablo@lubuntu64:/home$ A/app B/data.txt 
"/home"
true

just in case, the contents of corresponding folders A and B

pablo@lubuntu64:/home$ ls A
app
pablo@lubuntu64:/home$ ls B
data.txt

[Joachim W]

thanks to @JonB's questions, I located the problem: the current directory changes while my application is running, namely when the singleton instance of Mainwin is created.

[Joachim W]

deep in the code, in an inappropriate location and for unkown reasons, there was a statement

QDir::setCurrent(QDir::homePath());

which obviously caused the described behavior, confused me for days, and made me unjustly suspect Qt of doing insane things.

Thanks to you all for helping me in interpreting the Qt docs and in locating the bogous instruction.

[Joachim W]

The ultimate cause of my problem is a conflict between command-line interface and GUI:

For a file dialog in a GUI, it is perfectly reasonable to start from the user's home directory, whereas for a command-line interface it is insane to overwrite the current working directory.

[VRonin]

@Joachim-W said in how to set current working directory so that QFile gets relative paths right:

For a file dialog in a GUI, it is perfectly reasonable to start from the user's home directory, whereas for a command-line interface it is insane to overwrite the current working directory.

QFileDialog has setDirectory there is no need to mess up the working directory

[JonB]

@Joachim-W said in how to set current working directory so that QFile gets relative paths right:

thanks to @JonB's questions, I located the problem: the current directory changes while my application is running, namely when the singleton instance of Mainwin is created.

Yep, that's the only thing which makes sense!

I meant to ask what to do instead. I definitely need to get command line arguments interpreted in the standard way.

Now, doubtless you already realise this, but if you are dealing with relative paths received from the command line, you'd better deal with them (even if it's only to make them absolute) before you hit that code which changes the working directory (unless they really intentionally relative to the home directory in your app for some reason).

whereas for a command-line interface it is insane to overwrite the current working directory.

I see no reason why a file dialog for read/write should not be relative to the current directory, rather than say the home directory, but of course depends on context.

Finally, as @VRonin says, you can (and should) use QFileDialog::setDirectory() rather than actually changing directory if you only want that for the purpose of the file dialog.