On Sun, 30 Sep 2007 10:06:59 -0500 "Mikkel L. Ellertson" <mikkel@xxxxxxxxxxxxxxxx> wrote: > Dumb question - is the link using an absolute or a relative path to > the directory it is pointing to? If it is a relative path, then is > it a valid path when in /etc/skel? Maybe the program/script that > sets up the new user's home directory does not copy bad symlinks... I actually tried it both ways. ln -s /opt/data/test . ln -s ../../../../opt/data/test . Neither one works. After further experimentation, I'm starting to think there is something more fundamentally strange going on here. When I create a new user with the .dosemu directory already in place in/etc/skel, I see this when I load dosemu and do a dir: command.com autoexec.bat cpi kernel.sys help bin gnu config.emu config.sys autoemu.bat doc dosemu nls tmp appinfo If I delete ~/.dosemu in my new user's directory and then run dosemu and do a dir I see this: autoexec.bat config.sys tmp And that's it. It seems to be looking in the wrong place for drive C: when the .dosemu directory is in /etc/skel (and hence finding all of those files), and it straightens itself out if it's allowed to create its own ~/.dosemu directory instead. I wonder what the difference is between a directory created from /etc/skel and a directory created by the dosemu program itself. The way that I make this /etc/skel is that I set up a desktop just the way I wanted it, then made a tar from that and un-tarred it in /etc/skel and did a "chown -R root.root /etc/skel" Everything else out of /etc/skel seems to work the way I expected it to when I create a new user, with the exception of dosemu. It's not a major issue; I just have to remember to run dosemu and create the symbolic link each time I set up a new user. But I would still like to know why it's not working the way that I thought it would. -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
