/etc/skel doesn't work?!
asv at inhio.net
Wed Apr 26 17:50:44 UTC 2017
Thank you for the info and apologies for the very late reply, I've been
away for a while and lost track of this issue.
I thank you for the "dot" explanation nevertheless the "looks like a
bug to me" was referred to the "/etc/skel" directory being there while
having no functionality at all.
But this has been explained by Arthur Chance within the email tread:
Looking at the svn entries for /etc/mtree/BSD.root.dist I find that
/etc/skel was introduced at 2.2.7-R by Jordan Hubbard on Feb 27th 1998
with the comment:
"MFC: /etc/skel doesn't seem to be used in the -current branch either,
but it doesn't hurt."
In fact creating a directory which has no purpose and no functionality
whatsoever and letting it there for almost 20 years until somebody
founds it and realises that is a dead object IT DOES hurt.
It should be removed. :)
On Mon, 2017-03-06 at 19:57 +0100, Polytropon wrote:
> On Mon, 06 Mar 2017 12:25:22 -0300, ASV wrote:
> > Hello there,
> > I haven't use this standard functionality for ages but yesterday I
> > suddenly needed and then I've tried ... and failed.
> > Further reading led me to add files that I want to be added on any
> > new
> > user home dir in /usr/share/skel/dot(filename).
> > For example: to make my customised .zshrc copied on any new user
> > home
> > dir I'd just copy the .zshrc file in question to
> > /usr/share/skel/dot.zshrc and it will be copied with the proper
> > rights
> > without the prepending "dot".
> > And that works!
> At the "top level", a real dot needs to be escaped with "dot.",
> both for files and directories. Within directories, files can
> be named "as is".
> A little sidenote:
> If you want to make users participate in the use of a customized
> C shell configuration, you can use the global /etc/csh.cshrc and
> leave the user's .cshrc (dot.cshrc in the skel/ directory) empty
> for individual overrides. Advantage: When you improve /etc/csh.cshrc,
> all users will immediately have that improvement, too.
> > Nonetheless, according to my understanding, any file placed into
> > /etc/skel should end up into the newly created user home directory
> > but
> > it does NOT.
> > Doesn't matter how the file is named.
> As I said, there is a specific naming convention that applies both
> to /usr/share/skel and /etc/skel content. You can make the adduser
> program use /etc/skel instead of /usr/share/skel in case you don't
> want to "pollute" that directory. :-)
> You can find details in "man adduser" and "man pw", which I'd like
> to quote from the -m option:
> This option instructs pw to attempt to create the user's
> home directory. While primarily useful when adding a new
> account with useradd, this may also be of use when moving
> an existing user's home directory elsewhere on the file
> system. The new home directory is populated with the con-
> tents of the skeleton directory, which typically contains a
> set of shell configuration files that the user may person-
> alize to taste. Files in this directory are usually named
> dot.<config> where the dot prefix will be stripped. When
> -m is used on an account with usermod, existing configura-
> tion files in the user's home directory are not overwritten
> from the skeleton files.
> This section clearly states the convention of the "dot" prefix.
> > Looks like a bug to me.
> No, it doesn't. :-)
> > My machine: FreeBSD 11.0-RELEASE-p2 (amd64)
> > Command used: pw useradd <username> -m
> > P.S. would be interesting to know why "dot" is required to be
> > prepended
> > in files added in /usr/share/skel
> Convention, because the copying routine uses this replacement
> for "real" files (source/dot.* -> target/.*) whereas it ignores
> hidden file (source/.*); I don't know why, but you can have
> hidden files in the skel/ directories which are ignored at
> its top level.
More information about the freebsd-questions