New answers tagged

0

short answer : you can't. long answer: HOME dir is set in /etc/passwd, 6th field. It is read upon loggin, your shell is started with this home dir. The proper way to change home dir for joe is : have joe log off. use usermod -d /new/home joe to change home dir for subsequent session. Once session is run, you must do two things: edit $HOME to change ...


2

The usermod command wont work if you're logged in with the user you are trying to make changes on. From the manual page on usermod it says: CAVEATS usermod will not allow you to change the name of a user who is logged in. You must make certain that the named user is not executing any processes when this command is being executed if the user's ...


1

You need to edit the /etc/passwd file to change home directory of users that are currently logged in. Edit the /etc/passwd with sudo vipw and change home directory of the user. vipw highly recommended other than vim or other editors since vipw will set lock to prevent any data corruption.


1

It's fine. Remember, it's your home directory; you can do anything you want in there. GNOME/KDE/whatever might complain if you go around deleting .config, but anything you do in your home directory will, by definition, only affect you. Adding some directories in .local is harmless. Putting something in a dot directory will be mildly inconvenient, ...


0

The common convention (used e.g. with some install-home targets, like for mercurial, known as hg) is to put them directly under $HOME, i.e., in $HOME/bin, $HOME/etc, $HOME/lib, and so on. This is the result of the GNUish configuration dance starting with ./configure --prefix=$HOME.


1

The obvious reasons why not: user's home-directories are often limited in size (quotas on shared systems) predefined profiles often have already added ~/bin to your PATH (making it more convenient to install in that directory) if you have control of the machine, installing into a shareable location works out nicely, e.g., /usr/local/bin. Your ...


1

Never ever move or delete the dot files in your home directory. This will break your environment because as stated, they hold your configuration. Some are recreated when missing and others not.


1

You would be going against alot of UNIX momentum and history renaming your the hidden folders in you home directory, I wouldn't do it. Not only do the existing programs expect those folders to exist but any applications you install in the future will just place more hidden folders in your home directory. I agree its annoying - I have almost 100 files and ...


3

Programs using dot files for configuration expect them to live directly in your home directory. Symlinks can indeed help with this. What you want to do can be achieved by moving your dot file to the required sub-directory (.dotfiles or .other in your example) and then symlinking the file you just moved into your home directory. Example (code to run from ...


2

As a rule of thumb, applications you run as a non-root user will put their configuration under /home. System-wide configuration resides under /etc (and to a lesser extent under /var/lib and other locations), but applications not running as root don't have write access to these locations. As for your 2nd question, it depends. If your new system contains the ...


1

If you copied the files to the new partition but didn't delete them from the root partition, the old ones are masked or hidden by mounting the new partition on top of them. In that case, you should still have the same amount of root partition being in use, no space being freed. Unless we both missed that part, deleting the old copies is not included in the ...


2

The new filesystem (/home) is mounted over the directory (/home) on the original filesystem. So the files are still there, but they are hidden from simple access. To avoid this, you would need to add some steps to your process. Namely, rename the /home directory after creating a copy of the content. Then, create a new empty directory /home as the new ...


2

It seems that there is a configuration somewhere pointing to that user. I have a few suggestions you can try. First, make sure your new $HOME has the right ownership. Secondly, read and post the error message given by Xorg. Thirdly, search your $HOME directory for any configuration files that hold the old $HOME path. cd $HOME grep -r "olduser" . It ...



Top 50 recent answers are included