[Annatar]

UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX.

If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.

[flukus]

Windows doesn't treat them in an special way either. You can open a text file with any/no extension.

[Annatar]

You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.

[flukus]

A Unix desktop environment will do the same, they use extensions as conventions, it's no different to Windows.

[Annatar]

No they do not, what in the world gave you that impression?

UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expect the OS to work.

Even so, a desktop environment on UNIX is just yet another application, sometimes it is just a single process. The operating system empathically does not provide any kind of file type recognition or handling for such a desktop environment application, and any such file type recognition and handling is proprietary to that application.

Since the core UNIX paradigm is one of everything is a file, and all files are nothing but a stream of bytes, the OS has no concept about the contents .h, .c, not shell scripts, let alone .wav, .au, or .mp3 files, for instance. The UNIX operating systems only deliver streams of bytes at the request of applications via the open(2) and read(2) system calls. That's policy. The mechanism of what applications (consumers) of that or those byte streams do with the stream is left up to the applications which consume the streams:

A Unix File Is Just a Big Bag of Bytes

A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.

http://www.catb.org/esr/writings/taoup/html/ch20s03.html

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...

[flukus]

> No they do not, what in the world gave you that impression?

Using desktop environments. If I click on a text file in KDE, it opens in kate. Same with every other linux desktop I've used and same one mac.

You're yet to say a single thing that doesn't apply equally on windows and unix.

[Annatar]

That is KDE specific, and has nothing whatsoever to do with the OS.

How does your KDE handle file types when you are logged into a headless server, without any kind of graphics hardware, and your console is a serial port? How does the UNIX kernel handle file types when you're on a headless server with no graphics hardware, and your output is stdout on a teletype terminal or a nullmodem cable on a serial port?

I guess you missed the point of everything I've written so far. Did you read the links I provided?