> 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> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
