Op 12-10-10 22:37, Jari Aalto schreef:
1)
In some specific environment where $HOME are readable inside a company,
it may be desireable to be able to access other user's configurations.
It's just that in today's environment, the user accounts are pretty much
locked in elsewhere, so accessing other user's config for typical
university or polytechnic, or other non-corporate environments in
useually discouraged by policy.
My experience is inside a company, where people work together on
projects. Typical $HOME is open for the group and closed for the world.
It's daily practice to read files from colleagues in your own group.
What I also see a lot is that $HOME is open for the world and
subdirectories are selectively closed for others or group (like I do).
So I can share files with people in my company who are not part of my
unix group.
So, I don't know is large user base would be affected if the default
were chnaged to use ~/.wcd and if not found, then revert back to the
old.
But an old version of wcd will not understand this. It will look for the
old file locations and fail. In companies people are often conservative
about software and operating systems. Upgrades are only done when
absolutely needed. I see a lot of people using very old versions of wcd.
They copy it to other colleagues. Some others use a new version. Wcd is
not part of the OS, it are all individual installs.
2)
The $HOME has been littering over the years as more and more software
put stuff under $HOME. This makes managing home a challenge.
The root of $HOME is worst place to put things. Although conveient for
few configurations, it starts to be annoying for 100-200 configurations
files.
Trading typicaly two or three wcd files for one directory does not bring
much advantage. I have 276 hidden files and directories in my $HOME (at
work). I never felt annoyed by it.
The probelem:
You can't version control each package's configs separately very
easily if it puts directly to $HOME.
But if package writes to $HOME/.package/ that directory can be
esily
- Backed up
I don't see a problem or why it makes a difference. We have all files
automatically backed up regularly in .snapshot directories. Also when
you backup up on tapes, all files under $HOME are included.
- put under version control
For me it's hard to imagine why anyone would like to put the .wcd files
under version control. These are not source files. A backup suffices.
The configuration of how wcd behaves is defined in the shell startup
files, where people add options to the wcd function, or set environment
variables. These are also in $HOME.
- scp'd somewhere else to make a copy
I don't see the difference in copying a hidden file or directory.
Typically you don't copy these files. Wcd tree files belong to the file
system where they are located on. A tree file, or alias, or stack file
makes no sense on a different file system with different paths. People
only copy the wcd settings in the shell startup file.
It also makes overall management simples when there would be always
a directory (C.f how ~/.ssh/ manages files.
SUMMARY
So, if you could ponder this and perhaps consider how the change would
help the future needs.
I will keep it in mind. I do agree that keeping by default all files
under ~/.wcd is cleaner. But considering the small amount of files I
rather keep it the way it is, so users are not bothered. I think that
more people will be annoyed if I change this, compared to people who are
annoyed by the amount of hidden files under $HOME.
best regards,
Erwin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
