Tips for remembering the order of parameters for ln?

Question

I have used ln to write symbolic links for years but I still get the order of parameters the wrong away around.

This usually has me writing:

ln -s a b

and then looking at the output to remind myself.

I always imagine to be a -> b as I read it when it's actually the opposite b -> a. This feels counter-intuitive so I find that I'm always second-guessing myself.

Does anyone have any tips to help me remember the correct order?

Answer 1

I go by "ln is like cp. The 'source' needs to come first."

Answer 2

I use the following: ln has a one-argument form (2nd form listed in the manpage) in which only the target is required (because how could ln work at all without knowing the target) and ln creates the link in the current directory. The two-argument form is an addition to the one-argument form, thus the target is always the first argument.

Answer 3

Most Unices document the ln command as

ln source target

(I'm omitting options etc. here)

Examples:

• The POSIX standard

    ln [-fs] [-L|-P] source_file target_file
  

• OpenBSD:

    ln [-fhLnPs] source [target]
  

• NetBSD and FreeBSD

    ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]
  

• macOS

    ln [-Ffhinsv] source_file [target_file]
  

• Solaris

    /usr/bin/ln [-fns] source_file [target]
  

• AIX

    ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
  

The GNU ln manual is the odd one out and calls the source target and the target linkname.

• GNU manual for ln

    ln [option]… [-T] target linkname
  

Ignoring the GNU choice of words, the ln utility follows the same semantics as, e.g. mv and cp in that the target is what is created from the source.

Therefore,

ln -s a b

would create the symbolic link b pointing to a. Or in other words, b is the target of the operation that creates a symbolic link using a as the source.

Note that when creating symbolic links, the source is simply a string representing what the symbolic link should point at. There is usually no check made to validate that it points to anything useful:

$ ln -s "hello world" README.txt
$ ls -l
total 0
lrwxr-xr-x  1 kk  wheel  11 Sep 15 11:39 README.txt -> hello world

---

A personal thought about GNU's choice to use "target" and "link name" rather than "source" followed by "target":

It may seem obvious that the second argument, the thing that is created, should be the "link name" and that the first argument, the target of the link, is "target". However, that's only true when you use the link.

When you create the link, which is what you're doing with ln, the second argument, the thing that is created, is the "target" of the ln operation, and it's created using the first argument, the "source".

This, together with the analogous "source"->"target" ordering of arguments to other basic tools, makes the non-GNU documentation for ln seem more natural.

Answer 4

I recently heard a great way to remember this particular thing: a rhyme

Something old, something new,

something borrowed, something blue,

and a sixpence in her shoe.

The first verse is what the arguments of ln are: something old followed by a name of the new directory entry.

Answer 5

In case this helps anyone: I've gotten used to thinking of it as "ln what where", which helps me remember that the first argument ("what") is the existing file, the second ("where") is the place to put (a link to) it. As opposed to the reasoning in most of the other answers, this is nothing more than a pithy phrase that I can mentally recite to myself as I'm typing a command, which serves as a memory aid. This probably won't be useful to everyone but I suspect that it will help some people.

It helps that the other standard file manipulation commands use the same convention, so I can do the same for cp and mv.

Answer 6

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.

---

So GNU 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.

Adding 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 @ appended: Fsoft@

With 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.

Short ls -sF:

5932 F    5932 Fhard     0 Fsoft@

adding --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

Answer 7

It is really helpful to remember that the name of the link is optional. If it is not given, the basename of the link target is used.

ln -s /path/to/file1 file1

is identical to dropping the link name completely:

ln -s /path/to/file1

This would not make any sense if the link target was mentioned last.

Answer 8

Just think Unix -> AT&T -> destination on right:

mov %eax, %ebx  ;; AT&T style assembler syntax: %ebx register gets value of %ecx

mv foo bar    ;; foo renamed to bar

cp foo bar    ;; contents of foo go to bar

foo | bar     ;; data moves left to right in pipeline

ln abc def    ;; link to abc installed as def

Answer 9

Similar to cp, which I mentally read as “copy this to that”, I read ln commands as “link this to that”.

Answer 10

Personally, I prefer to avoid remembering X, in favour of knowing where to look for X when I need it. I'm also a fan of the "better safe than sorry" attitude so I always like to check carefully what I'm writing, especially as root.

In this case, the answer is literally in the first lines of the manpage:

   ln [OPTION]... [-T] TARGET LINK_NAME
   (...)
   In the 1st form, create a link to TARGET with the name LINK_NAME.

I wouldn't have suggested it if it required to delve in the manpage, but since it's right at the beginning, IMHO it's worth the 3 seconds it takes to type man ln and quit.

Answer 11

This is how I remember it: Forget the target. In other words, if I am in dir1 and want to create a symlink here to file1 that exists in /some/other/dir/, I would just do:

ln -s /some/other/dir/file1

You will get a symlink called file1 in dir1 that points to /some/other/dir/file1. From the man page for ln:

ln [OPTION]... TARGET (2nd form) ... In the 2nd form, create a link to TARGET in the current directory.

Just keep in mind that this work only if you want the symlink to have the same name as the target (which most likely is the case).

Answer 12

Imagine a version of ln which allowed you to create multiple (symbolic) links in one command.

Synopsis: ln -s TARGET NEW_LINK...
Example: ln -s target_file  new_link_1  new_link_2  new_link_3

It wouldn't make any since to reverse that, since a symlink can only point to one TARGET at a time and the normal command line convention is to put the repeating part at the end of the command line, e.g. grep PAT [FILE]...

Answer 13

I'd like to expand on @gary's answer.

In addition to his anwer: the ln command can accept arbitrary number of arguments, so that you can create multiple symlinks in one invocation (which is handy when you need it).

1. With that knowledge, when you encounter ln -s foo bar baz, what's the most logical explanation which arguments means what?
2. With the answer to #1, when you encounter ln -s foo bar, what's the most logical explanation which arguments means what?