The one that always trips me up is that `ln` is “dumb” about how it handles the first argument.

If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd.

    ln ./foo ./bar/baz

./bar/baz will be a symlink whose literal contents are `./foo` so it will look for foo in the same directory (bar), rather than in bar’s parent directory.

This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.

At least with GNU coreutils, you can use `-r`/`--relative`

TIL!

I've never internalized this, so I usually stick to using absolute paths...

Not a solution for all problems, but it works for me most of the time.

Absolute paths will break if, for example, the target and source are in the same directory but you move the directory.

Sometimes you semantically want absolute paths (I want to symlink a thing to /bin/foo), sometimes you want relative paths (I want to symlink a thing to something in a nested directory).

This is what made the “ln” argument order click for me as well.

Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory:

  cp /other/dir/foo.txt .

The corresponding shortcut with ln is not naming the destination at all, and the symlink is created in the working directory:

  ln -s /other/dir/foo.txt

Both of the above are my most common usage patterns, and the abbreviation of the second argument in both helps reinforce the parallel between cp, mv and ln.

thanks, i still need to ignore the fact that the link on the right points to the left then