Linux File I/O
When I write a program using file i/o (using fstream) on windows, if I do something like std::ifstream in("file.txt"); it will open "file.txt" in the same directory as the executable.
However when I compile the same code in *nix (I''m running SuSE, not that it matters too much) instead of looking in the same directory as the executable it looks in "/home/yoshi/file.txt"
I know how to find the absolute path of the file using various methods however I would like to know if there is a way to get it to just open the file in the same directory without having to find the path to the file first.
-YoshiXGXCX ''99
I didn''t tried it:
std::ifstream in("\\.file.txt");
std::ifstream in("\\.file.txt");
To be considered a genius you just have to say what everybody knows in a way very few understand
std::ifstream in("\\.file.txt") will not work, i guess you mean "./file.txt"?
the "./" means that it should create the file in the current directory. But this is the default - from which working directory are you running your application? are you running it from an IDE or the shell?
Chris
the "./" means that it should create the file in the current directory. But this is the default - from which working directory are you running your application? are you running it from an IDE or the shell?
Chris
Depending on how you are running the program it very possibly is being told /home/USERNAME/ is the current directory.
If what you want is a file in the same directory as the binary you should check arg[0] for the path.
EDIT:
I almost forgot.. If you are opening a file for writing or a user specific file of some type (basically anything the user should be able to edit) then as a general rule of thumb somewhere in /home/USER is the right place to look. It is almost always very bad to do anything requiring the user to have root privledges
[edited by - drakonite on October 19, 2003 2:02:13 PM]
If what you want is a file in the same directory as the binary you should check arg[0] for the path.
EDIT:
I almost forgot.. If you are opening a file for writing or a user specific file of some type (basically anything the user should be able to edit) then as a general rule of thumb somewhere in /home/USER is the right place to look. It is almost always very bad to do anything requiring the user to have root privledges
[edited by - drakonite on October 19, 2003 2:02:13 PM]
Shoot Pixels Not People
If I run it from the IDE (KDE 3.1) it doesn''t work, but if I run it from the commandline and the current working directory is the same directory that the file is in it works fine.
However this is not the ideal situation. I would like it to read the file from the same directory as the executable always.
The file is just a list of vertices that I am rendering (I''m using SDL) so I do not want the user editing it.
Any solutions?
However this is not the ideal situation. I would like it to read the file from the same directory as the executable always.
The file is just a list of vertices that I am rendering (I''m using SDL) so I do not want the user editing it.
Any solutions?
-YoshiXGXCX ''99
*sigh*
forget the window-ism that data and executable are in the same directory and figure out how UNIX does it.
forget the window-ism that data and executable are in the same directory and figure out how UNIX does it.
Alright, problem solved. I had an old method for fixing this however it didn''t always work when the program was run from the commandline. I''ve figured out why and I have fixed it.
And C-Junkie, I really don''t need your holier-than-thou attitude. I have my reasons for keeping the file in the same directory, and if you don''t like it I can tell you where to cram it.
And C-Junkie, I really don''t need your holier-than-thou attitude. I have my reasons for keeping the file in the same directory, and if you don''t like it I can tell you where to cram it.
-YoshiXGXCX ''99
Sorry, I just have to deal with a bunch of 1337 people all day saying things like "windoze is teh suck" and I get sick of it.
Anyway, the program is being compiled on windows and linux (and eventually mac os) and so it''s mostly a portability issue.
Anyway, the program is being compiled on windows and linux (and eventually mac os) and so it''s mostly a portability issue.
-YoshiXGXCX ''99
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement