19 replies to this topic

[Servant of the Lord]

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) 

[Bacterius]

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, 23 January 2013 - 06:45 PM.

[Paradigm Shifter]

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, 23 January 2013 - 10:17 PM.

[L. Spiro]

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, 23 January 2013 - 07:21 PM.

[Milcho]

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)

[Servant of the Lord]

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, 24 January 2013 - 11:53 AM.

[L. Spiro]

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

[Milcho]

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".

[L. Spiro]

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, 24 January 2013 - 03:13 AM.

[Milcho]

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.

[Hodgman]

Also consider paths like C:/path/./to/./file -- that's equal to C:/path/to/file.

The dot is pretty meaningless.

 

It's mostly useful when you want to be explicit in the case where multiple directories are going to be searched for your input.

e.g. let's say that when you type 'notepad.exe' the windows command line, it first checks inside the system32 directory (i'm not sure if this is true) before checking the current directory.

If you wanted to be explicit that you meant the notepad.exe relative to the current working directory of your shell, you could type "./notepad.exe" instead, because the shell will resolve your dot-containing-input into a full path before it searches for that file.

Edited by Hodgman, 24 January 2013 - 05:42 AM.

[SimonForsman]

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

 

On Linux ./executablefile and executablefile are not the same when used from the shell.

 

"./executablefile" will attempt to launch executablefile from the current directory, "executablefile" will attempt to launch it from the directories listed in the PATH enviroment variable which may or may not include the current directory(.) (most distributions does not include the current directory in PATH by default so you usually have to launch applications using ./executablefile)

 

on Windows and DOS the system will try the current directory before it tries the ones in the PATH variable  but using ./file should stop it from using the PATH so they shouldn't behave identically.

 

the system() function in C and C++ should launch the specified application using the same shell the host application started from (so system("pause") and system("./pause") should behave differently), i would guess that the same is true for shellexecute in Windows, things like iostream however doesn't use the shells enviroment variables so all non absolute paths should be treated as relative paths.

[L. Spiro]

e.g. let's say that when you type 'notepad.exe' the windows command line, it first checks inside the system32 directory (i'm not sure if this is true) before checking the current directory.
If you wanted to be explicit that you meant the notepad.exe relative to the current working directory of your shell, you could type "./notepad.exe" instead, because the shell will resolve your dot-containing-input into a full path before it searches for that file.

I don’t think that is correct (I don’t know for a fact) based on how Windows searches for DLL’s.
Assuming the DLL search is related to executable searches, it should check the current working directory before the system32 directory. After also checking the executable’s directory (but if I had to wager, this is the part I would guess to be different and skipped entirely).
http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

I’ve never heard of any meaning related to the . in Windows paths, and my guess is it is just a carry-over from a past system such as DOS, FAT32, NTSF, or Unix-like behavior.

Again, I don’t know it for a fact (what Google search terms would you use for this anyway?) but I think the . has absolutely no meaning on Windows paths except for possibly in some special cases such as some DOS commands.


L. Spiro

[Hodgman]

I don’t think that is correct (I don’t know for a fact) based on how Windows searches for DLL’s.

Yeah I didn't mean to imply that that particular search path order is correct, just that the shell will expand the dot before searching for the file, so ".\notepad.exe" will stop it from finding it in the system32 directory (unless that's the shell's current working directory). If the working directory is "C:\", then the shell will be looking to run a file named "C:\notepad.exe", which only has one possible location.

This kind of behaviour is totally up to the shell though, and has nothing to do with the OS as a whole.

When building your own apps that interact with a file-system, you could implement or not implement similar ideas to make use of the dot.

Edited by Hodgman, 24 January 2013 - 06:12 AM.

[Servant of the Lord]

Thank you, this is all really helpful. I don't normally work with 'working directories' that are different from the executable directory (just launching the executable specifically or by shortcut), and I've very little experience with Mac and Linux systems.

 

Thank you very much!

[Servant of the Lord]

Rather than start a new thread, here's a closely related question: Is an empty file extension the same as no file extension?

 

Example: Is file the same as file. ? One has a no period and no extension, the other has a period with an empty extension. Are they treated identically by modern OSes (> Win XP), including Linux and Mac OSX?

 

I ask this because: Given a path by a string, how does one know if the path ends with a file or a directory?

 

If the final string segment ends with a '/', you know it's a directory.

If the final string segment contains a period, you are fairly sure it's a file (since folders don't usually, but can, contain periods).

But if the final string segment contains neither a period nor ends with a slash, it's very ambiguous (but assumed to be a file?).

[RulerOfNothing]

Preliminary testing appears to support the statement that "file" and "file." are interchangeable on modern Windows (in fact, when I made a file called "file." it simply got rid of the period) I cannot say anything definitive about Linux and OSX though.

[Milcho]

Files and Folders aren't just differentiated by 'extension'. In fact, extensions aren't really anything special - they're just part of the filename (windows can be configured to hide that part of the filename, but in reality, the extension is just a string).

 

You can try this yourself, on linux, if you type "ls -l" you'll see a list of properties preceeding each file, something like this for executables:

-rwxr-xr-x

or this:

-rw-r--r-- 

for non-executables. The properties are separated into categories - owner, group, and other - and each is given permission to read ®, write (w) or execute (x) a file.

see chmod man pages if you want more explanation: http://ss64.com/bash/chmod.html

 

A folder isn't like a file at all. It's an entry in the file system that simply says that there's a folder there. You rename a folder to something.exe and it still won't be executed (same on linux too)

Btw, a folder's properties on linux look like this:

drwxr-xr-x

That first letter (d) indicates its a folder on the filesystem.

 

Renaming a file that's 'executable' to whatever extension will stilll let you run that file from the command shell in linux. Windows is another story, that I'm not 100% sure of. It seems like it does treat files based on their extensions (for executables I mean).

 

Oh, and filenames in linux can't contain /. (though they can contain all other sorts of unreadable and impossible to use characters.. including newline..yeah...)

[SiCrane]

For the most part, given a path as a string you don't know if it's a file or a directory. You need to query the file system. Ex: with the stat() system function on POSIX systems, the is_directory() function in boost::filesystem, etc.

[Servant of the Lord]

For the most part, given a path as a string you don't know if it's a file or a directory. You need to query the file system. Ex: with the stat() system function on POSIX systems, the is_directory() function in boost::filesystem, etc.

 

Thanks, that's what I was wanting to know - whether there was a way to be reasonably confident merely from the string without querying the file system itself. Other than ending in a '/' guaranteeing it's not a file, there's not much you can go off of!

 

It would've been great if OSes enforced a period for filenames, even if the extension was left blank, or maybe used a separator to indicate where the path ends and the file begins. Maybe ':', like: my/path/to/file/:filename

 

Ofcourse, extensions don't really confirm a file is of any specific format anyway, so maybe that's just band-aiding an imperfect, but functional, system.