Jump to content

  • Log In with Google      Sign In   
  • Create Account

'.' in filepaths


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 Servant of the Lord   Crossbones+   -  Reputation: 19545

Like
1Likes
Like

Posted 23 January 2013 - 06:24 PM

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) 


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8861

Like
2Likes
Like

Posted 23 January 2013 - 06:33 PM

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.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Paradigm Shifter   Crossbones+   -  Reputation: 5372

Like
0Likes
Like

Posted 23 January 2013 - 06:38 PM

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.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#4 L. Spiro   Crossbones+   -  Reputation: 13577

Like
2Likes
Like

Posted 23 January 2013 - 06:41 PM

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.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 Milcho   Crossbones+   -  Reputation: 1177

Like
3Likes
Like

Posted 23 January 2013 - 07:11 PM

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)



#6 Servant of the Lord   Crossbones+   -  Reputation: 19545

Like
1Likes
Like

Posted 23 January 2013 - 07:32 PM

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.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#7 L. Spiro   Crossbones+   -  Reputation: 13577

Like
1Likes
Like

Posted 23 January 2013 - 07:46 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#8 Milcho   Crossbones+   -  Reputation: 1177

Like
1Likes
Like

Posted 23 January 2013 - 07:57 PM

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



#9 L. Spiro   Crossbones+   -  Reputation: 13577

Like
1Likes
Like

Posted 24 January 2013 - 03:12 AM

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.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#10 Milcho   Crossbones+   -  Reputation: 1177

Like
1Likes
Like

Posted 24 January 2013 - 03:33 AM

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.



#11 Hodgman   Moderators   -  Reputation: 30384

Like
1Likes
Like

Posted 24 January 2013 - 05:39 AM

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.


#12 SimonForsman   Crossbones+   -  Reputation: 6109

Like
2Likes
Like

Posted 24 January 2013 - 05:51 AM

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.


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#13 L. Spiro   Crossbones+   -  Reputation: 13577

Like
1Likes
Like

Posted 24 January 2013 - 05:58 AM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#14 Hodgman   Moderators   -  Reputation: 30384

Like
2Likes
Like

Posted 24 January 2013 - 06:09 AM

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.


#15 Servant of the Lord   Crossbones+   -  Reputation: 19545

Like
0Likes
Like

Posted 24 January 2013 - 11:57 AM

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!


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#16 Servant of the Lord   Crossbones+   -  Reputation: 19545

Like
0Likes
Like

Posted 25 January 2013 - 05:47 PM

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?).


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#17 RulerOfNothing   Members   -  Reputation: 1160

Like
1Likes
Like

Posted 25 January 2013 - 06:00 PM

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.

#18 Milcho   Crossbones+   -  Reputation: 1177

Like
1Likes
Like

Posted 25 January 2013 - 06:04 PM

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



#19 SiCrane   Moderators   -  Reputation: 9596

Like
1Likes
Like

Posted 25 January 2013 - 06:05 PM

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.

#20 Servant of the Lord   Crossbones+   -  Reputation: 19545

Like
0Likes
Like

Posted 25 January 2013 - 06:17 PM

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.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS