• Create Account

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

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 -

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

### #7L. Spiro  Crossbones+   -  Reputation: 19239

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

### #8Milcho  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".

### #9L. Spiro  Crossbones+   -  Reputation: 19239

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.

### #10Milcho  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.

### #11Hodgman  Moderators   -  Reputation: 38840

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.

### #12SimonForsman  Crossbones+   -  Reputation: 6709

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!

### #13L. Spiro  Crossbones+   -  Reputation: 19239

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

### #14Hodgman  Moderators   -  Reputation: 38840

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.

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

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 -

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

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

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 -

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

### #17RulerOfNothing  Members   -  Reputation: 1300

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.

### #18Milcho  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...)

### #19SiCrane  Moderators   -  Reputation: 10421

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.

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

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 -

[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