Re: Namespace pollution

Remco Blaakmeer writes ("Re: Namespace pollution"): > On Mon, 6 Apr 1998, Marcelo E. Magallon wrote: > > On Wed, 4 Mar 1998, Ian Jackson wrote: > > > Approval will not normally be granted except for the use of capital > > > letters where there appea

Re: Namespace pollution

On Mon, 6 Apr 1998, Marcelo E. Magallon wrote: > On Wed, 4 Mar 1998, Ian Jackson wrote: > > > Approval will not normally be granted except for the use of capital > > letters where there appear in an upstream package command name. > > Was this approved? Christian? > > I'm packaging Login.app, a

Re: Namespace pollution

On Wed, 4 Mar 1998, Ian Jackson wrote: > Approval will not normally be granted except for the use of capital > letters where there appear in an upstream package command name. Was this approved? Christian? I'm packaging Login.app, a graphical login prompt. The name of the binary is Login.app, dot

Re: Namespace pollution

> Maybe a dumb question, but what about bash's {,} syntax? If you have > commands with commas in the names, it could make this somewhat > awkward. Yes, you're right. Then, we should remove , from the set of allowed characters. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject

Re: Namespace pollution

Ian Jackson <[EMAIL PROTECTED]> writes: > The punctuation characters I specified are (I believe) precisely those > which are not metacharacters for the shell and file-manipulating > programs, I believe. If someone knows of a significant program for > which `,' in a command name would be troubling

Re: Namespace pollution

Clearly my original proposal should have included an exception for traditional Unix commands (and probably for POSIX-mandated short commands). Oliver Elphick: > why allow a comma? The punctuation characters I specified are (I believe) precisely those which are not metacharacters for the shell and

Re: Namespace pollution

> I propose the following policy: > > No package shall create without approval any command name (or > corresponding manpage): > > 1. not matching the regexp ^[a-z0-9].. > 2. matching ^... if it creates more than two such > 3. matching [^-+._,a-z0-9], or > 4. which is a single common dictionary wo

Re: Namespace pollution

"Oliver Elphick" wrote: >Let me restate this in English, to be sure that I understand it: > >"No package shall create without approval any command name or manpage less >than four characters long. Commands must consist only of lower-case letters, >digits or the symbols within these quotes:

Re: Namespace pollution

Ian Jackson wrote: >I propose the following policy: > >No package shall create without approval any command name (or >corresponding manpage): > >1. not matching the regexp ^[a-z0-9].. >2. matching ^... if it creates more than two such >3. matching [^-+._,a-z0-9], or Let me restate

Re: Namespace pollution

"a single common dictionary word" is vague and too restrictive. I also don't think it defines the collision space well. I think you can do better at defining this. Thanks Bruce

Re: Namespace pollution

I think that this proposed policy is too strict. It forbids several commands already in widespread use on the system, and it forbids program names from being a single (English?) word, which is unreasonable, in my opinion. Some command names that this policy forbids: (Section 1) GnomeScott Mail M

Namespace pollution

I propose the following policy: No package shall create without approval any command name (or corresponding manpage): 1. not matching the regexp ^[a-z0-9].. 2. matching ^... if it creates more than two such 3. matching [^-+._,a-z0-9], or 4. which is a single common dictionary word or any directo

Re: what to do with `namespace-pollution'

On Wed, Feb 11, 1998 at 08:22:08PM +0100, Milan Zamazal wrote: > > "MB" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > MB: There is no need to keep a silly choosen upstream name. We > MB: change a lot of things defined upstream (file location, etc), > MB: and I don't think tha

Re: what to do with `namespace-pollution'

> "MB" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: MB: There is no need to keep a silly choosen upstream name. We MB: change a lot of things defined upstream (file location, etc), MB: and I don't think that changing a name from "B" to something MB: more readable is confusin

Re: what to do with `namespace-pollution'

On Tue, Feb 10, 1998 at 09:26:36PM +0100, Christian Schwarz wrote: > > A few days ago there was a discussion on debian-devel about > `namespace-pollution', i.e., binaries in the PATH which use a very short > name (1 or 2 characters). The problem with such binaries is that users

what to do with `namespace-pollution'

A few days ago there was a discussion on debian-devel about `namespace-pollution', i.e., binaries in the PATH which use a very short name (1 or 2 characters). The problem with such binaries is that users usually take 1- or 2-character names for aliases, short shell scripts, etc. >