Live data from Hacker News

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

reddit.com

41–50 of 127 posts

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

#41
post #10

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.

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?

tar is like that because of command lines

tar [args] [one thing] [list of things]

it'd be wierd if it was

tar [args] [list of things] [filename]

... but i will admit i frequently make that mistake.

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

#42
post #14
post #10

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.

Probably in order to be consistent with assignment.

Which is really the odd ball. In a left-to-right language, it's sort of bizarre that we don't write `4 = x' since the rvalue tends to be the more complicated part of the expression.

The curious bit is, AT&T assembly syntax does follow this convention so you'll see something like `mov $5, ax'.

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

#44
post #10

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.

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?

I don't feel it's a crime. For that matter, I don't even prefer one over the other.

For "mv A B"

I've no problem saying either

  mv into A the contents of B
or

  mv the contents of A into B

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

#45
post #41

Earlier quoted context omitted.

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?

tar is like that because of command lines tar [args] [one thing] [list of things] it'd be wierd if it was tar [args] [list of things] [filename] ... but i will admit i frequently make that mistake.

But, as a counterpoint, if you want to copy several things to a folder, you do:

  cp [args] [list of things] [destination folder]

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

#46
post #2

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.

The problem with "from" and "to" is - which is the from and which is the to?

Is the "from" the file/dir I want to copy "to" a link?

Or is the "from" the name of a link I want to point "to"?

The dual meaning of some terms that the concept of links and making links creates causes a lot of this confusion, IMHO. Are we using terminology that refers to the act of creating the link or that refers to the direction of the link?

Similarly, I don't think it helps that the usage text and manpage for ln refer to "target"s.

(I know what you mean by your examples but I wanted to share my pet theory as to why this is always so hard to remember)

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

#47
post #36

Earlier quoted context omitted.

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?

Except volume dials.

And gas valves.

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

#49
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.

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

#50
post #10

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.

The reason strcat, strcpy have the destination first is because of the need to support a variable number of arguments. By definition, if the number of arguments is variable, they must be at the end. So if you think of sprintf for instance, the destination has to be first. Now, to be consistent, strcat has to behave the same and have the destination first as well, although it doesn't have a variable number of arguments.
Post reply on HN