'.' in filepaths

Started by
18 comments, last by Servant of the Lord 11 years, 2 months ago

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.

Advertisement

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.

[size="1"]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!

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

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

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.

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!

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

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.

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

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.

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.

This topic is closed to new replies.

Advertisement