The path reference when trying to open a file?
-
hey follas. I am confused when I tried to open a file normally I do with fopen:
fopen("path","r");
path would be "../" or "./" or whatever it should be. but the question is what is the reference to this "./"? the position of the .pro file or the debug/release file?
I tested and it turns out it should be the .pro file. But I still want to verify my thoughts.
-
Hi
./ means "this directory"
so inside Creator its the project folder.
If you run your exe from some place else it will be something else.../ mean the parent/one back directory from this one
For production code, its easy to use
qDebug() << "App path : " << qApp->applicationDirPath();
which means where .exe is.
-
Hi
./ means "this directory"
so inside Creator its the project folder.
If you run your exe from some place else it will be something else.../ mean the parent/one back directory from this one
For production code, its easy to use
qDebug() << "App path : " << qApp->applicationDirPath();
which means where .exe is.
-
@mrjj said:
will
hi, I know what ./ and ../ means. but I dont know if I wrote ./ in qt, what should be the reference of this "./" ? should this be the path of the executable file or the .pro file?
I dont know if I made myself clear enough.
@qtpi
hi
ok.
the value of "./" depends on how its activate and what the current folder is.Often it will be from the exe file and most OSes will make current folder the folder of the exe. Via creator it seems that current folder is where project is and not exe.
if you need to load files from exe
qApp->applicationDirPath();
or
http://doc.qt.io/qt-5/qstandardpaths.htmlshould be used instead of "./" and "../"
ps. and sorry if i still dont get what you are asking :)
-
@qtpi
hi
ok.
the value of "./" depends on how its activate and what the current folder is.Often it will be from the exe file and most OSes will make current folder the folder of the exe. Via creator it seems that current folder is where project is and not exe.
if you need to load files from exe
qApp->applicationDirPath();
or
http://doc.qt.io/qt-5/qstandardpaths.htmlshould be used instead of "./" and "../"
ps. and sorry if i still dont get what you are asking :)
-
It's worth to point out that your program should never rely on such relative paths, The working directory (
./) will change depending on how you start your app.If you start it from Qt Creator it will be (by default) the build directory (not .pro location nor executable location). If you go to Project pane and select the "run" page you can change working directory to whatever you want.
When you run the app by double-clicking the executable the working directory will be the location of the executable.
When you create a shortcut for it you can change the working directory in its properties to whatever you want.
When you run a program from a command line the working directory will be the directory you are currently in, which may have nothing to do with the executable location.
In summary - do as @mrjj said and use standard paths instead of relative ones.
-
It's worth to point out that your program should never rely on such relative paths, The working directory (
./) will change depending on how you start your app.If you start it from Qt Creator it will be (by default) the build directory (not .pro location nor executable location). If you go to Project pane and select the "run" page you can change working directory to whatever you want.
When you run the app by double-clicking the executable the working directory will be the location of the executable.
When you create a shortcut for it you can change the working directory in its properties to whatever you want.
When you run a program from a command line the working directory will be the directory you are currently in, which may have nothing to do with the executable location.
In summary - do as @mrjj said and use standard paths instead of relative ones.
@Chris-Kawa said:
If you start it from Qt Creator it will be (by default) the build directory (not .pro location nor executable location). If you go to Project pane and select the "run" page you can change working directory to whatever you want.
Thanks! That's very informative! The reason I prefer relative path is that if the software is copied on another machine I do not need to notice which directory I have to leave the software in.
But indeed absolute path is way safer.
-
@Chris-Kawa said:
If you start it from Qt Creator it will be (by default) the build directory (not .pro location nor executable location). If you go to Project pane and select the "run" page you can change working directory to whatever you want.
Thanks! That's very informative! The reason I prefer relative path is that if the software is copied on another machine I do not need to notice which directory I have to leave the software in.
But indeed absolute path is way safer.
The reason I prefer relative path is that if the software is copied on another machine I do not need to notice which directory I have to leave the software in.
But indeed absolute path is way safer.
It's not a matter of using or not using relative paths, it's a matter of their "relativity" - what are they relative to. If you write
../appthis depends on the current working directory which may change, but/home/myuser/test/../appis another matter - you have the../appfragment now relative to/home/myuser/testand this isn't changing. So ultimately you'd get the same behavior every time.The point is you should retrieve the application executable's path and then base your paths on that or use one of the standard locations (e.g.
QStandardPaths::AppDataLocation), just as @mrjj wrote. A starting point../just means nothing because the current working directory (the.dir) isn't rigidly defined (see Chris's explanation), it depends on how and who starts the application.Kind regards.
-
You can also override the working directory at runtime. For example to always use the location of the executable as the "base" you can call something like this somewhere at the start of your app:
QDir::setCurrent(qApp->applicationDirPath());It might have some caveats on some platforms though, see the docs.
