Re: What is this rule for?
> Ben Finney dijo [Tue, Sep 29, 2009 at 11:40:46PM +1000]:
> > > > On the other hand, Section 10.4 says only "the script name should not
> > > > include an extension". So you can leave the extension for
> > >
> > > What is the intention of this rule anyway?
> > To encourage command names (and hence command APIs, since the name is
> > part of the API for the command) that do not encode implementation
> > details, such as the programming language. This allows the program to be
> > later re-implemented in a different language without the command name
> > being misleading.
> And because extensions truly mean nothing. Of course, I can
> implement foo.py in Ruby as I am just prototyping but later decide to
> reimplement it (using the same name, as many scripts already depend on
> it) in Perl.
> In a Unix system, extensions are usually appended garbage which adds
> very, very little real value.
True. However, it makes no big difference whether people use (or resp. abuse)
file extensions to claim the language a program is implemented in, or they do
it within the base name. There are plenty of apps starring with py* and perl*,
(and we have them most for years, which is not that different from *.py and
*.pl) and I'd hesitate to characterize their naming style as tasteless or non-
Unix way, instead I'd rather accept it as is, since this was what the author
decided on and is what the rest of the world got used to.
> ...Or possibly we could decide on renaming /bin/ls to /bin/ls.elf in
> order to show what kind of file it is, and allowing for different
> implementations to coexist?
This is of course good argument. Perhaps, some groups of apps, are not that
challenging to be reimplemented in different ways, for various reasons
including historical ones.
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>