
I always forget the argument order of the `ln -s` command - pepsi_can
http://www.reddit.com/r/programming/comments/1qt0z/ln_s_d1_d2_am_i_the_only_person_who_gets_this_the
======
terra_t
I used to have this problem. Then I realized that if I want to really copy a
file, I type

$cp file_from file_to

and that

$ln -s link_from link_to

has a very similar effect to the cp command above. I haven't messed this up
ever since.

~~~
jackowayed
This phrasing confused me more.

`$ ln -s link_from link_to` would imply the reverse behavior. How does a
symlink point from the actual file to the thing-that-looks-like-a-file-but-is-
really-a-symlink? The file doesn't even know whether there are symlinks
pointing to it.

Applying your definitions of "link from" and "link to", this:

<a href="[http://google.com/>Google</a>](http://google.com/>Google</a>);

creates a link from google.com to the hyperlink on your site.

I find the top reddit comment:

    
    
        cp existing new
        ln -s existing new
    

much, much more useful. You want to create a new link pointing to an existing
file, which has the same ordering as when you use cp to create a new file with
the content of an existing file.

~~~
joshwa
Less ambiguously:

    
    
      cp    existing_thing new_thing
      ln -s existing_thing new_thing

------
dboyd
Does anyone know why C calls like 'strcpy' and 'strcat' are the opposite of
this?

    
    
      strcat(target, source)
      strcpy(target, source)
    

But, in SH...

    
    
      cp source target
    
    

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.

~~~
philwelch
This is a crime against usability IMO. Another comment mentioned that tar
takes arguments as "target source" rather than "source target".

Ever notice that for everything in the world that screws, like valves or
screws or bottle caps, counter-clockwise loosens and clockwise tightens? How
is it we got the whole world to agree on that convention, but software is
50/50 on how we order the source and destination?

~~~
jonsen
Except volume dials.

~~~
jholman
I conclude from this, by process of logical inference, that "louder" must be a
type of "tighter".

"Forward" is also "tighter", apparently.

------
frossie
I've always used complex numbers as a mnemonic: real + imaginary, a + bi
(obviously the file is real and the softlink is "imaginary").

<http://en.wikipedia.org/wiki/Complex_number>

~~~
andywhite37
The real/imaginary concept is exactly what I use too. I sort of recall being
able to use the real/imaginary concept with other Unix commands as well, but I
can't recall which ones off the top of my head.

~~~
jacquesm
rm only has the real component before you issue it and the imaginary one
afterwards ;)

------
daten
You can create multiple links with the original names at once with commands
like:

    
    
      ln -s path1/files* path2/
    

