> On Tue, 29 Sep 2009, George Danchev wrote: > > 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, > > Both of these naming styles are annoying. Wasting characters in > commands on non-useful information gets in the way of users doing what > they want to do. > > If you're going to stick a command into a directory which is in > PATH,[1] then it should be named as precisely and concisely as > possible, while still being unique. If an executable encodes an > interface which is widely used outside of Debian, then a compatibility > symlink might still be in order, but otherwise, ditch the extension, > submit a patch upstream,[2] and get on with life. [But whatever is > done, don't spend too much time on it; if an upstream is doing this > sort of thing, odds are there are other, more insidious things > lurking, and it'd be a beter use (or waste!) of time trying to find > them.] > > > Don Armstrong > > 1: If this is some piddly executable in /usr/lib/foobar/blah.sh, then > it doesn't really matter; the author could call it > blah.sh.because.its.cool.nyatch because presumably no one is going to > actually run the executable directly. > > 2: It's perfectly fine if its named blah.sh in the source, so long as > it installs as blah on UNIX-y operating systems. Don, I hereby agree with the above (hence fully quoted & signed), believe me or not. However, I'm afraid that we have some sort of asymmetry at our side, since we claim that both (py* vs. *.py) are annoying, but make sure policy discriminates only one of them. It is the asymmetry I have mostly misgivings with, hence I'd hesitate to use adjectives the authors naming styles. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part.