I always forget the argument order of the `ln -s` command

I used to have this problem. Then I realized that if I want to really copy a file, I type<p>$cp file_from file_to<p>and that<p>$ln -s link_from link_to<p>has a very similar effect to the cp command above. I haven't messed this up ever since.

Does anyone know why C calls like 'strcpy' and 'strcat' are the opposite of this?<p><pre><code> strcat(target, source) strcpy(target, source) </code></pre> But, in SH...<p><pre><code> cp source target </code></pre> I feel like these things were developed around the same time, by the same community. I've always wondered if there was a reason for the different perspective.

I've always used complex numbers as a mnemonic: real + imaginary, a + bi (obviously the file is real and the softlink is "imaginary").<p><a href="http://en.wikipedia.org/wiki/Complex_number" rel="nofollow">http://en.wikipedia.org/wiki/Complex_number</a>

You can create multiple links with the original names at once with commands like:<p><pre><code> ln -s path1/files* path2/ </code></pre> or<p><pre><code> ln -s path1/* . </code></pre> Doing that helped me remember the order because I knew my command could end with a directory as the destination and links would be created there.<p>Sometimes hardlinks are useful too. You don't always need -s<p>Edit: Why was this downvoted? I didn't see anyone else mention it until after my post and to me this was an easier way to remember the order than comparing it to "cp".

My god, this thing always keeps biting me. It seems so obvious now with that cp-mnemonic. But it makes me wonder, why does everyone do it wrong in the first place?

For me, it's always the recursive options in (s)cp and chown/chmod and which one is capital -R which one is lower case -r. Simply vexing.

That's funny, I do too. I always thought it was just me...

The way I remember it is "ln -s target [filename]", where filename is an optional argument to override the default, where the default is a link created in the CWD pointing to target. Easy.

Why don't we have better shells that give hints on these things?<p>I'm thinking like an IDE will pop up some help text when you begin typing a function name or a recognised special word. Why doesn't the standard sh (bash for me) give me similar help, as I type "ln" it could give me a pop-up with the possible completions and then as I get to "ln -s" it could remind me with "TARGET [NAME] // will create a file named NAME that is a soft link to TARGET, or use TARGET's name if NAME isn't specified". You get the picture.<p>In a pure text env the help could appear on the next line highlighted appropriately or could be to the right of the cursor or somesuch.<p>I'm hoping someone will say $CONSOLE does that already ...? Anyone?

Yeah, the UNIX ln command is full of trouble.<p>* The arguments order is just the opposite of common sense. It has taken me years to really remember it, and I still have to think a little every time I use it.<p>* The default is to create hard link, which you almost never want. And if you do want them, you are probably doing it wrong. Making hard links is just asking for trouble.<p>I've read that Plan9 has somewhat corrected this whole problem. At least there is no ln command at all. Instead one uses bind, mount, and unmount. Of which bind is most similar to ln -s, but with arguments in reversed order.

I stopped remembering what the order was and just use the `lns` script found here: <a href="http://interglacial.com/~sburke/pub/lns.html" rel="nofollow">http://interglacial.com/~sburke/pub/lns.html</a>

The annoying thing is that the mklink command in Windows uses the opposite order, so you have to do<p>mklink link_to link_from<p>EDIT: formatting.

The worst part with that kind of mistakes is that you end up never knowing for sure. :)<p>You start with "ln -s A B" and realize you always make the mistake, so you force yourself to do the opposite of your natural instinct: "ln -s B A". It works until <i>this</i> becomes natural but you still think you always get it wrong, so start doing the opposite of your new natural: "ln -s A B". You'll now be very confused until you force yourself to learn it for good.<p>This happens to me all the time for various binary things.

Someone told me 'fact before fiction' a long time ago, and I've never forgotten it.

I just read the -s as "source" even though it really means symbolic.<p>ln -s source fakename

Think about boobs.<p>Everyone prefers real to fake*<p><pre><code> ln -s real fake </code></pre> Now you will never forget.<p>* <i>Yes, I realise this isn't strictly true</i>

I used to get this wrong all the time too. Mentally, I'd be thinking "ln -s source destination", where source was the link and destination was what it pointed to. Of course, that's completely backwards. 'man ln' on OSX didn't help either, since they use the terminology 'source_file [target_file]' which just re-inforced my incorrect thinking (target sounds like something that is pointed <i>to</i>, does it not?).<p>As other people have mentioned, thinking of it in terms of the files created (ala cp) has helped to learn the correct behavior. I think this is a case where some minor change in the documentation might help to avoid the whole problem.

If you leave off the second argument, you don't need to remember it. Much easier.

I think the source of confusion is that linking is closely associated with chains. When you add a link to a chain you always add the new link to the existing chain or<p>ln -s new_link (onto) existing(chain)<p>Obviously the target isn't a chain but the association between links and chains is a strong one.<p>In other words I don't think of creating a link as creating something new _from_ something that already exists, I think of it as adding something new _to_ something that already exists.

As someone who always had that problem, I think it's because I always mentally picture a command as saying "do &#60;action&#62; from &#60;arg0&#62; to &#60;arg1&#62;", ie, "copy this file to that file". But this construct doesn't hold up for linking, so I just have to remember it arbitrarily by remembering cp. function(src, dest) just generally seems to be the unofficial "right way" of ordering things.

Its like a black hole in my mind. Every single time I screw this up. I've.... just had to learn to live with deleting my first crappy link. :)

I think up to the 100th time reading the man page I would forget, until I memorized the following mantra:<p><pre><code> ln -s target link_name</code></pre>

I just remind myself that second argument is optional (and it couldn't be the other way around for that to work)

In CP/M the order really <i>was</i> "cp to from". So chosen to match the assignment operator in programming.

Every comment except this one is just a repeat of the stuff said in the original reddit discussion

My mnemonic for this is to remember that the link name is optional. When you specify only one argument the link name is the base name of the target (in the current working directory). Therefore the link name must be the second argument.

Imagine there's an arrow pointing left between the arguments. You know - "the symlink is pointing to this file".<p>ln -s file &#60;== symlink<p>Always remember that. Pointing left. The symlink is pointing at the file.

My mneumonic is that in "ln" the "n" comes second, and n is for "name" so the name of the symlink comes second. But I still have to think about it every time...

a copy points to the original (for an instant anyway) the same way that a link points to the original:<p><pre><code> cp original copy ln -s original link</code></pre>

The way I think of it is that the path that exists first (the target file), comes first.<p>It's kind of a dumb way to think of it, but it seems to work for me.

I also occasionally forget the -s, and really wish it was the default since I'm almost always creating a symbolic link.

when I noticed that I was messing up when using ln, I started thinking this way: "write what you already know first, so you have time to think about what you'll write next<p>"what you already know" being the existing file and the second part being the name of the link to the existing file.<p>I never got it wrong again.

Ruby's alias_method(new_name, old_name) always gets me also because I'm so used to ln [-s] (src, tgt).

A co-worker once told me to remember it like: "I have a (src) that I'd like to call (dst)"

My mneumonic is "lentil", since it's ln (-s) &#60;T-for-target&#62; &#60;L-for-link&#62;.

<i>I always forget the argument order of the `ln -s` command...</i><p>...because I met the `man` command.

Ditto. I just remember that it's the reverse of tar, but the cp trick is better.

Funny, I have a similar problem with scp.

I just think of the "-s" as "source".

"ln -s something somewhere"

think like so: ln -s {source} {target}<p>(not "from"/"to", which is ambiguous)

Keepin' it real fake...<p>ln -s real fake

$ ln -s javac javac<p>Not like that.

remember real first fake second ...

ln -s <i>source</i> destination

exist want<p>from to<p>source target

It's the same argument order for mv and cp, also the same for rsync and scp<p>Hell, it's even the same argument order for git-clone.<p>Pretty much all command lines use "source destination" order.<p>Why is 'ln' confusing? Because people think of "linking" in a backwards way, it seems that if you're creating a link from A -&#62; B, A is the source and B is the destination. But that's not the meaning of "source destination" that command lines expect<p><pre><code> mv B A </code></pre> A is the new B<p><pre><code> cp B A </code></pre> A is the new B, but B is still there<p><pre><code> ln -s B A </code></pre> A is the new B, except it's just a link, and yes, B is still there.<p>B is the source, A is the destination. B is the source of the data, A is the destination for that data; the command will create 'A' (or modify it), that's why it's the destination.<p>For the link itself, B is the destination, but for the operation of creating the link, B is the source, and that's the meaning that's consistent with all other commands.

I use emacs and dired as a condom that shields me from the stupidity that is remembering this kind of trivia.

Yeah it seems backwards to me as well. I always thought it was the only one.