Shell CLI challenge: as root, create symlink to a location on a location for a different user

This is not a real problem. I just noticed this CLI admin dilemma.
I have a script that adds 4 predefined users to a target FreeBSD installation dir. It runs as root. All users of the target system have file aaa in their home directory. They also require a symlink to this file named bbb

As root, how do I create symlink ~/bbb to ~/aaa for a different user? Problem is that ~/ gets translated to /root because root runs it. All users get a /home/root/bbb symlink but it should point to each user's own home directory. I can't find a solution for this except a post-installation action to fix the symlink names for all non-root users.

As root, how do I create symlink ~/bbb to ~/aaa for a different user's home directory? I have the feeling I'm missing something simple...
 
Bash:
srcfile=/root/file
for i in user1 user2 user3 user4; do
    destfile="/home/$i/file"
    ln -s $srcfile $destfile # -s required if not on same filesystem
done
# permissions issues are left as exercise for OP
 
Bash:
srcfile=/root/file
for i in user1 user2 user3 user4; do
    destfile="/home/$i/file"
    ln -s $srcfile $destfile # -s required if not on same filesystem
done
# permissions issues are left as exercise for OP
The source file should be ~/file for all users, pointing to their own home dir. Problem was that ~/file gets translated to /root/file always because root runs this code.
~<user> does avoid that.
 
for a in user1 user2 user3 user4; do (cd ~$a; ln -s aaa bbb; chown $a bbb); done If these users are not on the system where you run the script, you can chroot to $target before doing this.
 
Quit using the tilde and parse the password file then.
I thought the idea of it was to make referencing to the home dir of different users universal. They can all use the same application that installs things there. It's also time-efficient at manual CLI operation. ~ = my homedir. I often use >~/a to store some output temporarily without typing a full path.
 
for a in user1 user2 user3 user4; do (cd $a; ln -s aaa bbb; chown $a bbb); done If these users are not on the system where you run the script, you can chroot to $target before doing this.
True but every program you run inside the chrootdir has to be there including dll's. /bin/ln needs libc and libstdbuf.
 
I often use >~/a to store some output temporarily without typing a full path.
The shell will look up /etc/passwd to interpret ~$user so if this is not shared with the target, you have to locate target's password file but if you use chroot $target, it will lookup the appropriate passwd file.
 
The shell will look up /etc/passwd to interpret ~$user so if this is not shared with the target, you have to locate target's password file but if you use chroot $target, it will lookup the appropriate passwd file.
So ~ stands for the 7th field of the passwd file? I thought it was a POSIX demand that all shells comply with.
It still works without the password files, though. It's not using $HOME?
 
It can (and probably does) use $HOME for ~ but I am talking about ~$randomUser.
Everything before the / is the homedirs path only?
It's the $HOME dir. export HOME="" ends ~ interpretation. I think /usr/bin/login remembers it because it reads de passwd file anyway and passes it to the shell.
 
Back
Top