[elteto]

What finally got the `ln` argument order engraved in my mind was learning that you can skip the destination argument:

    ln -s /foo/bar/baz

will create a soft link in the CWD named baz, pointing to /foo/bar/baz.

So you see, if you know that you can always skip the destination, then, logically, the source must be the first one!

[atq2119]

I'd say the easiest way to remember the argument order is that it's conceptually the same as for mv and cp: ln -s x y is the closest possible symlink-analogue of cp x y.

[a_e_k]

Nah, the closest possible symlink-analogue of `cp x y` is `cp -s x y` :-)

[elteto]

This a great way to think about it.

[layer8]

> logically, the source must be the first one!

You mean the target, but that isn’t a logically necessary consequence at all. Conceivably, `ln` could support the following two syntaxes:

  ln [options] target
  ln [options] link_name target

The way I remember the correct parameter order is that I remember it’s the non-intuitive one.

[nice2meetu]

Ah, I remember it is the non-intuitive one, but then when I use it a while, I keep double-guessing which one is the intuitive one.

Kind of like when my wife tells me I'm doing something wrong and she wants it to be the other way.. I know she thinks this thing is important, but can't work out which way she wants it done.

[layer8]

The intuitive one is the order in which `ls` displays it, or assignment order (a := b). That’s how I remember what the intuitive order is. ;)

[naniwaduni]

Surely the intuitive order for mutating assignment is value → name, though...

[ryanianian]

I remember this as "ln=long -s=short $long $short" as in "ln -s $long $short" creates a $short file pointing to $longfile. But to your point, $short is defaulted to basename($long).

[OriginalPenguin]

The other way to think about it is that it's the same order as cp.

[geysersam]

Finally! Somehow I've never been able to remember that either.