Symlink not being created - bash

I'm running Fedora on a laptop with a small SSD and large HDD. I've got the OS installed on the SSD and my data on the HDD.
All my files are located at /run/media/kennedy/data/Kennedy
What I had before (and want again) is a symlink from /home/kennedy to that location. That way I'm not messing with actual /home, but when I am in /home as normal user, all my things are easily accessed and stored with plenty of space. Right now /home/kennedy has the standard directories; desktop, documents, downloads, and so forth. No files worth worrying about.
So I opened a shell, logged in as su, and entered
ln -s /home/kennedy /run/media/kennedy/data/Kennedy
expecting that when I cd /home/kennedy and ls, I would see all my lovelies. Instead, I see that standard folders and nothing more. Whisky Tango Foxtrot, over.
edit to add: I'm pretty sure the permissions are right, but only pretty sure. How do I check and correct that (if off)?

You have to reverse the arguments:
ln -s /run/media/kennedy/data/Kennedy /home/kennedy
This will:
run successfully if /home/kennedy doesn't exist (kennedy would be the new symlink)
fail if /home/kennedy exists and it is not a directory (symlink or a regular file); need add -f flag in such a case - ls -sf ...
if /home/kennedy is a directory, then the symlink will be created as /home/kennedy/kennedy
See this related post: How to symlink a file in Linux?

You have the command backwards, it should be:
ln -s /run/media/kennedy/data/Kennedy kennedy
Invoke the command while you are in your /home directory, then you should be set.

Related

Symlink broken right after creation

