Jump to content
  • Advertisement
Sign in to follow this  
Servant of the Lord

'.' in filepaths

This topic is 2062 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In Windows/Linux/Macintosh operating systems, in filepaths, does a filepath with a single period indicate that it's relative to the location of the executable, or relative to the current working directory of the environment?

 

For example, if I do: (ignoring the lack of drive letters  on non-Windows system)

C:/> CD C:/path/to/folder/

C:/path/to/folder/> ../../different/folder/program.exe

 

Inside of 'program.exe', if I tried to access: ./file.txt, would it find:

C:/path/to/folder/file.txt  (Relative to environment working directory)

Or

C:/path/different/folder/file.txt  (Relative to executable directory) 

Share this post


Link to post
Share on other sites
Advertisement

It's always the current working directory, I believe. It's usually the same as the executable's location, especially under Windows where most programs are started from a shortcut which automatically sets the CWD to the executable's location. When you're starting program.exe from a different folder, you're really starting different/folder/program.exe, it should then be clear the executable's absolute location is somewhat irrelevant.

 

You could always whip up a quick program to find out, though!

Edited by Bacterius

Share this post


Link to post
Share on other sites
Yeah, try it out.

You can set the working directory in Visual Studio when you run it using F5, it's in the debug panel (probably), I think it defaults to the exe location. Edited by Michael Tanczos

Share this post


Link to post
Share on other sites

Windows:

Anything that does not explicitly specify a drive is relative to the working directory, so the period has no real meaning on Windows.  The working directory is often the same as the executable directory but could be different if the executable changes it at run-time, it is run under Visual Studio, or run from a .bat file located elsewhere (the working directory will be that of the .bat file).

If you run it from the command line as in your example, the working directory would be “C:/path/to/folder/”.

 

Macintosh:

Absolute paths begin with / and everything else is relative, though there are special cases such as “~/”.

 

Linux:

I don’t know.

 

 

L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

Mac OS X is Unix based, thus it inherits most of its features, including the paths.

In Unix- based OS, such as Linux, 

. = current directory

.. = parent directory

And what L. Spiro described for Mac, also applies to Linux.

Anything starting with / is considered an absolute directory path from the root (which is just /)

Anything else is considered relative paths (so folder/file ./folder/file and ../myfolder/folder/file are all relative paths). ~ is just a symbol that is automatically expanded to the user's home directory (which is set by the environment var $HOME for each user)

Share this post


Link to post
Share on other sites

It's always the current working directory, I believe.

So you are saying, under Windows, the single dot always indicates the current working directory and not the executable directory, unless they happen to be the same (which is most of the time)?
 
Is it the same on Mac and Linux?

You could always whip up a quick program to find out, though!

I don't currently have access to a Mac and I don't have Linux installed, so I can't currently try it out.
 

Windows:
Anything that does not explicitly specify a drive is relative to the working directory, so the period has no real meaning on Windows.  The working directory is often the same as the executable directory but could be different if the executable changes it at run-time, it is run under Visual Studio, or run from a .bat file located elsewhere (the working directory will be that of the .bat file).

Thank you, that helps.
 
And in the situation of running from a command-line prompt like this:

C:/> CD C:/path/to/folder/
C:/path/to/folder/> ../../different/folder/program.exe

 
'program.exe' will have the current working directory of 'C:/path/to/folder/ ', and not 'C:/path/different/folder/?
 

Mac OS X is Unix based, thus it inherits most of its features, including the paths.
In Unix- based OS, such as Linux, 
. = current directory
.. = parent directory

So is the 'current directory' the "directory of the executable", or "the current working directory of the environment"?
 

Anything else [speaking of Unix-like systems] is considered relative paths (so folder/file  and  ./folder/file   and  ../myfolder/folder/file are all relative paths).

Thanks, I was wondering about that. So folder/file and ./folder/file would be the same directory?



[Edit:] Fixed broken quotes a day later. Edited by Servant of the Lord

Share this post


Link to post
Share on other sites
Thanks, I was wondering about that. So folder/file and ./folder/file would be the same directory?
Yes. The period is probably just for clarity for us humans, or it might have significant meaning in some DOS commands (just a guess), but with or without it is the same to the file system.


L. Spiro

Share this post


Link to post
Share on other sites

Your quotes seemed to have messed up a bit.

So is the 'current directory' the "directory of the executable", or "the current working directory of the environment"?

It depends on where your program is executed from. Running a program from the shell in linux, i believe it will use the current directory the shell is in as the "." directory.

Most programs are run from their own folders usually by the graphical UI in linux. But I think every Linux distribution allows you to set the "Run From..." setting on any executable you run. That location, which is set depending on how your program is run, is what's considered the current directory by the program (the . directory)

 

So folder/file and ./folder/file would be the same directory?

Yes. In linux those are the same.

The only exception is executable files in the shell - if you're in the same directory as an executable file, say "test.sh" - and you try to run "test.sh", it will not work. You need to run "./test.sh".

Share this post


Link to post
Share on other sites

And in the situation of running from a command-line prompt like this:

C:/> CD C:/path/to/folder/
C:/path/to/folder/> ../../different/folder/program.exe

 
'program.exe' will have the current working directory of 'C:/path/to/folder/ ', and not 'C:/path/different/folder/?

I didn’t see your follow-up question the first time around.
Yes, it will be the directory in the command-line.


L. Spiro Edited by L. Spiro

Share this post


Link to post
Share on other sites

And in the situation of running from a command-line prompt like this:

C:/> CD C:/path/to/folder/
C:/path/to/folder/> ../../different/folder/program.exe

 
'program.exe' will have the current working directory of 'C:/path/to/folder/ ', and not 'C:/path/different/folder/?

I didn’t see your follow-up question the first time around.
Yes, it will be the directory in the command-line.


L. Spiro

Odd, I failed to see that question too until you pointed it out. I blame the fact that the quotes were out of line. 

It works the same in Linux as well, as I mentioned before, the current path in which you are in when you invoke a program (regardless of where that program is) is what's used as the program's "working directory".

 

This is useful because a lot of command line tools in unix are just simple executables, So when you run "grep sometext somefile" in a directory, you expect the grep tool to search through "somefile" which is often located in the current directory, and find you any occurances of "sometext" in that file. 

You don't expect to have to place "somefile" in the directory in which the executable called "grep" is located in order to be able to search through it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!