Re: What is this rule for?
On Tue, 2009-09-29 at 13:37 -0700, Russ Allbery wrote: Andreas Tscharner starf...@sunrise.ch writes: This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, he'll be able to run it on both systems as GreatPerlScript. This is another interesting point... Should we also preserve the CamelCase names? This is merely a decoration under Windows, but is important under $unix! ...just kidding. Seriously, the developer had to[1] add a file extension to distribute the file to windows, it doesn't means that such bad practice should be carried-on on other platforms. As an alternative to [1], if a perl/python/$language developer wants windows users to be able to start a command easily, it is best to provide a windows foo.cmd file which merely launch the interpreter and command. As a benefit, the command can be launched by executing foo. Franklin [1] On doesn't actually have to specify the file extension. I can only speculate on why Python/Perl installer don't set PATHEXT properly... http://docs.activestate.com/activeperl/5.8/faq/Windows/ActivePerl-Winfaq4.html#What_s_the_equivalent_of_the_she -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Andreas Tscharner starf...@sunrise.ch writes: On 29.09.2009 08:21, Steve M. Robbins wrote: 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. -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Andreas Tscharner a écrit : 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? So I'm not the only one to wonder about this. After digging I've found the following discussion: http://lists.debian.org/debian-policy/2003/04/msg00031.html which led to the following bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753 which was fixed in version debian-policy/3.7.0.0. I agree with the arguments, but I am not convinced we should diverge from upstream on this topic, by the way. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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. ...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? -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
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. -- Ban cryptography! Yes. Let's also ban pencils, pens and paper, since criminals can use them to draw plans of the joint they are casing or even, god forbid, create one time pads to pass uncrackable codes to each other. Ban open spaces since criminals could use them to converse with each other out of earshot of the police. Let's ban flags since they could be used to pass secret messages in semaphore. In fact let's just ban all forms of verbal and non-verbal communication -- let's see those criminals make plans now! http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
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 signature.asc Description: This is a digitally signed message part.
Re: What is this rule for?
[George Danchev] 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. I think that is a historical accident. Before python got so popular, language-based prefixes were not common, but suffixes have always been popular, probably because people came from MS-DOS and its spiritual descendent, Windows NT. The other reason suffixes are worse is, again due to influence from MS-DOS, people don't think of them as part of the name. And, removing the suffix does not cause problems with tab completion in the shell. So it seems less harsh to strip suffixes than to strip prefixes. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Gunnar Wolf wrote: [snip] And because extensions truly mean nothing. Of course, I can This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl Don't get me wrong here: I see the reasons for removing the extensions, but I think this is a valid point for having one in the first place. Best regards Andreas -- Andreas Tscharner starf...@sunrise.ch -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -- Rich Cook -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Andreas Tscharner starf...@sunrise.ch writes: This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, he'll be able to run it on both systems as GreatPerlScript. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Russ Allbery r...@debian.org wrote: Andreas Tscharner starf...@sunrise.ch writes: This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, he'll be able to run it on both systems as GreatPerlScript. Yes. And those scripts that would run on Windows and expect GreatPerlScript.pl, but do not run on Unix *only* because the pl is missing - those script probably don't exist. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Frank Küster fr...@debian.org writes: Russ Allbery r...@debian.org wrote: If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, he'll be able to run it on both systems as GreatPerlScript. Yes. And those scripts that would run on Windows and expect GreatPerlScript.pl, but do not run on Unix *only* because the pl is missing - those script probably don't exist. Oh, I'm sure they do. I know that renaming binaries can break compatibility; I'm not arguing that. I'm just pointing out that it's not impossible to do the right thing. Transition issues certainly still apply. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
Andreas Tscharner dijo [Tue, Sep 29, 2009 at 10:35:46PM +0200]: And because extensions truly mean nothing. Of course, I can This is true for Unix/Posix systems, but unfortunately not for Windows systems. And if the maintainer of a great Perl script wants his script to work on both platforms, he'll probably will name it GreatPerlScript.pl If the extension .pl is linked with a Perl interpreter in Windows, he'll be able to run it on both systems without a prepending perl Don't get me wrong here: I see the reasons for removing the extensions, but I think this is a valid point for having one in the first place. That's the reason we sometimes diverge away from upstream: We don't cater for the exact same audience, and we might modify their chosen binary names to make things easier and more coherent for our users. -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
