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

[Christopher Browne]

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

> The compiler,
> linker, and make, for example, all use extensions in a
> consistant way to specify types of files used for programming.

No, since the filesystem never supported extensions, these tools do
not use extensions for *any* purpose.

Read the documentation for "Make," for instance.  It uses what are
called "suffix rules" to automate various transformations.  Not
extensions - suffix rules.

> The ls program uses file names that begin with . (i.e. contain
> only an extension) to denote files that are, by default,
> not listed.

In view of the nonexistence of extensions on Unix filesystems, it
should be obvious that this cannot be a correct characterization of
things.

If you read the man page for ls, it says nothing about extensions.

"-a" or "--all" indicates
   "do not ignore entries starting with ."

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"

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

The documentation for the respective programs clearly demonstrates this.

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