After using Linux every day for 3 years, today I learned that the first parameter to ln is relative to the second one and not to the current location.

After years of ln I still have to check the docs on how to use it

And I don’t even know what ln does. Just googled it, seems interesting

Realised it when setting up nginx

What !??

I'm just gonna leave this here...

@magicMirror this xkcd makes me feel superior everytime.. tar -xvzf blahblah.tar.gz

I had to memorize it since it was all that i was doing in my job most of the time.

@purist good ol eXtract Ze File

ln is a prime example of how not design UX.
It does the wrong thing by default and i had to read the man page every fucking time to get the parameters right.

Whoever made it, basically invented UI anti patterns.

@Oktokolo I think the reason for this behavior is that it reminds the user of how symlinks work; that they refer to different things in different file systems, that their meaning changes when you move the folder and that their interpretation is up to the program at hand.

@homo-lorens
You got a point there in the sense, that it actually is impossible to use the tool without reading the man page before every use. So yes, it makes the user aware about the simplicity of the concept of symlinks by exposing him to a horrible UI designed to be as bad as possible without being horrible enough to provoke a fork (but now that i think about that, i really wonder why that didn't instantly happen back then)...

@Oktokolo Okay, how else should it work such that you can guarantee that every legal set of parameters maps to exactly one meaning and every legal meaning is mapped by at least one set of parameters?

@Oktokolo Assuming that you can't change how symlinks work, because their simplicity and versatility is key to their popularity. You can direct them to an absolute path to refer to system-global things like executables and devices, or a relative path to refer to nearby files, eg. within a version controlled tree. This usage is portable across many file systems and OSes.

@homo-lorens
Change default to create a symbolic links (hard links are actually the exception).
Limit the tool to only create one link at a time (eliminates forms 3 and 4, and -t, --target-directory).
Remove the backup feature (--backup, -b, -S, --suffix).
Remove support for hard linking directories (-d, -F, --directory).
Remove dereferencing support (-L, --logical, -n, --no-dereference) - just link what is named.
Always create links relative to current working directory (-r, --relative).
Always treat link name as a relative path (obsoletes -T, --no-target-directory).

@homo-lorens
What is left is a single syntax: ln [option]... <target> <linkname>
<target> is used as given for symbolic links. It is interpreted relative to current directory for hard links (still fails if file doesn't exist or is on another file system).
<linkname> is always treated as a path relative to current working directory like in the other GNU core utilities.
<linkname> is still optional and defaults to the last path element of <target> (which still doesn't have to exist).

Options left:
-f, --force, -i, --interactive, -P, --physical, -s, --symbolic, -v, --verbose, --help, --version.

@homo-lorens
You decide between relative and absolute paths (for symbolic links) by starting or not starting the target with a slash (like in literally every other case where paths are given to a program).