I downloaded the linux Tor Browser package, which is a self-contained folder. I made a symlink to the run script:
$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser
However, the link was broken upon creation. All I did was run that command, nothing else, and it was broken. I did ls and got:
lrwxrwxrwx 1 synful synful 28 Jul 18 21:52 torbrowser -> torbrowser/start-tor-browser
...which is weird because torbrowser/start-tor-browser had 755 permissions. Also, I ran file:
$ file ~/bin/torbrowser
bin/torbrowser: broken symbolic link to `torbrowser/start-tor-browser'
I made a new bash script and a symlink to it to test this, and had no such problems. I'm not sure why it's only happening with start-tor-browser. It's got normal permissions and is just a normal bash script (even according to the file command).
...any ideas?
It's important to know that
ln -s SOURCE TARGET
create a symlink called TARGET which is symbolically linked to the string SOURCE. If SOURCE is a relative path (that is, it does not start with /), then it is interpreted relative to the directory that TARGET is in. If it is an absolute path, then it's an absolute path. If it is a string which could not be a path, or includes a non-existing path or file, or is otherwise not a valid path string, no matter. ln -s does not check that SOURCE exists or is even a valid path. You could store almost any shortish string you wanted in the dirent.
So when you do this:
$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser
what you are doing is, roughly:
create a directory entry inside your bin subdirectory with name torbrowser.
Make that new directory entry a symbolic link (symlink) to the (relative) path torbrowser/start-tor-browser
The new symlink is a circular. ~/bin/torbrowser is linked to ~/bin/torbrowser/start-tor-browser, which means you have to follow the symlink in order to resolve the symlink. If you try to use it, you'll see:
$ cat ~/bin/torbrowser
cat: /home/joshlf13/bin/torbrowser: Too many levels of symbolic links
$
Sometimes -- often, even -- the ability to symlink to a relative path is extremely handy. A common use is getting rid of version numbers:
$ ln -s apps/my_fancy_app_v2.63.1 apps/my_fancy_app
Now, not only can I call my_fancy_app without remembering its version string, I can also move the entire folder elsewhere, without breaking the symlink:
$ mv apps /usr/local/apps
But other times -- as in your example, I think -- you need to symlink to an absolute path.
As for the permissions, symlinks always have permissions lrwxrwxrwx because the actual permissions used by file operations are the permissions on the real file. (You can think of that as meaning that anyone can follow the symlink, but that's not quite true: they'd also need read permissions for any directory they need to follow. More accurately, anyone who can see the symlink can see the name it points to, even if they have no access to the file with that name.
It is important that the TARGET you specify in
ln -s TARGET LINK_NAME
is full path of the file/directory.
I had this issue, in my case when I cd into target's directory and did
ln -s ./eclipse.ini ~/Desktop/eclipse1 resulted in broken link
But when I did this ln -s $(pwd)/eclipse.ini ~/Desktop/eclipse It worked!
the above usage given for ln:
ln -s SOURCE TARGET
is correct, but confusing when referred to the man page:
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
as 'TARGET' has different meaning
Note: this can also happen due to permissions
eg. if you try
sudo ln -s /home/somesuperuser/commonfile /home/somenormaluser/commonfile
this would not work, while
sudo mv /home/somesuperuser/commonfile /usr/share/commonfile
sudo ln -s /usr/share/commonfile /home/somenormaluser/commonfile
sudo ln -s /usr/share/commonfile /home/somesuperuser/commonfile
does work
I also struggled with this, I got lots of time Linux sym link broken after creating, but solution is simple - as mentioned by rici:
If SOURCE is a relative path (that is, it does not start with /), then
it is interpreted relative to the directory that TARGET is in.
In other words:
You have this dirs:
- my_directory
-- directory_1
- other_directory
-- *you want your directory_1 link here*
Easiest approach. Got to "other_directory". From there is simple:
ln -s ../my_directory/directory_1 directory_1
Done :)

Moving files between users from shell in Mountain Lion

I am working on a group of Bash shell scripts and have one of the scripts check if an update is needed. If so, it needs to copy files from my computer to others. In Snow Leopard I can just do something like.
account=$(whoami)
cp "/Users/Sleepykrooks/Library/Services/Program" "/Users/$account/Library/Services/Program"
But with Mountain Lion, even though the full path still would look like this, using the same thing leads to an error of not finding the folder or file it's looking for. However it does work if you use something like.
cp "/Library/Services/Program" "/Library/Services/Program"
This is where I am unsure how to use my path to copy my updated files to another user's path.
Thank you for the help.
When you copy a folder in Unix, you usually need the -R flag. (See the cp manpage).
cp -R "/Users/Sleepykrooks/Library/Services/Program" "/Users/$account/Library/Services/Program"
Or, using the BASH shortcut of ~ for home directory:
cp -R ~Sleepykrooks/Library/Services/Program ~/Library/Services/Program
Normally, you should not be touching the /Library directory or the user's ~/Library directory on the Mac. And, you should never touch anything under /System unless you can stare into a TV camera and say in an absolutely serious tone "I'm a professional. Don't try this at home."

Locate command can't find anything inside Documents folder on mac

As it says in the description. I first check our database is up to date
mh547:bin crashandburn4$ sudo /usr/libexec/locate.updatedb
Password: #password entered and function executed without errors
I then try and search for something inside my Documents folder
mh547:bin crashandburn4$ cd ~/Documents/
mh547:Documents crashandburn4$ ls
Mamp_workspace/ Scenarios.docx gc01/
mh547:Documents crashandburn4$ locate Scenarios.docx #nothing returned
I then try another random folder:
mh547:Documents crashandburn4$ cd ..
mh547:~ crashandburn4$ ls
Applications/ Movies/ drawable/ untitled-2.pdf
Desktop/ Music/ drawable-xhdpi/ untitled-2.synctex.gz
Documents/ Pictures/ dwhelper/ untitled-2.tex
Downloads/ Public/ linux_ssh* website-terminal-copy-paste
Dropbox/ Samsung/ scripts/ workspace/
Google Drive/ Sites/ untitled-2.aux workspace_copy_to_linux*
Library/ android-sdks/ untitled-2.log
mh547:~ crashandburn4$ locate website-terminal-copy-paste
/Users/crashandburn4/website-terminal-copy-paste #correct result returned
can anyone help me? I've been stuck on this for a good half hour or so.
As pointed out by plundra, that's because the locate OSX ships with is old and crippled and doesn't index and/or report files which are not readable by nobody, even when run as root. What you can do though is either install homebrew and then GNU locate, or, as suggested here use mdfind -name instead (I don't have an OSX box at hand to test this).
It's because your Documents-folder isn't world readable, which is a good thing, specially on shared systems.
The BUGS section of the locate(1) man-page explains it:
The locate database is typically built by user ''nobody'' and the
locate.updatedb(8) utility skips directories which are not readable
for user ''nobody'', group ''nobody'', or world. For example, if your
HOME directory is not world-readable, none of your files are in the
database.
Try running ls -ld ~/Documents and you'll see the permissions. Wikipedia have an article on Unix permissions if you are unfamiliar with these.
You can do sudo ln -s /usr/libexec/locate.updatedb /usr/local/bin/updatedb to make the updatedb command available

How do I symlink the contents of the folder without including the actual folder?

I'm trying to symlink my Library/Fonts directory with a folder in my Dropbox, so that I don't have to keep installing and figuring out which machine has the fonts I need. When I try this:
ln -s Fonts/ ~/Library/Fonts
I get this error in return:
ln: /Users/Username/Library/Fonts/: File exists
I can't delete the folder because its required by the system and thus won't let you delete.
Delete the Fonts folder (obviously you'll want to move any files you want saved somewhere else) from your Dropbox directory and then type:
ln -s ~/Library/Fonts Fonts
Note that you do not want the trailing / for that last Fonts directory.
Edit to address comment:
You're right that this only links to one /Library/Fonts folder. You might try doing this on one machine and then on the other machine(s), try:
Turn off Dropbox
Save off the ~/Dropbox/Fonts folder
Perform the same symbolic link function as on the first computer (ln -s ~/Library/Fonts Fonts)
Copy over any fonts that might not be on this machine
Turn Dropbox back on
I have not tried this so I don't know if it will work, but it should do no harm.
The other alternative that definitely will work is to set up a cron job to copy any non-existent fonts in your ~/Library/Fonts folder to your ~/Dropbox/Fonts folder and vice-versa. If the symbolic link trick works, I think that would be preferred.
ln -s -F will force the creation of the link removing the original target before creating the link.
this method will only work if the target folder is already a symlink.
Using the ln that ships with OSX or BSD-derived unixes:
ln -s -h -F /source/folder/to/use /destination/folder/to/overwrite
the -h is key here. otherwise you'll end up with something like ~/Library/Fonts/Fonts because it traverses inside that folder. the -F alone wouldn't try to overwrite, since it wouldn't see a conflict once it got inside that folder.
relevant portions of ln manpage:
ln [-Ffhinsv] source_file ... target_dir
-s Create a symbolic link.
-h If the target_file or target_dir is a symbolic link, do not follow it.
This is most useful with the -f option, to replace a symlink which may
point to a directory.
-F If the target file already exists and is a directory, then remove it
so that the link may occur.
GNU coreutils ln users:
if you're using the GNU ln from the coreutils package (linux, brew, macports, etc.) use -T:
ln -sTf /source/folder/to/use /destination/folder/to/overwrite
additionally, with the GNU ln you can replace normal folders. look at its manpage for the -t option, use it to specify the parent of the target folder:
ln -sf -t /destination/folder/to/overwrite/.. /source/folder/to/use
the trailing /.. is needed to target creation inside the parent dir, leave it in place.

Adding custom log locations to the OS X console application

After searching online, the best solution I've found so far is to just make a symbolic link in either "/Library/logs/" or "~/Library/logs/" to get it to show up in the Console application.
I'm wondering if it would be possible to add a new directory or log file to the "root" level directly under the "LOG FILES" section in the console.
Here's a quick screenshot:
There is one way to get your log files into the console.
You can add a symlink to the log file or log directory to one of the directories in the list. The directory ~/Library/Logs seems like the logical choice for adding your own log files.
For myself I wanted easy access to apache2 logs. I installed apache2 using macports and the default log file is located at /opt/local/apache2/logs.
Thus all I did was create the symlink to that directory.
# cd ~/Library/Logs
# ln -s /opt/local/apache2/logs/ apache2
Now I can easily use the console.app to get to the logs.
My solution for macOS Sierra:
First and last step, you must create a hard link from your source (log) directory into (as example) one of existing official log directories, you can seen in console.app.
I take my ~/Library/Logs directory for that.
hln /usr/local/var/log /Users/dierk/Library/Logs/_usr_local_var_log
Cross-posting this great tool for creating hardlinks originally posted by Sam.
Short intro:
To install Hardlink, ensure you've installed homebrew, then run:
brew install hardlink-osx
Once installed, create a hard link with:
hln [source] [destination]
I actually just came across this option that worked perfectly for me:
Actually if you open terminal and...
$ cd /Library/Logs
then sym-link to your new log directory. eg i want my chroot'ed apache logs as 'www'
$ ln -s /chroot/apache/private/var/log www
then re-open Console.app
drill down into /Library/Logs and you will find your sym-linked directory.
;-)
Mohclips.
http://forums.macosxhints.com/showthread.php?t=35680
In Terminal run this command... append any log file directories you want to add
defaults write com.apple.Console LogFolderPaths -array '~/Library/Logs/' '/Library/Logs/' '/var/log/' '/opt/local/var/log/'
Since Mavericks, symlink behavior as change so "ln - s" doesn't work anymore.
use hardlink-osx instead to create an hardlink to your directory (may be installed via homebrew)
Very old post I know but, this is the only way I could get it to work.
cd /Library/Logs
sudo mkdir log_files
sudo ln -s /Users/USERNAME/Sites/website/logs/* log_files
In mac os 10.11, you may not be able to link to folder of logs, but instead you need to link to each log of logs folder in side console.
ln -s /opt/local/apache2/logs/error_log ~/Library/Logs/Apache2/error_log
You can just open any text file with console.app and it will add and keep it. Folder's though, no luck on that yet.
I was able to hardlink the files into ~/Library/logs by running:
ln /usr/local/var/logs/postgres.log ~/Library/logs
Notice the absence of -s.
No luck for directories though.
OSX Sierra 10.12.6
Just tried to do something similar.
I enter this in terminal, while the Console.app was running.
sudo mkdir -p /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
Now whenever I open the Console.app it crashes.
Really wish there was a way of adding log files in the files. You CAN do it by dragging and dropping a folder onto the Console.app (given it a directory path as an argument), but the added folder only displays its immediate contents and doesn't allow for recursively descending into folders.
---------EDIT BELOW----------
Nevermind I stupidly did something like this leading to infinite recursion in Console.app
sudo mkdir -p /usr/local/var/log/apache2
sudo ln -s /private/var/log/apache2/apache2 /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
I don't believe it's possible.
If you're generating log files, you should generate them into one of the standard locations anyway, so this won't be an issue.

Resources