NAME ln -- make a link
SYNOPSIS ln name1[ name2 ]
DESCRIPTION ln creates a link to an existing file name1.
If name2 is given, the link has that name;
From 1971 Unix First Edition Manuals.
There is a second, simple, syntax form.
I put FILE or FILENAME instead of TARGET --- see comments etc.
See also very long addition at the bottom, addressing the iceberg, hard and soft of
ln, not just the tip of it.
ln has this:
ln [opt] FILENAME
In the 2nd form, create a link to FILENAME in the current directory.
where you don't need the link name. After
ln -s /usr/lib/modules you get a
modules -> /usr/lib/modules
with the same name as FILENAME ("target" or "source"), right where you are. No choice, no confusion.
Now if you are more demanding and want the link created under another name and/or somewhere else, you add that wish as name or path. The real target comes first, the extra fancy new link name second.
Or you say: "I know this arrow notation in
ls -l for links. I don't have an arrow in the shell to show the direction of my link. So I have to turn it around."
You create it in one direction, so you can use it in the other.
(END OF ANSWER-THE-QUESTION PART)
On another level, the word "link" itself carries a deep hidden double meaning. Symbolic links came later, so in the early days a link was just a link. There was no soft and hard, no
-s option. And now I even use the source-target symbolism:
mv A B --- move the whole file to B (dir or new name)
cp A B --- copy whole file (mv and cp are "the same" here)
ln A B --- copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keeping
At this stage, there are links, but no hard and soft, and
ls -l does not show arrows, because there is no direction in a (hard) link. A "link" at that stage of unix evolution meant that filename "B" (directory entry "B") in the filesystem points to the same inode as filename "A" is pointing to.
Files A and B are "linked" together, because they share the same blocks. So now with every
rm, the kernel has to check: do I delete/free this file's blocks on the disk, or is there another file linked to the same blocks? For that, a link counter is used.
Say you want to keep a big file on /tmp from being deleted and do
ln /tmp/bigfile. Now you have a large bigfile in your working dir. After cleaning /tmp and removing the "original", you happily go on using the same data blocks. You don't get a dead or dangling link, you have a normal file. Pointing to no file but only filesystem blocks as every dir entry does. Only now "cleaning" /tmp is not as effectve as it was. It looks empty, and it is, but the blocks on the partition don't get freed.
Even though a hard link does not cost space itself as
cp does, it can indirectly.
ln -s to the sequence above:
ln -s A B --- copy only the file's name to "B"
Now "B", the soft link, only has a string with a pathname. This is "soft" info. Technically "A" and "B" are unrelated. But still B is a "link" in the new sense that you can use that stored pathname as a shortcut to "A". Now it is "a link to A" (period) and not "linked with file A's inode"
Both kind of links can confuse not only humans but also the kernel/fs. The 1971 man page notes: "BUGS: links get backed up twice, and restored as separate files with separate inodes."
Hard links to directories (rare/not allowed) can easily lead to a clog.
Soft links to directories (very common) can lead to eternal loops - these have to be recognized by utilities / kernel.
Practical example in bash
Starting with a regular file "F"...
ln F Fhard
...makes Fhard the same size as F, but they BOTH appear now in a dark red WITHOUT arrows in
ls -l --color. Because of
stat showing "Links: 2" in connection with "Inode: xyz". Hard linking F turns F itself into a hard link. Both are/stay filetype "regular file". But both have an inode with a link count above 1.
ln -s F Fsoft
...makes a tiny "unregular" file "Fsoft" with filetype "symbolic link" --- even more space saving than an empty dir. A
ls -l shows nothing special for "F". For Fsoft, the shown size is 1 byte as the string is 'F', and
Fsoft -> F is displayed as name. No need to colorize a soft link to recognize one, because in the short form
ls -F you get a coiled chain
ls -l it looks like this:
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 F
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 Fhard
lrwxrwxrwx 1 root root 1 Sep 16 16:31 Fsoft -> F
Fhard has F's size and type.
Fsoft has F's name and F's name's length as size, and a different file type.
5932 F 5932 Fhard 0 Fsoft@
--block-size=1 does not yield same sizes either. Fsoft has size "one byte, zero blocks". F and Fhard deviate in parallel:
6074368 F 6074368 Fhard 0 Fsoft@
To see whether Fsoft is dangling or not,
ls lets you use colors.
ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file