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>
Reply to: