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

[Christopher Browne]

On 1/15/07, John Macdonald <john-Z7w/En0MP3xWk0Htik3J/w at public.gmane.org> wrote:
> 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.

Fewer restrictions, sure.

Separate namespaces have not been introduced.

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

I guess I should submit a bug report.

Because There Are No Extensions on many of the relevant platforms.

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

That primarily demonstrates that the Unix community has seen an
enormous influx of clueless Windows users who don't understand the
difference and who have added things wrongly to the documentation.

> > 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)?

No, because I'm not stupid.

CP/M has extensions because its filesystems support a separate
namespace devoted to providing them.

VMS has multiple forms of extensions.

But Unix doesn't.  And its tools don't.  Even if suffixes have been
wrongly termed "extensions" in some fragments of documentation.
-- 
http://linuxfinances.info/info/linuxdistributions.html
"...  memory leaks  are  quite acceptable  in  many applications  ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
--
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