The one that always trips me up is that `ln` is “dumb” about how it handles the first argument.
If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd.
ln ./foo ./bar/baz
This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.
I've never internalized this, so I usually stick to using absolute paths...
Not a solution for all problems, but it works for me most of the time.
Absolute paths will break if, for example, the target and source are in the same directory but you move the directory.
Sometimes you semantically want absolute paths (I want to symlink a thing to /bin/foo), sometimes you want relative paths (I want to symlink a thing to something in a nested directory).
This is what made the “ln” argument order click for me as well.
Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory:
cp /other/dir/foo.txt .
ln -s /other/dir/foo.txt
thanks, i still need to ignore the fact that the link on the right points to the left then
That is, if before there is something at /some/path but not /another/path , after running
there will be something there (same as cp).