4 ms·
I don't like ln as an example of sanity. $ ln usage: ln [-Ffhinsv] source_file [target_file] ln [-Ffhinsv] source_file ... target_dir "Source = f
by Domenic_S 12y ago
I don't like ln as an example of sanity.
$ ln
usage: ln [-Ffhinsv] source_file [target_file]
ln [-Ffhinsv] source_file ... target_dir
"Source = from", "target = to" is how I interpret that. Then if you look at some existing link, you'll see it as:
my_link --> real_directory
In the direction of the arrow: from, to. But to create that link, the command would really be
$ ln real_directory my_link
The link target/real path is the source and the link to create is the target.
My brain thinks it breaks the idiom of `[cmd] [from] [to]` that cp, mv, etc use. You wouldn't say the example above is a link from real_dir to my_link, you'd say the opposite (and that's what the cli shows when you ls a link).
- bydo 12y agoI have no problems with tar; it's operating on the archive, so the operation goes first, then the archive, then the optionals. I have to look up ln every time.
- LukeShu 12y agoI agree that ln is a little confusing. I've often explained it to people that it's the same order as if you were copying the file, but it creates a link instead. Also, in sections 1 and 8 (shell), data typically flows from left-to-right across the line. The filename on the left flows into the link on the right. Data flows from the left of the pipe to the right. Whereas in section 3 (C), data typically flows from right-to-left across the line. Variable assignment, memcpy, ... There are of course exceptions (dup2, bcopy), but that's the general style for the order of arguments in *nix.