Unix file extensions (Was: make apache2 serve file as htmL...)

[John Macdonald]

On Sun, Jan 14, 2007 at 10:51:04PM -0500, Christopher Browne wrote:
> On 1/12/07, John Macdonald <john-Z7w/En0MP3xWk0Htik3J/w at public.gmane.org> wrote:
> >On Fri, Jan 12, 2007 at 04:40:24PM +0000, Christopher Browne wrote:
> >> [...]  (Aside: People seem to keep forgetting that
> >> Unix has NO SUCH THING as a "file extension."  It's not MS-DOS.  It's
> >> not VMS.  It's not MVS.  All of those systems had special portions of
> >> filenames known as an "extension."  Unix doesn't do that.)
> >
> >Unix, the operating system kernel, has no special meaning or
> >support for file extensions.  It does, however, permit users
> >to use any conventions they like to organize their files.  The
> >only rules enforced by the operating system about file names are:
> >
> >- no slash in a file name (reserved for directory separator)
> >- no null in a file name (reserved for string terminator in system calls)
> >- "." and ".." are reserved for directory layout
> >- each type of file system has its own additional limitations, in 
> >particular
> >    the maximum length of a file name is a property of the particular file
> >    system type
> 
> Right.  This doesn't change that filenames have one single namespace,
> not two, as is the case on all those other OSes.
> 
> >On the other hand, Unix, the programming environment, has always
> >made use of file extensions to manage files.
> 
> Nonsense.  It never has, which should be blatantly obvious in view
> that Unix never had a separate namespace for file "extensions."

Only a small part of the programming environment depends upon
what is enforced by the operating system and file system,
and that part is not really considered a required part of the
programming environment.  Until BSD FFS came along, filenames
were restricted to 14 characters maximum, but as newer file
systems provided fewer restrictions the programming environment
continued work, just with fewer restrictions.

> Look at GCC documentation.  Does it say "behaviour is based on file
> extension?"  No.  It says:
> 
> "For any given input file, the file name suffix determines what kind
> of compilation is done"

It also says:

"You might also like to precompile a C header file with a .h
extension to be used in C++ compilations."

and:

"When used in combination with the -x command line option,
-save-temps is sensible enough to avoid over writing an input
source file with the same extension as an intermediate file."

and:

"-x assembler-with-cpp
    Specify the source language: C, C++, Objective-C, or assembly.
    This has nothing to do with standards conformance or extensions; it
    merely selects which base syntax to expect.  If you give none of
    these options, cpp will deduce the language from the extension of
    the source file: .c, .cc, .m, or .S.  Some other common extensions
    for C++ and assembly are also recognized.  If cpp does not recog-
    nize the extension, it will treat the file as C; this is the most
    generic mode."

and:

"-fpreprocessed is implicit if the input file has one of the
extensions .i, .ii or .mi.  These are the extensions that GCC
uses for preprocessed files created by -save-temps."

So, the gcc man page does not agree with you that file name
suffices may not be called extensions unless they are enforced
by the operating system and/or file system.

Browsing through the vim help pages (for syntax highlighting)
I also see lots of usage of extension to denote file name
suffices that specify the type of contents that are expected
to be found in  the file.

> >So, the original point is true, but only to a point.
> >The concept "you have no NEED to use extensions in Unix"
> >is useful for people to know.  However, any phrasing of that
> >concept that implies "you should not use extensions in Unix"
> >is just plain wrong.  So, be careful about how urgently you
> >present that message.
> 
> No, I don't take any of it back.  There are no extensions on Unix.

Unix does not have what *you* call extensions, but that viewpoint
is not adopted by the world at large.

> The documentation for the respective programs clearly demonstrates this.

It clearly demonstrates that using program suffices to denote
the type of content in a file is called "file name extension",
even on Unix systems.

> Using the term "extension" instead of "suffix" or "pattern" is sure to
> cause confusion, as it doesn't reflect the way things work.  This
> isn't VMS or TOPS-10 or MVS or CP/M; we don't have no steenking
> extensions.

Denying a term that is in common use is more likely to cause
confusion than using it for in a situation that is enforced
differently but generally has the same function.

While VMS, TOP-10, MVS, and CP/M (and numerous others) have
OS enforcement of extensions, they are surely inconsistant
with each other about exactly what the full ramifications are.

Do you next say that CP/M doesn't *really* have extensions
because they aren't automatically tied into version control
(another suffix usage on VMS)?

-- 
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists