Interesting... most commenters here (so far) seem to be against the extension.
Can someone explain why? Except for executables, all the files I use have extensions -- .jpg, .html, .png, .mp3, .sh, and so on. Why should text files be any different? "README" doesn't tell me if it's text, or markdown, or HTML, or anything. Having ".txt" lets me know the format without opening it first to see.
I just can't figure out why anyone would ever not put a ".txt" extension on a text file, when the entire consumer ecosystem of computing uses extensions to help automate actions more usefully.
I hate them because they're an abstraction leak. The type of a file's content is different from the application that I want to use to manipulate it, which both are in turn different from the name I chose to give the file. That current file systems and the GUI representations on top of them are so badly designed as to confuse three unrelated concepts is a failing of software and as clear an indication as you could ask for of the triumph of Worse Is Better.
Why are they badly designed? There are a huge amount of bright OS hackers in the world, and a huge amount of mindshare on the problem. When the culmination of all this effort continues to be hilarious[1], I can only conclude that the problem is less tractable than we expected.
And in fact, that is what the people who work on the problem say[2]: that it is not tractable.
I'm not denying that fixing the problem requires a rethink. I guess I'm still just feeling beat up by the removal of the admittedly imperfect first class metadata from HFS in favor of file extensions. Roll that progress back, folks. Make NFS happy.
EDIT: I don't believe that the problem is tractable in a world where you need to maintain backwards compatibility; the solution then to me is ditch backwards compatibility. I almost always prefer elegant solutions to practical ones.
> the solution then to me is ditch backwards compatibility.
Backwards compatibility is a visible problem, but it isn't the True Problem with creatorcodes/metadata. The true problem is that a world with metadata is an unstable equilibrium, because what if just this once we get it wrong.
* Consider the case that the file's author got it wrong
* Consider the case of Python and RPython (or .js and .json, or .txt and .md) where a file can belong to multiple classes. Further consider the case where a system has a Python interpreter but not an RPython interpreter installed (or a JavaScript interpreter but not a JSON parser, or a text editor but not a MarkDown editor, or...)
* Consider the case where a document was saved with Excel 2013, but just happens to only use Excel 2010 features, because who really cares about whatever the heck they add in each new Office release
* Consider the case of a container format, like mkv or mp4, that does not alone completely describe the format of the data it contains
* Consider the case of sometimes-interchangable formats like m4a and m4b, mp4 and m4v, etc.
* Consider the difference between a storage format (.sqlite3) and the data that it contains (.localstorage, Firefox/Profiles/places.sqlite, ~/Library/Mail/V2/MailData/Envelope Index)
* Consider the case that that one day somebody just wants to make a "monkey-fighting file without filling out this monday-to-friday questionnaire" and either the "no really, it's a file" creator code is accepted by the International Body of Creator Codes, or it isn't and so there are five incompatible implementations.
As soon as you tolerate any of these (and probably the list is a lot longer than this), we are right back where we are now: trying to guess what kind of file it is by poking at it with a stick. Backwards compatibility is a red herring.
The conflation of file type and editor is orthogonal to the use of file extensions as type metadata. I agree that including the file's type in the name is suboptimal, but in a world where we're constantly sending files from one environment to a completely different one, it isn't entirely unreasonable either, as file names are the one truly universal way of identifying a file, and a file's type is part of its identity.
README files have been .txt for years... the only time I would expect an extension on one is if it's NOT a .txt file.
If you're a novice programmer and you're working with a library that has a README file you'll only be confused 1 time, after that you'll know. If your OS gets confused... well, that's your fault for your OS selection and you should be used to using "open with...".
If it has a "format", add an extension. If it's plain text, it should be redundant.
README for text, README.md for markdown, README.rtf for RTF, etc.
That some operating systems can't figure out what to do with a plain-text file is not the issue here. Hacking on an extension to appease this seems messy.
An image extension can be one of many formats (png, jpg, gif etc). The format is important here because the application that will open it (the image viewer for example) needs to be able to understand it[1]. The README is a simple plain text file. It has no requirements. Just open it with your text editor.
Adding a .txt extension would not be an earth-collapsing-into-a-black-hole kind of thing but there is a problem with it. You are only doing it so that an application can open it more easily. So, here we have a suggestion to change all README files so that an application can open them instead of changing an application so that it can open all README files. Not a good idea!
[1]: Actually I lied, the file extension is not that important; it only gives a hint of the format and reading the file will reveal it's format. However, you might want to open different image formats with different image processing applications.
What a facile display of false heroism. Ignoring users is the second easiest thing in the world, right after declaring that you're too cool for Microsoft. But this opinion has neither heart nor intellect behind it. It's pure hipsterism — "Yeah, I'm above Microsoft and all the sheeple who use their products!"
If you don't want to support Windows, that's cool. It's your choice. But don't act like this is some great moral stance any more than companies refusing to provide device drivers for Linux.
The idea of a minimal technical hurdle is important in free software. If we adapt everything from our free world to look just like the Windows world, Windows users will never notice that there's something else better. It's important that free software give itself some competitive advantage over nonfree software, especially for its users.
This is a much better-reasoned response. Like I said, excluding people is not inherently unreasonable. You almost always have to exclude someone, and you're free to define that "someone" in whatever way suits you best. But it isn't something to make blustering declarations about, as though you're taking some great moral stance — it's a practical choice that everyone has to make.
This is a really important point. TXT files are associated with Notepad by default. If we want README.txt (or README.md/rst/org.txt) files to be read by the least sophisticated users, then they should all have Windows line endings.
Besides being a joke based off a classic Dilbert cartoon, Windows really is broken, at least in this one specific area.
File extensions should only be used by people. The OS should have other ways of knowing the file type. And ".txt" is redundant. The default assumption should be "text" and only other file types should require extensions. IMHO.
Notice that I never disagreed with anyone on this. I also think that file extensions are broken. My issue is that you (and a few others) lay the blame solely on Redmond. The issue of file extensions goes far beyond Windows. Every operating system is subject to them.
Out curiosity, what sort of mechanism do you think is best for the OS to figure out the file type? Metadata can be opaque and leads to applications being rigid about what type of input they'll accept, and sniffing magic bytes can't possibly be sufficiently reliable. Relying on extensions is suboptimal in terms of polluting what should be a logically independent attribute of a file, the name, with information about its type, but practically it seems like a serviceable and flexible solution.
The 'correct' way to determine the type of a file is indeed to look at metadata. This includes things like magic numbers and extensions, but shouldn't be limited to those things.
Just looking at extensions can be misleading because not all files have extensions and some extensions correspond to multiple types of files. In general, no method will be perfect because no modern OS provides dedicated file typing (some older operating systems stored the file type as metadata, although even that breaks down at the boundary between your computer and the rest of the world). The imperfection is usually manageable, depending on the type of file (which is the real answer to your question - it depends on why you want to know).
Applications that won't open what I tell them to because they disagree about the file type are just broken. (Having to rename files whenever I want to open them is annoying. Having to replace a good piece of software because it refuses to follow instructions is even more annoying.)
All my Windows and Linux systems let me change the filename, without selecting the extension by default, and in the rare case that I want, I can change the extension too, from the same interface.
.md is a special type of .txt file. Nothing wrong with having a README.md. Let the OS have a default for reading .md files. In Windows that may be Notepad or something completely specialized like markdownpad.com. If we are adding .txt because the target is novice users, then you should have README.txt so they can click on it.
In fact Winzip recognizes extension-less README files quite well. It shows them in a different color and most users understand that it is something to be viewed. The name 'README' is pretty obvious.
While we are at it, do we still need to use the three letter extensions which are a legacy of the MS-DOS era and FAT filesystems? A couple of years down the line, people would wonder why we tried to save one letter by typing 'txt'!
I don't work on anything with a README that is for nontechnical users, and I don't produce technical material for anything other than UNIX. No one I work with that I care about pleasing uses it. I'd rather stick with the tried and true convention.
While it may make logical sense to some people, the ultimate implication when you see a .txt file is that the developer uses Windows. I'm not sure a lot of developers are comfortable with that.
This isn't only of use to Windows users - lazy ZSH users can set up a suffix alias for .txt, so that you can open README.txt just by typing its name, but that doesn't work for files without extensions (like README).
README.md or README.markdown which IIRC is the proper extension for markdown files since .md had already been claimed by some other (now most likely obscure) file format prior to Markdown's rise to stardom.
> appears in Comic Sans to me because of some web font usage
Which I was admitting: this is on my end.
It's ironic because some opinions in this thread sounded like old-school "You want .txt because of Micro$oft", exactly the Microsoft-bashing we were used to read back then when websites where in Comic Sans.
Can someone explain why? Except for executables, all the files I use have extensions -- .jpg, .html, .png, .mp3, .sh, and so on. Why should text files be any different? "README" doesn't tell me if it's text, or markdown, or HTML, or anything. Having ".txt" lets me know the format without opening it first to see.
I just can't figure out why anyone would ever not put a ".txt" extension on a text file, when the entire consumer ecosystem of computing uses extensions to help automate actions more usefully.