Re: [Gnu-arch-users] Re: {arch} directory

[Doran Moppert]

On Wed, Sep 24, 2003 at 12:06:29PM -0700, Tom Lord wrote:
> > From: Doran Moppert <address@hidden>
> 
> > true, it's served well on unix for a long time to name directories that the
> > user normally shouldn't have to interact with starting with a dot. CVS broke
> > this but it so rarely caused a problem due to the nature of the directory's
> > content .. but with arch it obviously (going by the list traffic) causes a 
> > lot
> > of discomfort.
> 
> That's funny.  I've reached the opposite conclusion from list traffic.

well in the lifetime of this thread at least, it seems controversial.

Agreed this is not a show stopper issue and very possible to work around, but
I still haven't seen a rationale (other than "visibility" -- which doesn't
really fly for a meta-info dir I'm not meant to interact with).

All I'm after is a simple explanation of the design decision: the preexistence
of the dotfiles convention and the usability issues with common tools make it
seem questionable. Yes, many of these "common tools" may be "broken" in some
sense, but when you're talking about some of the most widely used and
deployed unix shells, the code goes back a long way and calling for behaviour
changes in bash, tcsh and whatever else is not a very productive approach.

Nor do I think calling for the use of `tla inventory` over `find` is
appropriate: what, should my distribution Makefiles rely on tla?? Rename
{arch} to .tla and suddenly find, tar and /usr/bin/* work in the expected way
on a project directory.

Normally I'm not for change-for-the-sake-of-change. A good reason is needed to
defy tradition. I sense you're similarly inclined, so I'm just curious as to
why this one was broken.

D.