Re: Bug#282067: yes!
On Sat, 2004-12-18 at 13:37 -0800, Karsten M. Self wrote:
> on Sat, Dec 18, 2004 at 12:36:17PM +0100, Gergely Nagy (algernon@bonehunter.rulez.org) wrote:
> > On Fri, 2004-12-17 at 22:27 -0800, Karsten M. Self wrote:
> > > on Wed, Nov 24, 2004 at 04:54:27PM +0000, Colin Watson (cjwatson@debian.org) wrote:
> > > > On Fri, Nov 19, 2004 at 06:05:39PM +0100, martin f krafft wrote:
> > > > > also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.11.19.1802 +0100]:
> > > > > > Umm.. So if I have an NFS-shared $HOME, that I share between
> > > > > > Debian, various BSDs and commercial Unixes, I'll have to resort to
> > > > > > black magic to get some of my dotfiles appear where they need to,
> > > > > > on all of the systems I'm using them?
> > > > >
> > > > > Use symlinks.
> > > >
> > > > Or how about we all get a grip and stop making changes for the sake of
> > > > changes when the present situation works perfectly well and
> > > > interoperates well?
> > >
> > > $ ls -d . | wc -l
> > > 221
> > >
> > > ...note that that includes . & .., so we're talking 219 dotfiles and
> > > directories.
> > >
> > > Frankly, I'd like to see a $HOME cleanup. Dotfiles are hard to manage,
> >
> > For the past few years, I did not have any problems managing my
> > dotfiles, and I have quite a many (346 to be exact).
>
> Have you tracked growth and/or proliferation? I remember when I had two
> dotfiles. The trend is to more, and it's likely to accelerate.
Last year I had roughly 330, so it isn't growing that fast anymore.
> > > there are possible conflicts between packages and user files, and it's
> > > tough just to come up with a good directory list recipie to show, say,
> > > just dotfiles and directories, excluding . and .., on the command line,
> > > without resorting to filters and/or pipes.
> >
> > Pipes! Oh god! Run, run for your lives, he said pipes and filters!
> > Aaargh!
>
> Actually, I found a solution after a bit of banging around:
>
> $ ls -A --ignore=[^.]*
>
> ...which can be aliased, say:
>
> alias ldot='ls -A --ignore=[^.]*'
>
>
> As for avoiding filters and pipes in directory listings: there's a lot
> to be said for ls output which:
>
> - Is colorized.
> - Is columnar.
> - Doesn't behave radically different from any other ls commands.
find and xargs can help with that. Or a file manager (/me pats
dired-mode)
> > > I agree that policy is rather blunt for this to happen, but the
> > > desire needs to be expressed somewhere.
> >
> > He who is not happy with the situation, can symlink their stuff from
> > $HOME to $HOME/etc already. If you're not happy with that, why should I
> > be happy with symlinking stuff from $HOME/etc to $HOME?
>
> First, nobody's said which way the symlinks need to run. And
> compatibility modes have run both ways.
In an ideal world, they don't run neither direction. (By the way,
there's another way to move stuff to ~/etc: pass a
--config=~/etc/yadayada.conf option to various programs - provided they
support this, and place lotsa wrappers in ~/bin. *runs*)
> What's more important than raw implmentation is expressing a preference
> and getting applications developers to start following it. Everything
> else is bloviating.
My preference (both as a user and upstream for a few small utilities) is
to leave everything as-is until I have more files in ~/etc than in plain
old $HOME.
Rationale: many users just don't care about dotfiles, they don't even
see them, because their file manager hides them. Those who care about
them, and want to tweak them, are able to move them to whatever place
they want and set things up in a way that nothing breaks. So what would
be the benefit of moving stuff to ~/etc? Those who don't care, wouldn't
see anything (provided the migration is smooth, and the applications
either move the file from the old location automatically, or search both
locations; or otherwise it is ensured that the dotfile is always found),
those who care, could already migrate if they wanted it so much.
Judging from past experience, it's a fair bet that migration wouldn't be
as smooth as one might wish.
> > Especially if that's only on Debian,
>
> The idea would be for this to get beyond just Debian.
>
> There's some precedent for this. SysV init comes to mind: RH
> eventually came around to the LSB/Debian mode. With a compatibility
> mode link farm for a while. Debian's own migration from /usr/doc to
> /usr/share/doc is another.
> You'll likely find you've still /usr/doc populated with symlinks on your system.
No, I don't. /usr/doc is a symlink to /usr/share/doc on my main system.
On another, it only contains a handful (12, to be exact.. versus 1250
directories [and 1328 entries altogether] in /usr/share/doc) of links
which did not migrate yet.
While here, I'd like to point out that the /usr/doc -> /usr/share/doc
migration was entirely different. No program would behave differently if
I removed /usr/doc (if it would, that would be a bug). The same isn't
true for moving the dotfiles to someplace else. (Excluding documentation
readers and man here, whose purpose was to do stuff with those files,
for they are a minority)
Also, /usr/share/doc might be a standard now on Linux, it still isn't on
the BSDs (on one FreeBSD system, /usr/share/doc is a general Unix
documentation place, while package docs goes to /usr/local/share/doc),
while dotfiles are kept in $HOME on those systems too. Therefore, the
dotfile move would be a much much larger task, not one limited to
GNU/Linux systems.
--
Gergely Nagy
Reply to: