Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I noticed that I can read text files without an extension .txt just fine. How come? Should I save these files with or without the .txt extension?

Also, what about .ini files? I usually use them like this: config.ini, should I remove the extension here to?

Any general resources on how Linux handles file extensions would be useful.

share|improve this question
add comment

6 Answers

up vote 27 down vote accepted

UNIX/Linux does not have the same early DOS / CP/M heritage that Windows does. So extensions are generally less significant to most UNIX utilities and tools.

I usually use a command-line only environment. Extensions in such an environment under Linux aren't really significant except as a convenience to the operator or user. (I don't have enough experience with KDE or GNOME to know how their filemanagers deal with extensions.)

But such convenience is usually important. If config.ini is really in Microsoft-standard ".ini" format, I'd let the extension stand. Plain old text files usually carry no extension in Linux, but this isn't universal for all programs configuration files. The programmer usually gets to decide that.

I think ".txt" is useful under Linux if you want to emphasize that it's NOT a configuration file or other machine-readable document. However, in source distributions, the convention is to name such files all caps without an extension (i.e. README, INSTALL, COPYING, etc.)

There are some standards and conventions but nothing stopping you from naming anything whatever you want, unless you are sharing things with others.

In Windows, naming a file .exe indicates to the shell (usually explorer.exe) that it's an executable file. UNIX builds this knowledge into the file system's permissions. If the proper x bits (see man chmod) are set, it is recognized as executable by shells and kernel functions (I believe). Beyond this, Linux doesn't care, most shells won't care, and most programs look in the file to find it's "type."

Of course, there's the nice command file which can analyze the file and tell you what it is with a degree of certainty. I believe if it can't match the data in the file with any known type, and if it contains only printable ASCII/Unicode characters, then it assumes its a text file.

@Bruce Ediger below is absolutely correct. There is nothing in the kernel or filesystem level, i.e. Linux itself, enforcing or caring that the contents of a file needs to match up with its name, or the program that is supposed to understand it. This doesn't mean it's not possible to create a shell or launcher utility to do things based on filename.

share|improve this answer
It's also useful if you're working in the console a lot, since nicely named files are easier to differentiate from others with globbing. –  lynxlynxlynx Aug 9 '12 at 17:59
You should emphasize that Linux file names do not have "extensions" - the ".txt" part of a file name that contains it is merely a substring. You should also emphasize that internal file organization (LF-ended strings, CR-LF ended strings, fixed size records, etc) is not even faintly related to name, nor is the "app" that knows about the file related to it by name. –  Bruce Ediger Aug 9 '12 at 18:18
I think only the FAT16 8.3 directory entries under DOS had a separate 3-byte field for the extension. FAT32 kept the 8.3 field for compatibility but the actual "long file name" is a string with no separate extension field, split against multiple directory entries (fandecheng.com/personal/interests/ewindows/nuhelp/lfnspec.htm) –  ultrasawblade Aug 9 '12 at 19:19
add comment

Unlike Windows, in UNIX systems the filetype is not determined by the extension. The file extension is and was simply a visual indicator for humans. You can name a JPEG foo.c and open it in Gimp. Another contrast from Windows is that on UNIX systems you must use the entire filename, while Windows will often take care of it for you (e.g., running just explorer vs. explorer.exe). On UNIX foo.sh must be called as foo.sh, not simply foo.

By convention people tend to use a common set of extensions. This practice, while unnecessary, is probably beneficial to humanity at large.

share|improve this answer
+1 for This practice…is probably beneficial for humanity at large –  Ulrich Dangel Aug 9 '12 at 17:30
Too bad the packaging diversity makes proper mime handling hard sometimes (eg. in KDE from my experience), though I don't know why the programs don't fall back on checking the magic byte. –  lynxlynxlynx Aug 9 '12 at 17:58
Because there is no "magic" byte. That's just shorthand for "all known filetypes that are reasonably well documented and structured enough to be reliably detected with a high degree of certainty". It works very well for text or container files. It generally fails miserably for any raw or unknown data types. –  bahamat Aug 9 '12 at 18:05
@bahamat It's not a byte, but there is a part of the file traditionally called the "magic number" that's supposed to define what the file contains. It's what the file command is looking at. (#! is the magic number for sh scripts, for example) –  Izkata Aug 9 '12 at 20:38
@lzkata right, like I said: "known filetypes that are reasonably well documented and structured enough to be reliably detected with a high degree of certainty". –  bahamat Aug 9 '12 at 22:36
show 3 more comments

You may want to read an Intro to Unix File System.

share|improve this answer
add comment

In general I've found keeping a strict, descriptive, naming convention to be very helpful. You don't need the extension in Unix, but I'd keep it for two reasons:

1) If that file will ever be read by a windows machine, it'll be easier to open than trying to find "open with...".

2) Extensions helps you, the user, figure out what the file is doing. In our lab: .txt = text file .sgi = irix compiled binary .linux = linux compiled binary

If you have to use older unix machines (we still use IRIX), keep in mind that carriage return is different in *nix machines, and programs might not appreciate if you try and open a file with windows carriage returns.

share|improve this answer
add comment

There are several good answers. I'd like to further answer part of the original question: "Any general resources on how Linux handles file extensions would be useful."

It is possible to register extensions, so that Linux always opens certain extensions with certain programs. This facility is called binfmt.

binfmt_misc is a capability of the Linux kernel which allows arbitrary executable file formats to be recognized and passed to certain user space applications, such as emulators and virtual machines. The executable formats are registered through a special purpose file system interface (similar to /proc). Debian-based distributions provide the functionality through an extra binfmt-support package.

Each format has a corresponding file entry in the /proc/sys/fs/binfmt_misc directory which can be read to get information about a given file format.

share|improve this answer
add comment

.txt can be opened through different applications. but the important thing is that it is used to classify the file in certain type. You can see if we save the same file using .html the file tries to open in internet explorer. the applications are made accordingly to support such file types. If you use .html in above the compiler tries to find the html attributes in it and shows result accordingly. same with the other extensions. .ini file can be read as text but the extension classify it as configuration file and hence the compiler treats it as configuration file not an ordinary text file as the text file is only a set of record and does not have specific function as that of .ini.hence you would not want to change the extension of ini to text

share|improve this answer
That may be the case on Windows, but (as explained in other answers), this is irrelevant in UN*X-ish operating systems. –  Piskvor Aug 10 '12 at 7:38
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.