[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: i



dark@xs4all.nl (Richard Braakman)  wrote on 06.02.98 in <[🔎] m0y0d4L-001NHbC@night>:

> Santiago Vila wrote:
> > On Thu, 5 Feb 1998, Richard Braakman wrote:
> >
> > > Overlap between cfs_1.3.3-1 (nonus,orphaned) and chris-cust_0.4:
> > >    usr/bin/i
> > > Right.  I wonder which is the more intuitive meaning for i.
> > > Reported as #17841 to cfs and #17842 to christ-cust.
> >
> > This is namespace pollution again...
> > We would need some policy preventing this.
>
> Such a policy would be very hard to define.  Consider just the
> one-character commands.  Which of these are namespace pollution?

All except for those that match the description for "Important", that is,  
stuff every experienced Unix person would expect.

> (And most importantly, if it is to be policy, why?)

Anything else should be available for users (for example, for aliases and  
convenience scripts). IMHO, of course. In these days of tab completion,  
there's not much reason left to keep command names excessively short and  
meaningless.

There are too much short commands already. I wish we could use the same  
rule for two- and even three-character commands.

>    Command          Package
>    i and o          cfs
>    i and l          chris-cust
>    w                procps
>    B                sam
>    R                r-base
>    X                xbase
>    [                shellutils

Maybe w, certainly [. I see no reason why X shouldn't be named X, but I  
also don't see why it has to be in the $PATH. startx, xdm, openwin, stuff  
like that, but hardly X.

None of the others.

MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: