|
That hits the dot.  It's a delimiter.
But, If we look at it strictly and take it more precisely, linux file systems don't has file extensions and such definition!
Something about which we often break our head:
"In the name of the Compiler, the Stack, and the Bug-Free Code. Amen."
(source unknown)
|
|
|
|
|
I have had to consider it in both ways depending on what I have programmed. So I don't really care about the "definition".
When I need to interact with filenames, I just do a first test, check if it "is part" or not and then end the function according to the result.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
But that doesn't answer the question.
|
|
|
|
|
I think the "I don't care" subject line is a rather unambiguous choice among the answer alternatives provided.
|
|
|
|
|
I wasn't commenting on his subject line.
|
|
|
|
|
Quote: I refuse to vote because I don't care.
Option #3. Is a given option to answer the survey.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
In FAT, the dot is not represented. Can something that is not there be a part of the extension?
In various *nix file systems, the dot is just another printable character, part of the file name. *.nix programmers have a varying awareness of an 'extension' concept; they certainly use suffixes such as .c and .h as if they were extensions, but usually insist that you may call the file whatever you want - the filename might even contain spaces! But if you do (whether naming a code file function_code.h or function code.c), they may get tremendously upset (and so may their build job, maybe even their running code)!
In NTFS (long file names), the dot is represented - both intermediate ones, being part of the file name, and the final one. So it is tempting to say that the dot is part of the extension. But under Windows, in most contexts the behavior is like FAT files, as if the dot was never there.
If you use a mixture of Microsoftware and software from other vendors, you will see a mixture of extensions with or without the dot. Some software is tolerant and strip off a dot it doesn't want (or add one it wants), others might misinterpret and give you a double dot when merging with a file name (if they want the extension without a dot) or add the (intended) extension to the file name, with an empty extension. You will have to try it out. (In the old days, we even could read the documentation, but that is just sooo last millenium!) My impression is that an increasing number of APIs handling the extension separately want it with the dot.
If the API knows that it is an extension, because that's what it asked for, it really is redundant; it doesn't add any information. Sort of like starting every WWW browser link with "WWW." (or even "https://www.". When you have to write that for all links, it ends up being nothing but clutter. Nowadays, everyone refers to "codeproject.com" - the significant part of the URL, and the browser adds the insignificant clutter.
The dot is similar clutter. I have never seen a case where an extension without a dot could be mistaken for a complete file name, so the dot doesn't add anything. If I were asked to make the decision, to include the dot or not, I'd say: Omit it.
In real life, file systems vary. So my answer is: It depends on the file system. In a *.nix file system, there is no doubt: The dot is part of the extension (provided that you recognize the extension concept at all). In FAT, it is not.
|
|
|
|
|
Any dot you speak of is only a matter of a particular textual formatting, it doesn't actually exist.
Just as the punctuation in a date/time value is merely a feature of a particular formatting.
|
|
|
|
|
You mean ... the dot is a lie? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Well, I mean, it frequently lies between the name and the extension, though it can also lie within the name on some systems. Of course in OpenVMS it also lies within the directory path as well.
Not very trustworthy, those dots.
|
|
|
|
|
Extension includes the dot, as demonstrated by this PowerShell sample
New-Item test.txt -ItemType File | Select-Object -ExpandProperty Extension
which returns .txt, with the dot
^Priscilla
|
|
|
|
|
Exactly! 
It is called dotnet and not net!
|
|
|
|
|
Which doesn't answer the question.
|
|
|
|
|
Which is also why I voted that it is part of the extension. While you could argue that it's a delimiter (and I'd be ok with that) a file without an extension doesn't have a .
E.g. MyFile vs MyFile.txt
|
|
|
|
|
A directory name doesn't have a \ at the end, either.
So therefore, the \ that you have to add before a subdirectory is not a delimiter, is that right?
The \ is part of the subdirectory name, right?
If we had a file system without extensions, but related files were collected in a directory, e.g.
...\myprogram\h (for the declarations)
...\myprogram\c (for the active statement code)
...\myprogram\obj (for the compiled object code)
...\myprogram\exe (for the linked executable)
then the separating slashes are delimiters, and not part of neither directory nor file name - right? But if we have two separate name parts in the same file name descriptor (as in FAT), externally separated by a dot, like
...\myprogram.h (for the declarations)
...\myprogram.c (for the active statement code)
...\myprogram.obj (for the compiled object code)
...\myprogram.exe (for the linked executable)
then the separator is not a delimiter, and we make an arbitrary decision to associate it with the second name part, part of the extension?
You can take it one step further: Named (alternate) streams. ...\dir\Myfile.txt:stream2 - is the colon part of the stream name, similar to the dot being part of the extension? The slashes and colon are not part of any name part, while the dot is part of the extension name part? That appears rather random, arbitrary - doesn't it?`
In a *nix filesystem with no real concept of an 'extension', it makes sort of sense, except that it makes less sense to extract part of a name and call it 'extension'. In FAT, it is different. In NTFS, it is mixed.
So my answer to the question is 'Can't tell!' - but that is not one of the options.
|
|
|
|
|
The question: Your personal opinion, not "what my framework says".
|
|
|
|
|
...to be more exact in today's possibilities for filenames:
the LAST "." in a filename is the delimiter between filename and extension.
it is not part of the extension and not part of the filename. it's a delimiter.
|
|
|
|
|
With today's capabilities and technical language, we might even say that each part delimited by a dot excluding the first is a tag. The last tag is customarily used to determine the correct application to interprete that file's contents.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