or

    
    
      ln -s path1/* .
    

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.

Sometimes hardlinks are useful too. You don't always need -s

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

------
jvdh
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?

~~~
nollidge
At least for me, it's because I say in my head "link $FOO to $BAR", which must
be typed "ln -s $BAR $FOO".

~~~
rg3
My theory is that we're used to see symlinks as part of the "ls -l" output,
which lists the link name first, and then the target. Later, we want to create
symlinks as we're used to see them (linkname -> target).

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

~~~
trafficlight
Yeah this one is particularly annoying.

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

~~~
Ygor
It is never just you. An important lesson I learned while programming.

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

~~~
andrewcooke
Yup. The thought process is basically "the target is optional, so it has to go
last".

------
pbhjpbhj
Why don't we have better shells that give hints on these things?

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.

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.

I'm hoping someone will say $CONSOLE does that already ...? Anyone?

~~~
zokier
It's mostly for historical reasons. More specifically we have restricted shell
as text mode only tool, and intellisense-like features/inline help do not tend
themselves neatly to line/character based output.

I think that there could be a place for a modern, more graphical orinted
command-line interface. In addition to inline help it could display tables
more nicely, maybe even allow proportional fonts. And while we are changing
stuff, then maybe the object passing idea could be taken from PowerShell.

~~~
xiongchiamiov
It could still be text-based if it uses ncurses. For instance, something like
bpython: <http://bpython-interpreter.org/screenshots/>

------
nene
Yeah, the UNIX ln command is full of trouble.

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

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

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.

------
streeter
I stopped remembering what the order was and just use the `lns` script found
here: <http://interglacial.com/~sburke/pub/lns.html>

~~~
arnemart
Same here. lns is always one of the first things I install on a new system.

------
cdonnellytx
The annoying thing is that the mklink command in Windows uses the opposite
order, so you have to do

mklink link_to link_from

EDIT: formatting.

------
Timothee
The worst part with that kind of mistakes is that you end up never knowing for
sure. :)

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

This happens to me all the time for various binary things.

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

------
shimon
I just read the -s as "source" even though it really means symbolic.

ln -s source fakename

------
sidawson
Think about boobs.

Everyone prefers real to fake*

    
    
      ln -s real fake
    

Now you will never forget.

* _Yes, I realise this isn't strictly true_

------
sibsibsib
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 _to_ , does it not?).

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.

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

~~~
ja27
That's how I finally got it right. Now I just remember that the second arg
("dest") is optional.

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

ln -s new_link (onto) existing(chain)

Obviously the target isn't a chain but the association between links and
chains is a strong one.

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.

------
manvsmachine
As someone who always had that problem, I think it's because I always mentally
picture a command as saying "do <action> from <arg0> to <arg1>", 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.

------
inanedrivel
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. :)

------
frankus
I think up to the 100th time reading the man page I would forget, until I
memorized the following mantra:

    
    
        ln -s target link_name

~~~
w1ntermute
Same here, I just memorized "target [the] link name".

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

------
phaedrus
In CP/M the order really _was_ "cp to from". So chosen to match the assignment
operator in programming.

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

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

------
Florin_Andrei
Imagine there's an arrow pointing left between the arguments. You know - "the
symlink is pointing to this file".

ln -s file <== symlink

Always remember that. Pointing left. The symlink is pointing at the file.

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

------
stretchwithme
a copy points to the original (for an instant anyway) the same way that a link
points to the original:

    
    
      cp original copy
    
      ln -s original link

------
funksta
The way I think of it is that the path that exists first (the target file),
comes first.

It's kind of a dumb way to think of it, but it seems to work for me.

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

~~~
double122
Could you maybe add:

alias ln='ln -s'

to your .bashrc? A quick test of this in my terminal and the alias takes
precedent over the ln command. Although, I guess it'd be worth doing a few
tests to make certain!

~~~
dminor
Sure, but I'd rather not get bitten when I'm on a system where I don't have
that alias defined.

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

"what you already know" being the existing file and the second part being the
name of the link to the existing file.

I never got it wrong again.

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

~~~
austintaylor
The arguments are in order they appear. i.e. alias_method :alias, :method

But yeah, it's weird that it's opposite of ln.

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

------
endtime
My mneumonic is "lentil", since it's ln (-s) <T-for-target> <L-for-link>.

------
aeurielesn
_I always forget the argument order of the `ln -s` command..._

...because I met the `man` command.

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

------
mattwdelong
Funny, I have a similar problem with scp.

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

------
kaens
"ln -s something somewhere"

------
joubert
think like so: ln -s {source} {target}

(not "from"/"to", which is ambiguous)

------
duncanj
Keepin' it real fake...

ln -s real fake

------
dclane
$ ln -s javac javac

Not like that.

------
joe24pack
remember real first fake second ...

------
known
ln -s _source_ destination

------
PeterWhittaker
exist want

from to

source target

------
hasenj
It's the same argument order for mv and cp, also the same for rsync and scp

Hell, it's even the same argument order for git-clone.

Pretty much all command lines use "source destination" order.

Why is 'ln' confusing? Because people think of "linking" in a backwards way,
it seems that if you're creating a link from A -> B, A is the source and B is
the destination. But that's not the meaning of "source destination" that
command lines expect

    
    
      mv B A
    

A is the new B

    
    
      cp B A
    

A is the new B, but B is still there

    
    
      ln -s B A
    

A is the new B, except it's just a link, and yes, B is still there.

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.

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.

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

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

