[Annatar]

I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.

UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.

[JoshTriplett]

Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos.

UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.

[Annatar]

Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script.

Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair.

The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care.

Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with!

Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion.

UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system.

On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions!

On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.)

It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records?

This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer.

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

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

As someone who authored XCB, you should be no stranger to separation of policy from mechanism.

[flukus]

So if we look through the source tree of a random unix I won't find any .h or .c files?

[Annatar]

You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range.

Where are you going with that?

[flukus]

The point is .c and .h are recognized file types and Unix has them.

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