• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Servant of the Lord

'.' in filepaths

19 posts in this topic

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) 

1

Share this post


Link to post
Share on other sites

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
2

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
0

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
2

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
1

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
1

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

1

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
1

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.

1

Share this post


Link to post
Share on other sites

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
1

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

 

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.

2

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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!

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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 (r), 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...)

1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0